I think it sounds good @richbhanover.

About the trunk thing:

Supported Since Rev                   :                # https://dev.openwrt.org/changeset/Rxxxxx
Supported Since Rel_release           : 10.03          # First official release (i.e. not trunk)
Supported Current Rel_release         : 10.03          # Current official release (i.e. not trunk)
Firmware OpenWrt Install URL_url      :                # downloads.openwrt.org/...factory.bin
Firmware OpenWrt Upgrade URL_url      :                # downloads.openwrt.org/...sysupgrade.bin

Supported Since Rev = trunk. The other ones are clearly not about trunk.
For images with no stable release, but a working trunk image, the url could point to trunk.
Ok?

(Last edited by zo0ok on 19 Aug 2015, 17:56)

@zo0ok: Looking at the pagename and pagetitle: linksys_e2000_10 -> E2000 1.0

1) 10 is no good representation of 1.0
More examples
https://dl.dropboxusercontent.com/u/906 … 66_130.txt
https://dl.dropboxusercontent.com/u/906 … 0_v100.txt (all engenius devices)
glinet, Linksys E*, Netgear WNDR + WNR series (1 + v1 mixed)

Yes, '.' is allowed in dokuwiki pagenames (see https://www.dokuwiki.org/pagename)

2) Compare
Devicepage http://wiki.openwrt.org/toh/d-link/dir-505
  vs.
Dataentry page: http://wiki.openwrt.org/toh/hwdata/d-li … nk_dir-505

-> Devicepage has no brand in the pagename, but Brand in the pagetitle
-> Dataentry has the brand in the pagename, but is missing the brand in the pagetitle

Current: ====== Techdata: DSL-062 6.62 ======
Should be: ====== Techdata: D-Link DSL-062 6.62 ======

Thanks for the hint, I corrected the template, which now has "http://¿" as default (the http:// gets added automatically by the data plugin).

Fields "Identical to / AKA" / "Similar to":
How do we handle devices like this example (there are some more): http://wiki.openwrt.org/toh/frys/fr54rtr ?

No! Please let's improve the bare "trunk" by adding the corresponding release, so you have an indication *what* trunk it is.

http://wiki.openwrt.org/meta/infobox/dataentry_topnote already contains this: For adding new dropdown values, contact the wiki admin.

Why would you want to manually type '¿' ?-)
In http://wiki.openwrt.org/meta/template_dataentry I can not find a field where you would need to enter ¿ manually.
And if there was a field: Copy & Paste.

Added some specs.

http://wiki.openwrt.org/oldwiki/completetableofhardware does not have any comment like that and is simply set to read only.
That's enough.

This field is _hidden (not visible in the editor), and users are not supposed to edit the wikisource, but rather use the LEFT edit button.

OK, this needs a change then:

Supported Since Rel_release -> Supported Since Rel_releasesince
Supported Current Rel_release -> Supported Current Rel_releasecurrent

Allowed values:

_releasesince: ¿, -, 0.9, 7.06, 7.09, 8.09, 8.09.2, 10.03, 10.03.1, 12.09, 14.07, 15.05, CC trunk, DD trunk, WIP, unsupportable, external image
_releasecurrent: ¿, -, 0.9, 7.06, 7.09, 8.09, 8.09.2, 10.03, 10.03.1, 12.09, 14.07, 15.05, WIP, unsupportable, external image

current = since - trunk

I have set ¿ as default in the template.

(Last edited by tmo26 on 19 Aug 2015, 21:13)

"If there's no information visible, then nobody has entered information."
I refuse to explain things this obvious.

I like it short and crisp:

If there's no install firmware link visible, it means that you are the lucky one who can contribute to the OpenWrt wiki by searching for it in the "latest release" or in "trunk".

1) Search for your device in the http://wiki.openwrt.org/toh/views/toh_extended_all
2) Look for the Target column
3) Goto https://downloads.openwrt.org/snapshots/trunk/ or https://downloads.openwrt.org/latest/
4) Goto the Target directory you found in 2)
5) Search for brand and / or model/version of your device
6) Find something ending in ...factory.bin + ...sysupgrade.bin
7) Edit the dataentry of your device and add the link you found in 6)

You might want to exchange "the lucky one" against some other phrase with positive connotation, which gives the $user a good feeling ("YES!!1 I'm the lucky one who contributed!!!11";-)

