Information in the wiki is not up to date, e.g. does not reflect the current state of the package and its available configuration options
Information does not show the OpenWrt version it applies to and multiple versions of the same information are not supported
Solution:
Place documentation for the packages with the packages in the git repository - this ensures it is updated, when the package is updated as part of the PR review process
Generate documentation website automatically from documentation files for different branches (main, 24.X, 25.Y, ...)
There is no technology set for the implementation of the solution. I'd rather open the thread to discussion on the general idea first and once that is settled and hopefully accepted, another brainstorming can go on for the technological implementation.
What do the experienced OpenWrt members, developers and users, think about this?
Yes. I have done this with the openNDS package. It is not integrated in any way with OpenWrt, as no standard integration route is available, but is an example of what can be done.
These are good ideas. That said, my suggestion to improve documentation goes beyond solving the 2 specific problems you identified. There are a lot of issues with the documentation in its current state. The 3 most significant issues (at least for me) are:
Documentation is spread across quite a few resources, especially documentation for developers.
So these are 5 separate locations to look for information, and then some of the information between those sources will be duplicate, some will be complementary, some will be conflicting and some will be missing or outdated. So typically one would also need to cross-reference the information with the 6th source: the forum. Then if you are new to OpenWrt, you will also be expected to learn from existing packages, and from previous PRs on Github to figure out how to construct the Makefile and how to submit a PR.
All this makes it extremely time-consuming, especially for people who are new to developing for OpenWrt.
Much of the documentation is outdated, without being clearly marked as such, which causes people to waste their time trying out things which are known not to work.
While probably it's hard to find someone who would want to proactively maintain the documentation, it could be maintained by the community, however there appears to be no established process for that. So when someone finds an issue in the documentation, they don't know what to do in order to get it fixed. So it doesn't get fixed.
I understand that this is a volunteer project and everybody does what they like, and no one is responsible for making the project easy to use and contribute to. I'm just pointing out the issues that I'm seeing, in case someone does want to put their time into improving the situation.
Fully agree, I like if processes are in place and they are easy to access. For example, I know some projects where each documentation page has a "report an issue on GitHub" link at the bottom or somewhere prominent.
Also using GitHub there are various ways to provide issue and PR templates and automated checks using workflows or bots. Also, GitHub provides a lot of their features for free on public repos and even more features to accredited OSS projects, which OpenWRT could clearly be. Just thinking beyond the docs, there is automated security vulnerability scanning, which was mentioned in the other thread about the future as well.
But I don't know how interested the project is in using more of GitHub's features, since their primary method of communication, as far as I understood, is the self-hosted git and the mailing list(s).
The built-in wiki search is very poor, which makes discovery of what you're looking for far too much work. This cascades into lack of maintenance, because if you can't even find an outdated page to begin with, there's no chance you could update it.
Maybe simply partitioning it to "wiki-only" and "toh-only" would help a lot, as most often my results are overwhelmed by hundreds of ToH topics that I don't care about.