I was debating for a while whether to start this topic or not. I'd like to preface this with that I understand this is a volunteer-based project, and more or less how it operates. My observations are mostly based around the packages repo. I don't want to point any fingers, and instead want to be help address the current situation.
I feel there's not enough attention given to reviewing new issues, which leads to users not reporting new issues and giving up on existing reports, and PRs with useful contributions bitrotting. Most PRs (in the packages repo) being merged are simple version bumps at the moment. Which are often reviewed and merged, by people other than the maintainers. As some maintainers have not been active for 1+ year. I understand the current reviewers (special thanks to @1715173329 for putting up with my PRs) are already stretched thin and and are understandably reluctant to dig into every bigger or unfamiliar PR. I've already tried to reach out to some of the inactive package maintainers, for which I'm trying to introduce changes, other than a version bump, with mixed results.
All of this leads to the current situation of close to 900 open issues and more than 300 PRs, some of them open for years, of undefined quality or relevance.
Instead of complaining, I'd like to at the very least volunteer myself both for reviewing/tagging new issues and PRs. However, I lack the necessary permissions and, let's face it, trust.
Part of this could be addressed with improved automation, where issues that are marked as waiting for details, are closed after a period of inactivity.
Another controversial option could be having a list of packages with designated maintainers who have not contributed for some time (say a year), and look for new ones or co-maintainers. This is especially relevant for packages with a single maintainer.
Either way, I'd like to hear some thoughts, especially from people who are actively contributing.
Well I can understand your frustration I have made a couple of PR's which were merged after some time but also have an open PR now already for more than 3 months (regarding adding source port to netifd).
So we sure could do with more maintainers, problem is how can we screen the maintainers to be, they can tinker with our source code so they not only have to be reliable but also knowledgable.
How to check?
How has that been done in the past?
Which is perfectly valid, and while it took three stable releases to happen it made sense.
There's stuff like @bluewavenet mesh11sd hitting a major milestone and the current package in stable not being the latest.
There's a bunch of devices that need testing and clarifying.
There's some PRs that are really bad and need rejection with a template and the submitters need to follow the guidelines.
I'm happy to volunteer to help with device submission as it backs on to the wiki and the toh.
The problem there is not getting the backport merged through lack of review, but rather, the CI on Github for 24.10 packages in openwrt/routing has been broken for over a month now, so nothing can be merged without "bending the rules".
So tricky problem. Someone will have to create a PR for the fix for the system that checks out PRs....
My 2 cents: on one hand, obviously there is not enough workforce to adequately manage the PRs. On the other hand, people are fairly frequently offering help. I may be wrong but to me it seems that for some reason, these 2 things do not connect. I.e. help offers are either unnoticed or ignored or rejected. If this is the case then the project leadership needs to really think how to handle this and perhaps implement a process which would allow volunteers to participate, and perhaps reach out to the community when help is needed.
It should be enough to report the breakage, so in this case, I would look into .github folder and there find .github/workflows/multi-arch-test-build.yml, which points to openwrt/actions-shared-workflows/.github/workflows/multi-arch-test-build.yml@main, so I would report the issue in https://github.com/openwrt/actions-shared-workflows/issues
There are literally hundreds of events generated every day on the PRs, its impossible to find out about such issues, one would need to read every comment. Creating an issue causes different event/notification, so it should be easily spotted. Using a proper, descriptive issue subject helps a lot with work prioritization as well.
Could you maybe share your opinion on the OP's post and on my comment? I feel that the community could take a much more active part in the project, including helping out with PR's, but because of something that I (maybe wrongly) see as lack of interest to organize this, that is not happening, which IMO is very detrimental to the project. Is this issue visible to the core team at all? If so then what's standing in the way of having someone who would take the role of engaging with the community on this?
As @Dante pointed out, the main issue here is trust. However, "untrusted" people could still help by weeding out bad issues and by supporting PRs to get them ready for final review.
Trust is a problem with virtually every large'ish open-source project but this can be solved, as demonstrated by projects like the Linux kernel. That project wouldn't have gotten even remotely as far as it did without being structured in a way that allows the community to participate. What's stopping OpenWrt from adopting a similar approach?
I think that the discussion here does highlight some of the difficulties with FOSS projects in general and OpenWrt specifically. There are certainly some bugs and feature requests (including 'ready to go PRs') that have really high latency in terms of developer responses. But, this is a volunteer project and the dev team (as well as several other teams) are busy working on lots of other things (and their personal + professional lives, too).
But, I honestly don't have much to add here. Why? Because I am not a developer, and I'm not "in charge" when it comes to development priorities, and I certainly can't tell anyone what to do (nor would I want to).
For reference, while I'm always happy to help where I can, I am an admin of the forum side only. I have standard edit privileges for the wiki (not admin level), and I don't have any special access to any other systems. I'm also not a developer and I don't have voting rights or PR approval status in the developer community.