Wow... suddenly many things to fix... I will not do it tonight.

I agree with nearly everything that everyone has said. In the interest of coming to closure, I want to list my only open issues:

1) Handling "trunk" releases: I still don't understand how we want people to set the fields of a dataentry to indicate that a router is supported by the stable (say, BB) release, but that there's also a trunk (CC) image that seems to be working. (We have handled the case of a brand new router that has never had a stable release already.)

2) I am concerned that we could get a brittle system following the responses to thread messages #953 & $954 (re: comment on the ToH page and Techdata comment). These solutions will work fine if people read the documentation and understand it fully before proceeding. But to help people who don't read carefully, and/or make a mistake, I like to leave hints in place. Specifically:
    - For #953: Yes, the major new ToH pages should be locked... But if someone tries to edit a ToH page the way they've "always done it", they will see the comment telling them the new way to add/update info.
    - For #954: If someone *does* use the right-hand Edit, we could use the same kind of block comment to say, "Use the bottom edit button"

3) I regret mentioning the empty URLs. I think the empty string looks much better than the peculiar and non-working http://¿ URL.

4) I think we need to include explicit instructions for contacting the wiki admin. *I* don't know how to do it (unless it's contacting tmo26) - all my previous e-mail efforts have led to naught.

(Last edited by richbhanover on 20 Aug 2015, 04:55)

I'll try to explain why things are the way they are:
- version is often not sensible in the filename ( v1, v2, v3.5 )
    + too much
    + version value may change in future, and then we don't want to change filename
- version is not necessarily something that makes a row truly unique
    + possible that NameA+VersionA = NameB+VersionB, even though NameA != NameB (look at the ASUS devices to see the risk)

My strategy is:
1) If the version is sensible I add a simplified version of it to the filename
    - "all", (empty), 1,2,3, things like that are not added
2) If, when the above rule is applied, a page does not have a unique name, I just add a number (_1, _2, _3...)

This is not super great in every way. But this is anyway a lose-lose-situation.

If I add a new device today (imaginary: TP-Link Archer zo0ok AC2500), I may not know the version even though I have plenty of good information about the device. So it does not make sense to require a valid version to be added to the filename. In the future, new revisions can come out: B, C, D. These may or may not be "practically identical" to my first version (A). Unless we can't look into the future we can't make good choices about naming files based on versions.

Academically, three solutions could be better:
1) use a GUID filename instead (I hate this)
2) always require version before adding a device, and create multiple entries when there is a new version, even if they are practically identical (this sucks a lot in the real world for us)
3) Never use version in the filename, always use _1, _2, _3 instead. But this just makes things less clear and more consistent.

I can easily allow 1.00 or 1.0 in the filename (rather than 100 or 10). Fine.
But you can still not look at the filename and draw any useful or general conclusions about the device version.

After some more thinking about this: _releasecurrent shouldn't contain WIP, right?

_releasecurrent = _releasesince - *trunk - WIP

If direct contact to the developers / admins doesn't work:
"If you need to contact a wiki admin, please visit the openwrt forum."

Not really nice, but IMHO a working solution.

Perfect would be, if we had an emailadress for this: wiki-admin@openwrt.org
This should be an email account that more than one person can access.

Because someone here thought it was smart to get rid of the Status column, right?

At the moment, I think neither releasesince nor releasecurrent should contain trunk, wip, unsupportable.
I think:
Trunk: Supported Since Rev=rXXXX, AND image=download.../trunk/....bin
WIP: Unsupported=WIP (with a possible comment)
Unsupportable: Unsupported=No Linux support for Platform

External Image: I am fine keeping this option for the rare cases only an external image is available.

I think todays WIP/Possible are not very useful. Remember: http://wiki.openwrt.org/toh/samsung/smt-g3xx0
How long is it going to remain WIP? Unless there is a real release, I think we should leave our Supported Xxx Rev fields empty.

I have been implementing large business systems for over 25 years.  I know from experience that the technical solution (the ToH itself) is only a small part of the "system".  Gaining user acceptance, which typically includes testing, training and supporting documentation is a major part of a successful implementation.

We have offered testing, and they did not come.
Training is not easy with out a captive audience.  The best someone could do are some YouTube videos.
Documentation on the other hand is something that can be done. 

