Watching an open-source project from the outside is a bit like seeing how the sausage is made—it’s a complex process that isn’t always pretty! 
Regarding the 0. Needs triage label: in my experience, it doesn’t mean the issue hasn’t been read. It usually just means the next step is still being determined, or it’s not yet clear if it’s a reproducible bug versus a configuration error.
Software is never perfect, and there’s always more work to be done. However, many reported issues aren’t actually bugs. I often see a mix of:
- Configuration matters that are better suited as support requests.
- Rare edge cases that affect a tiny fraction of users.
- UI/UX feedback or documentation refinements.
- Symptoms of broader architectural work or technical debt cleanup already in progress.
Prioritization generally goes toward issues impacting the largest segment of users, or matters of interest to the developers stepping up to do the implementation. It’s also easy to underestimate the work required to fix a problem without causing “collateral damage”—like breaking existing deployments, introducing new side effects, or needing to update extensive test suites.
For context, the last time I ran the stats, there are about 10k issues closed out annually across the project. At least half of those are tagged explicitly as bugs. And that’s not counting all the other bugs and UX refinements that get addressed directly through pull requests without an associated Issue (for example: I often fix bugs or address confusing UX matters that I run across as recurring themes here on the forum).
I assume that most of the issues are not real bugs… but nevertheless, there are bugs where the community has the feeling that “this really needs to work” are drowning.
If only the community spoke with one voice! Every individual has their own favorite priority area. Often, there is work happening behind the scenes—like the architectural shifts I mentioned—that eventually addresses those bugs as part of a larger move from point “A” to point “B.” Other times, well—yes—there’s always more that could be done. 
I should start to contribute and be part of the solution, which is for sure and I am checking how to do this.
You’d certainly be welcome. There are many ways to contribute, ranging from direct development to triaging Issues (reproducing, following up for missing information, de-duplicating, connecting dots between different Issues, etc.), improving documentation (coverage, organization, clarity, accuracy), testing/reviewing pull requests, translating, and more.
Because I can’t resist, I’ll also highlight one of the most needed areas in my opinion: testing betas and release candidates heavily. This means testing in diverse environments, with various app combinations (particularly community-maintained ones), and across different upgrade paths. I mention this because:
- It’s a vital quality assurance mechanism that automated testing can’t fully replicate.
- My observation is that far more people are willing to install
x.0.0 releases than betas or RCs. Unfortunately, this means a lot of QA ends up happening during the x.0.0 to x.0.2 maintenance cycles rather than earlier.
- It’s much easier today to set up testing/staging deployments using containers or VMs if you don’t want to risk your real data.
- We should all be good admins and have well-tested, streamlined backup and restore processes anyway!
So I’d like to see a balanced assignment of developer resources (feature vs. bug), a transparent, efficient and effective bug triage process and the awareness, that trust (however it is build) is always the biggest part of any decision.
I completely agree that transparency is key to building that trust. In that spirit, I keep meaning to clean up and publish my ad hoc project statistics dashboard to help make some of this high-level activity more visible.
The data is essentially all “there” on GitHub, but unless you’re active, it’s hard to have a good grasp of where to look (beyond just seeing how many issues are open, which lacks the depth needed to truly assess things). For a quick look at the activity level, you can check out the Insights → Pulse section in each repo (for example, here is the monthly Pulse for nextcloud/server), though it lacks project-specific refinement and cross-repo insight.
Another area that I think could really help on the transparency front is ensuring there are both changelogs and release notes available for everything possible—and that raw, dev-oriented changelogs are converted into a form more useful for admins. This happens for critical items, but a lot of work (both bug fixes and refinements) is often inadvertently less visible to those not involved in development—and even to those that are, as the project is massive with hundreds of active repositories!
I’ll plug one area I was experimenting with recently: adding release notes for the documentation itself. I think a lot of work there is currently “invisible,” and admins (and app developers) would benefit from seeing those updates. Here are some initial iterations for recent documentation releases for the Admin, Developer, and User Manuals.
You already reported it.