I was also considering the difference in the experience of filing a bug against MediaWiki vs my recent experiences filing bugs against the Gerrit code review tool for git. In the latter case, I spoke directly with a core developer about the issue, and proposed solutions. After figuring out what was a bug and what wasn’t, and what direction the solution should take, I filed bugs with those details. In comparison, filing a bug against MediaWiki provided (in most cases) zero feedback until months down the road – often that feedback is that the issue won’t be fixed. Instead, we should try to provide immediate feedback on every bug as they are filed – in particular whether the bug is accepted or not. Even better would be providing an opportunity to figure that out before the bug is even filed. I can’t immediately think of something more disheartening than having your bug rejected, or simply ignored. This is especially true for UX issues, which until recently have not been taken seriously. Even now, UX work is focused on the vector skin, and maybe a bit on FlaggedRevs (now that enwiki is involved, UX issues might be taken seriously – nobody cared about these problems earlier). This role could be filled by whoever is tasked with the “development community co-ordinator” and could make a big difference in how our tracker is used.

Finally, we need to ensure projects like AbuseFilter or LQT are taken to completion. Currently these projects lack polish (to be fair, LQT is still in the works), simply because the UX issues can be swept aside as insignificant in comparison to completing the core development. That isn’t good enough & the Foundation should be providing guidance with the aim of completing that missing polish.

Martin

Last month, I reported a wish concerning this tool on the KDE Bug Tracking System.

I also watch your roadmap page on Commons.