It is NOT reasonable to expect users to look for or find the pages of information that exist; they need to be directed.  The site search tools, in general, are poor.  The pages are not well linked and the pages that do exist are in need of review for current content and organization. 

It's a relatively small effort to go the extra mile and create fresh and succinct documentation for the actual product.  This includes content both separate from and on the actual product pages.

I have taken a stab at a ToH Start PAGE, which I think should replace the existing ToH entry page http://wiki.openwrt.org/toh/start.. The concept is a single main page that includes all the major links to the tool set, with thin supporting text, followed by FAQ and maintenance information.  What I am offering is a starting point. 

Substantially:
1 - ToH Views
2 - Device Management
3 - FAQs, guides, standards and other reference links

The page should be simple and clean, especially the section for the first 2 items.  I personally prefer the approach where the content of the FAQs is expanded and contracted (+/-) on the same page.  It makes the browsing experience cleaner for the user.

The unformatted text page can be found here: https://www.dropbox.com/s/copgt1bh35vku … e.txt?dl=0

Indirectly related, while there is a basic hyperlink on the https://www.openwrt.org/ page to the Table of Hardware, it says "Supported Device" (now outdated).  I think this topic deserves a more prominent display in a small section of it's own below "What is OpenWRT?".  One sentence and a link to the above page.

Pictures - 1366 x 768 is I believe to be the lowest value of most smaller laptop screens.  The max size should not require one to scroll, so 1280 x 720 to account for frames and to apply a generally accepted value\ratio of 16x9.  File size limit in the 250-500 k for something of this size. How does the picture get loaded to media:toh:brand:brand_model_general_view.jpg? 

dataentry and techdata - I think we refer to the dataentry page to create the techdata.  Is it possible to standardize on a single term, preferably Techdata, for at least all references, if not page names.  "Data Entry" is a generic process and I think it may be confusing to the user.

Done, link added, see http://wiki.openwrt.org/meta/template_d … amp;#usage
(And added myself to the contact page as contact for ToH specific questions).

(Last edited by tmo26 on 20 Aug 2015, 19:36)

- 1280x720 added as max size
- Filesize is limited to 2MB via media manager
- Howto added
- Sample picture added to DIR-505, one inside of the dataentry, one outside. Which one do you like best?

-> http://wiki.openwrt.org/toh/hwdata/d-li … acteristic

Warning implemented, see http://wiki.openwrt.org/meta/template_dataentry

For filtering "trunk", this would require both columns to be present in the datatable.
Two more columns? Really?

We got rid of the status column, reintroduced it as unsupported column, and now would need two more in order to be able to filter for trunk support? What do we gain by doing so, what's the benefit?

re: Trunk vs. Stable... I have to apologize, but I'm going to throw another rock in the pond.

It seems that we are struggling to represent two independent ideas: Stable builds (that most people should use) and "experimental" builds (that will make the world better when they're done) - these are usually "Trunk"...

Maybe we should just accept this dichotomy and create two categories of entries in the dataentry:

Current Stable Build: 14.07
Current Stable Firmware: http://...factory.bin

Current Experimental Build: 15.05 rc3
Current Experimental Firmware: http://...factory.bin

There aren't really many cases:

- For a brand new router that's a WIP, Stable Build is "" (no stable build), Experimental Build is "trunk" with a link to the current trunk (or external developer's image)

- For a router that's been around for a while (in August 2015), Stable Build is 14.07, Experimental build is 15.05/Trunk/rc3/whatever...

- For that same router in October 2015 (after CC ships), Stable Build is 15.05, Experimental is "trunk" (or whatever we call the DD builds)

- For a really ancient router, Stable Build is "8.09", Experimental is "" because no one has tried to update it.

Does this make sense?

(Last edited by richbhanover on 21 Aug 2015, 03:11)

@tmo26: Thanks for adding your contact info as "wiki admin". Thanks, too, for updating the dataentry template. I like the bit about, "... If you can read this, you're doing it wrong." If I may make a couple more observations,

1) Move that comment block to the top of the page. It'll be*even more* obvious...
2) I'd use the phrase "Edit this page using the 'Edit' button at the bottom" instead of talking about the "lower LEFT edit button"
3) I think the repeated info (3 & 4) is a bit of overkill :-)

