Major overhaul to Special reports
Closed, DeclinedPublic

Description

For a variety of reasons many of the special reports have become useless and some projects have been forced to create their own custom reports such as database reports or through means of the WMFLabs/Toolserver. I recommend a complete overhaul be done to the way these reports are generated that would allow some role within a user community (like Admin or template editor) to be able to modify the code that drives these special pages. Some functionality I think would be useful to do should include:

  1. The ability to hide reports from the list of those displayed if they aren't relevant to the project
  1. Add new reports under some type of custom section
  1. Be able to modify the criteria that is used to generate the reports.
  1. Have more flexibility to expand the length of a report even if that is to break it into 1000-2500 article chunks across multiple pages.

Of course this is just a short list and more detailed requirements and analysis of the problem would be needed. Some things have already been suggested here as minor changes to individual reports or other utility changes but what is really needed is a complete overhaul of the way the Mediawiki system creates and handles reports.

Reguyla (talk) 14:48, 26 August 2015 (UTC)

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 0 support votes, and was ranked last out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Miscellaneous#Major_overhaul_to_Special_reports

DannyH created this task.Dec 5 2015, 12:45 AM
DannyH updated the task description. (Show Details)
DannyH raised the priority of this task from to Needs Triage.
DannyH moved this task to Wishlist 51-on on the Community-Wishlist-Survey-2015 board.
DannyH added a subscriber: DannyH.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 5 2015, 12:45 AM
Krenair added a subscriber: Krenair.

allow some role within a user community (like Admin or template editor) to be able to modify the code that drives these special pages

This sounds like a terrible idea

Yeah, it's not getting much support on the survey.

Bawolff added a subscriber: Bawolff.Dec 5 2015, 9:46 PM

Yeah, it's not getting much support on the survey.

allow some role within a user community (like Admin or template editor) to be able to modify the code that drives these special pages

This sounds like a terrible idea

Regardless of level of support, that sounds like a terrible idea and should be considered WONTFIX.

However the rest of this bug is ok... having some special page reports be more customized to specific needs would be nice. I consider most example of tool labs db repotts to be signs that mw has failed our users

I'm not sure what #4 would look like, but how would #2 and #3 be possible without that?

Hoi,
Merge into MediaWiki is always a bottleneck. Decentralized services like Quarry always win because they are not bottlenecks.

I meant, as users demand things, we should add new special report pages, just like any other feature request. There could also probably be a lot of benefit to having a custom per-project extension of useful db reports.

I'm not really sure what 4 means either - maybe have better paging than limit/offset, or just increase $wgQueryCacheLimit

Hoi,
Merge into MediaWiki is always a bottleneck. Decentralized services like Quarry always win because they are not bottlenecks.

Sure. same thing could be said about tool labs in general, and new features. Once it becomes clear that a particular quarry usage is popular, I'd take it as a good sign that that particular usage is really useful, and a good candidate to implement in core.

csteipp edited projects, added Security-Team; removed Security.Dec 8 2015, 10:10 PM
csteipp set Security to None.
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptJan 21 2016, 2:52 PM
DannyH updated the task description. (Show Details)Feb 6 2016, 12:34 AM
Bawolff closed this task as Declined.Sep 4 2018, 3:39 PM

The ability to hide reports from the list of those displayed if they aren't relevant to the project

File a bug if you want this. I think its easily do-able

Add new reports under some type of custom section

People can write extensions. File a bug if there's anything specific.

Be able to modify the criteria that is used to generate the reports.

We're not going to let users write arbitrary SQL. If there are specific options people want, file a bug.

Have more flexibility to expand the length of a report even if that is to break it into 1000-2500 article chunks across multiple pages.

I have no objection to increasing length. Its currently controlled by a config variable. If increased large enough, we may need to rewrite the paging code. File a bug if you want this.

Declining. If you want any of the individual things, file an individual bug with more details.