This gives us a basis for making judgements about the fields to include/exclude for these templates as requested in the original post. Here are some thoughts:
This looks really good. It's comfortable for those of us who worked on the OpenWrt ToH, and gives us a chance to do it even better.
If I remember correctly, it's (relatively) straightforward to make systematic changes to these templates. We have scripts that can add a new fields with known/static data. Similarly, the scripts can automatically remove a given field from each template.
It would be a lot of (manual?) work to add new fields that have unique data for each device's template.
Should the top-level start page be within the "hwdata_lede" folder? (Maybe not, since it might get in the way of the script processing)
I had thought about including FCC ID & date as fields since these are valuable for determining the age and identity of a router. But it would (pretty likely) duplicate Wikidevi info. Perhaps we could have a "FCC ID & Date" field, but populate it with a link to Wikidevi (or just "See Wikidevi page")
[Side note: it was pretty scary when wikidevi went off the air about 6 months ago, and no one could raise its maintainers. Do we know if there's a (public) backup? How might we find out?]
If we include any instructive text on the dataentry pages, I think we should tell readers to use the "edit" button at the "lower left" of the page. (OpenWrt pages say on the "left" - and I scan in vain to find it.)
I'll say more as I look harder at it. But Great Work!
These are the minimum/maximum columns tables, just to give you an impression of the look with the raw bootstrap wiki-template. I will see if I can change this to a better (i.e. show hor/vert lines in the tables) via CSS.
Be careful: You are mixing up template and dataentry.
template_dataentry != dataentry of device_xyz
template_dataentry = the mother of all dataentries
The template itself doesn't contain any device specific information, but the dataentry does.
Changes to the template_dataentry are easy, since it is a normal wiki page.
Whatever we want to be in the dataentries, we better decide now and implement that now (=@time of import), instead of later.
The LEDE ToH dataentries are created via a script that contains the template (not the template page out of the wiki, but hardcoded in the script; changes to the wiki page must be transfered into the script manually. That's why I currently work with the script, rather than the wiki page; wiki will get updated later).
Changes @creation time of the dataentries are easy to do and result in nice and clean dataentries from the beginning, without any spamming of the wiki logs. There are more than 1100 devices in the ToH, and a change that affects all would result in more than 1100 changes that the wiki would have to handle. I would like to avoid that.
On top of that: If the dataentries are created correctly right from the beginning, you can later rely on that all dataentries have the same fields. This is important for the usage of the data in the datatables: If fields are added oder changed or deleted later on, you might have to adjust all datatables that make use of those fields. Tedious work that really needs to be avoided.
Changes that come later, when the LEDE ToH is fully implemented, can be done via wiki internal batch edit (not preferred for changes of more than 50 devices; you have to click a checkbox for each of them, which get's annying with increasing numbers), or alternatively via a shellscript (once again ssh access proves useful, thanks Ted!
The current folder is a little dirty remainder of the conversion. I forgot to change it to hwdata only. will be updated in the next update.
Regarding FCC: Linking to wikidevi would not make much sense. A link to https://fcc.io/yourFCCid is nice and short and easy to create for the user.
Regarding wikidevi: I havn't yet contacted them, since I wanted to have full access to the ToH data first. If I want to offer something to wikidevi, I need to be able to export data from the sqlite db and send it over to wikidevi. This ability is not given in the OpenWrt wiki (at least not for me), but now in the LEDE wiki.
A wikidevi backup is not a bad idea, indeed. This big pool of data must be available at all times.
Regarding LEFT edit button: Take a look at the dataentries: The 'includes' are already there, but the source of the includes not yet. Will be done later...
BTW: This is a nice example for modularity: Change one include-source, and you changed >1100 dataentries, without even touching them.
OK, enough for this reply. Keep on looking, let me know if there's something to improve.
Yes, I wasn't quite clear. It's all about "creation time". If we want to apply changes to every template, we really need to decide about those changes right now.
It's one thing to run a script across the 1100 dataentry pages to add/modify/remove fields. If we screw up and want to make changes after other people have started to enter their own info, it's a much harder process.
I was only suggesting that I would prefer to call this the "bottom-left button". I was initially perplexed at the instructions stating to use the "left edit button" because my eyes looked to the left and didn't see one... at least until I scrolled all the way down to the bottom. "bottom-left Edit button" would completely satisfy my concern.
depending on what you think about my idea here about templating the flashing guides too, we might need more fields to accomodate the info required by that to work
(flash offsets (min/max) for manual flashing, an identifier field to link the right tutorial depending on web interface as newer devices might have a different web interface even if they have the same brand ,console settings, something else maybe)
The file downloads have been reorganized and most of the packages are now at a folder at the same hierarchy level as targets. Under this "packages" folder are now a flat set of 39 instruction sets (I just checked all the subfolders) so I do not the the "Sub Instruction Set" field will be needed.
I have gone into more detail here: Packages for instruction sets I have no idea how to map the values in this table, and suspect most users will also not.
OK, now I get it!
I'm afraid, AFAIK this is not possible. That's our old problem, that we want to show a short link in the datatables, e.g. "Installation Image" or "Upgrade Image" instead of the current full url.
We were talking about modularity. Several devices share the same installation methods.
Introducing the "Installation method" field was an attempt to create shortcuts to the always same installation instructions, that do not need to be repeated over and over again.
I am not sure of the value of this "Installation method" field.
First off, I don't know how we would populate it. It wouldn't make
sense for us to review all the Device Pages from OpenWrt: despite the
fact that it would be a lot of work, we'd simply propagate any
(mis)information contained there (because we don't have personal
experience with all devices).
Second, what will the reader do differently based on the setting of this field? Would they choose not to use the device?
I'm not afraid of a lot of work.
Why should we review the OpenWrt devicepages, when this is about LEDE devicepages (which have yet to be created)?
You don't want to propagate (mis)information -> you don't want to copy the OpenWrt devicepages, but instead create new LEDE devicepages. If the devicepages are created new anyways, why not add a new way to include installation instructions?
Why should the reader do anything differently?
What you might think: The "Installation method" shows up in the ToH, and the $user wants to sort and select by this criteria. That's not necessarily so, but thinking about it, it could be a usecase (I want a device that can be flashed via GUI, since I'm too noob to even think about using CLI. Everything different than GUI will not do.) But that's only thinking aloud...
What I was thinking of: Show this field only on the devicepages and make them more modular by doing so.
Look at the packages download: Packages are now downloadable by instruction set, not by target, because several targets share the same instructionset and therefore also the same packages.
Same same in this case: Several devices / targets share the same installation instructions.
You could show this field on the devicepage in the "Installation" datatable, right next to the firmware download urls https://wiki.openwrt.org/meta/template_device#installation
Since LEDE is targets not only routers anymore, but to a wider category of embedded devices with hardware that may be much different than routers:
Would it be useful to have a field "GPIOs" in the dataentries?
The number of readily accessible GPIOs could be a useful search criteria.
The conversion table I posted above moved to a new location and is waiting for filling. Once I have the relation OWrt vs. LEDE Instructionset, I will update the dataentries.