(Last edited by richbhanover on 21 Aug 2015, 03:09)

@RangerZ - I agree, and thanks for pointing this out. The hurdle for this community-supported wiki is to allow our viewers to "do the right thing" at the moment it occurs to them that they can provide additional information.

So we need to figure out how to provide the hints that move people to the page/form/etc. where they can enter the "things they know" so that it becomes part of the permanent knowledge base.

Personally, I think the ToH and the dataentry pages are in great shape, and we're just arguing about optimizations that take us from 93 -> 97% perfect. We should definitely continue the discussion, but be comfortable that we have made a huge improvement to the Wiki.

@RangerZ - We have also been thinking about a new top-level pages for the wiki. I have proposed two:

- http://test.richb-hanover.com/openwrt-redesign/ - this is an updated home page for the www.openwrt.org site. It removes all the old/outdated stuff, and has links to current/relevant info.

- http://wiki.openwrt.org/doc/playground - This could be the new "home page of the wiki." It attempts to direct people to pages based on their experience with the OpenWrt product...

Your take on the documentation problem at https://www.dropbox.com/s/copgt1bh35vku … e.txt?dl=0 is another shot at fixing this. I would be quite interested to work with you to make sure all this info gets presented to people "at the right time" - when they are asking the question... Thanks.

(Last edited by richbhanover on 21 Aug 2015, 03:20)

I think there is some misunderstanding going on... perhaps on my side.

I like to get rid of the old 5-page-distinctions (supported/wip/possible/unknown/impossible), and focus on actual properties/capabilities/facts instead.

A (fully) supported device:

Supported Since Rev                   : R12345
Supported Since Rel_release           : 12.09     # First official release (i.e. not trunk)
Supported Current Rel_release         : 14.07     # Current official release (i.e. not trunk)
Unsupported                           :           # Describe what is not supported or status
Firmware OpenWrt Install URL_url      : http://downloads.openwrt.org/.../14.07/...factory.bin
Firmware OpenWrt Upgrade URL_url      : http://downloads.openwrt.org/.../14.07/...sysupgrade.bin

An experimental/trunk supported device:

Supported Since Rev                   : R12345
Supported Since Rel_release           : 
Supported Current Rel_release         : 
Unsupported                           : WiFi unstable         # Describe what is not supported or status
Firmware OpenWrt Install URL_url      : http://downloads.openwrt.org/.../trunk/...factory.bin
Firmware OpenWrt Upgrade URL_url      : http://downloads.openwrt.org/.../trunk/...sysupgrade.bin

A non-working device:

Supported Since Rev                   :
Supported Since Rel_release           : 
Supported Current Rel_release         : 
Unsupported                           : Bootloader does not accept OpenWrt image
Firmware OpenWrt Install URL_url      : 
Firmware OpenWrt Upgrade URL_url      : 
Forum Topic URL_url                   : http://forum.openwrt.org/viewtopic.php?id=xxxxx

I dont see any reason to classify this into WIP/Possible/Unknown/Impossible/(Abandoned). For anyone
a) waiting for the device to be supported
b) wanting to work on device support
the forum topic, Unsupported field, and Comment field should be better. Historically, many devices remain WIP/Possible for long, while other devices are completely undocumented even when they are supported (Netgear R7000). So, lets just focus on the fact, and leave the "progress/status" to the reader.

I prefer not to have separate fields for trunk-image:
a) they are not recommended for end users anyway
b) they change every night, and there is no guarantee the image you get actually works and have been tested by anyone
I think however, that when Supported Since/Supported Current are empty (as for trunk), we can allow links to trunk images, since it is obvious that the device is not supported (edit: as in stable-release-end-user-supported).
c) people who need trunk/experimental images will easily find them anyway (being helped by the link to the stable image)

@tmo26: You (who have a more practical wiki-user-perspective than I have) see some kind of use case or end user requirement that I fail to understand?

(Last edited by zo0ok on 23 Aug 2015, 08:20)

Is there more than one trunk?
I realize I don't know how this actually works (the development).

When it comes to CC trunk, CC RCX, and those things... it is pretty short lived... I think we should focus on what the end users really need. The developers will always manage.

In addition to the read only status, old ToH pages can get infoboxes like shown here (historic&locked): http://wiki.openwrt.org/oldwiki/start