Thanks for the consideration @richb-hanover. It's not just for myself, but also the other potential contributors out there that are likely frustrated as well.
I've been using OpenWRT since the original WRT54g and White Russian in multi-AP configurations, hard-wired in the early days, moving to WDS, and now 802.11s. I take copious notes of configuration and would like to be able to save others the time of finding out all the things that don't work, especially when it is so difficult to find documentation, even around UCI parameters. Even when an appropriate page is found, it is often incomplete, outdated, or flat-out wrong. As a specific example, I could not find any documentation on the parameters around switch configuration (yes, I added the section that is there now).
So as to the "what" it would be trying to organize and clean up the UCI documentation so that, for example, a user could find a page on /etc/config/network and have a clear, current, complete, and correct definition of what the various sections are, what the options available are and the range of valid parameters, and what each option actually does. Personally, moving the "examples" and "how to" sections out of the "man page" and into appropriate locations would make configuration a lot easier. I understand the "customers" that find LuCI sufficient for their needs, but there are many things that can't be configured in LuCI, especially for sophisticated users. Those are the users that drive technical innovation within OpenWRT.
Past that, documenting in a series of "How to" articles:
- Setting up "dead-end" IoT networks
- Supplying limited services and limited outside connectivity to IoT devices
- Configuring 802.11s
- Configuring bridged VLANs over gretap (over 802.11s)
As a product manager for enterprise software by trade, I understand the value of good documentation. That value is not only for those using the software, but also those considering their options. While OpenWRT is not a commercial product, there certainly are commercial entities that consider it for and may choose to use it in their embedded systems. Getting "return" from these professional endeavors can enhance OpenWRT, but only if they choose it over the alternatives.
Alternatives like FreeRTOS (now unencumbered by GPL with its acquisition by Amazon) running on ARM and the various derivatives are challenging the position of embedded Linux, especially with SoCs now providing TLS-enabled, IPv4/6, 802.11 stacks, and BLE stacks. Yes, these companies do give back, even when the license terms don't require them to do so. The powerful netgraph infrastructure in FreeBSD is a specific example I've been utilizing for years -- contributed by Whistle Communications even though there was no requirement in the BSD license to do so.
As a professional, looking at the OpenWRT documentation, which is only the Wiki, would I have confidence that my development team could work with it? In the state it is in, no. When I look at, for example, http://www.ti.com/product/cc3220 and the associated RTOS documentation, as a professional, I have a lot more confidence that my team could execute on scope, schedule, and cost.
Let's not lose the potential of professional contributions before the window of opportunity closes. Yes, there is a lot of good work among decade of contributions there. Please make it easier for those willing to try to make it both more usable and more professional to help the community in general.
Edit: To be clear, WYSIWYG editing would be sufficient. I switch between various flavors of Markdown and Confluence multiple times a day at work. It's seeing that I've got the wrong syntax as I type that makes it less problematic. I can quickly try something else and, for example, figure out how to type either <done> or <done> without having it converted to an HTML tag. It's also dealing with tables, that impossible for most humans to comprehend in any markup, and core to so much of the OpenWRT documentation, that is made so much easier with a "live" preview.
