As an aside, it would be cool if instead of fixing broken db reports, community tech turned them into query special pages.
Every db report is in essence a band-aid solution to MediaWiki software failing to give users the data they need.
Additionally, if its a real special page, its much more likely not to broken in the future.
No, I mean like https://en.wikipedia.org/wiki/Special:LongPages, https://commons.wikimedia.org/wiki/Special:GloballyWantedFiles, https://commons.wikimedia.org/wiki/Special:MostGloballyLinkedFiles, https://en.wikipedia.org/wiki/Special:UnusedFiles . QueryPage is the name of the class in MediaWiki that handles special pages which are essentially database reports (Special page that is essentially just the output of an SQL query, and depending on how long the query takes, also has the logic to run and save the query at regular intervals instead of just doing it on the fly).
Most database reports exist because historically the average user lacked knowledge/ability to get code into MediaWiki. It would be great if the more generic db reports could be folded into MediaWiki so that all MW users could benefit from them (among other reasons). It would be cool if the wiki[pm]edia specific db reports could be turned into query special pages as part of some extension (or WikimediaMessages)
That sounds like a good idea. It'd be great if you can file a request for it when our Community Wishlist Survey opens up. This will allow us to prioritize it and work on it officially, once it's been approved by the community.
This task was meant to be a quick-fix to some more important broken reports only and we don't intend to fix every broken report (>20 of them) right now unless it's specifically asked for by the community.
The thought had occured to me to make these into query pages, but like Niharika said, this was intended to just be a 'quick fix' project. Adding new query pages is easy technically, but in practical terms it takes a fair bit of time and work to get anything into core (security and performance reviews, discussions with the communities about implementation details, etc.). Clearly though, implementing these as query pages would have a much more positive impact on the projects. Perhaps we could identify some high priority reports to suggest as projects during the community wishlist survey (or at least to create Phabricator bugs for in case someone has time to do them).
but in practical terms it takes a fair bit of time and work to get anything into core (security and performance reviews, discussions with the communities about implementation details, etc.)
So basically, we're going to prioritize short term fixes over long term proper solutions, because our code review system is too much of a PITA? I would be angry about that if I wasn't also sympathetic to how much of a pita code review is.
but, for the record:
- Security review - you don't need a separate security review for adding a random special page to core. Review for security is no harder then a normal review in this context
- Performance review - there's a reason these special pages run on a separate db slave. (It does have to be handled slightly differently if they take more then 15 minutes to update)
- community review - Not like you're proposing a new interface. The implementation details in MediaWiki have been pretty much settled since they were committed on Dec 1 16:04:35 2003. That's more than a decade.
@Bawolff: It's important to understand the context of our work on this. The Community Tech team works on requests as they are prioritized by the community through specific input processes (See https://www.mediawiki.org/wiki/Community_Tech_team#Work_input_and_prioritization_process). These processes include explicit evaluation for support, impact, feasibility, and risk (See https://www.mediawiki.org/wiki/Community_Tech_team/Community_Wishlist_Survey#Analysis_and_prioritization for example). Rarely, we will also work on small tasks outside of those processes if something is completely broken and it's relatively trivial to fix and well-defined. (For example, we helped to fix some of the gadgets that were broken by recent ResourceLoader changes.) The broken database reports fit those criteria and also were a good opportunity for our developers to learn about bots, so we decided to make an exception and fix them. In most cases, we will prioritize the solution that has the most long-term benefit, but occasionally we're just going to slap a band-aid on something because the community asked us to and the band-aid is cheap. This task was one of those occasions, but it should not be considered indicative of our team's normal workflow.
@NiharikaKohli: It looks like the old report included the number of links and imagelinks in the output (which is useful for prioritizing which ones to delete). It should be pretty trivial for us to add this information as well.