Make PageTriage wiki agnostic
Open, Stalled, Needs TriagePublic

Description

Other non enwiki wikis want it


Version: master
Severity: enhancement

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

This proposal received 21 support votes, and was ranked #42 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Moderation_and_admin_tools#Special:NewPagesFeed_in_every_language

Todo list:
Add the following options to MediaWiki:PageTriageExternalDeletionTagsOptions.js:

  1. Option to disable "Proposed deletion" (PROD) functionality
  2. Option to disable "Articles for deletion" (AFD) functionality
  3. Option to disable "Criteria for speedy deletion" (CSD) functionality
  4. Variable to specify where the main page for AFD is.
  5. Option to disable warning the creator of said page of the deletion (usecase: Wikidata)

Details

Reference
bz48552
There are a very large number of changes, so older changes are hidden. Show Older Changes
bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:41 AM
bzimport set Reference to bz48552.
bzimport added a subscriber: Unknown Object (MLST).
Reedy created this task.May 16 2013, 10:42 PM
  • Bug 48553 has been marked as a duplicate of this bug. ***
Qgil added a comment.Jun 5 2014, 3:39 PM

[[mw:Extension:PageTriage]] says "... the extension is pretty much impossible to internationalise: developing a universal, stripped-down version is on our to-do list."

Any news on this front?

Could we separate parts of the API out from the module, as the API currently doesnt have a good 'newpages' feed afaik.

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptMay 16 2015, 6:11 AM

@kaldari Hi, could you give a small update on this matter: if volunteers want to port PageCuration to be usable on other wikis, what main steps are required?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 19 2015, 3:50 AM
Qgil removed a subscriber: Qgil.Sep 29 2015, 10:16 AM
Luke081515 raised the priority of this task from Lowest to Needs Triage.Oct 18 2015, 2:00 PM
Luke081515 added a subscriber: Luke081515.

I think this issue is more important, because there are seven wikis at the moment, that are waiting for this extension

@Luke081515: I don't think that resetting the Priority field will trigger a potential discussion here or make someone suddenly work on this. See https://www.mediawiki.org/wiki/Collaboration for some contact info and focus/roadmap...

I think, it would be the best, if someone from Collaboration-Team-Triage explains, why this extension is not activable at other wikis, than maybe a volunteer can fix this, and we have one problem less.

https://www.mediawiki.org/wiki/Extension:PageTriage says "some of the configuration and code is specific to the English-language Wikipedia's workflows and as it's constructed now the extension is pretty much impossible to internationalize"; https://www.mediawiki.org/wiki/Collaboration has contact info.

PageTriage is essentially abandonware at this point. The grand plan is to design a workflow system (as mentioned here) that lets wikis design their own localized workflows, rather than building extremely specific tools like PageTriage.

He7d3r added a subscriber: He7d3r.Nov 10 2015, 5:45 PM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 10 2015, 5:45 PM
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:53 PM
DannyH updated the task description. (Show Details)Feb 6 2016, 12:05 AM

I guess this is stalled, right?

Tgr added a subscriber: Tgr.Aug 5 2017, 4:07 PM

AFAIK no one is working on this (and its subtasks). But not sure if this 'can currently not be acted on' (which is the definition of 'stalled').

AFAIK no one is working on this (and its subtasks). But not sure if this 'can currently not be acted on' (which is the definition of 'stalled').

Might be another FlaggedRevs case, isn't that?

The problem with PageTriage and FlaggedRevs is that they need to be rewritten from scratch and they hit a point of technical debt that almost any type of improvement to them is practically impossible, now we have another problem: If we want to rewrite something, it needs developer time and without proper justification, you can't get resource to do that. In other words, this task is too expensive.

These are all my opinion and I'm not reflecting anyone else's or any organization's.

Who exactly decides that a development requirement is 'too expensive' ?

The developers of the component in question, I'd imagine.

Tgr added a comment.Aug 6 2017, 8:32 PM

Is there a summary of what exactly would need to be changed to make PageTriage work with other wikis?

The problem with PageTriage and FlaggedRevs is that they need to be rewritten from scratch...

Why? The only real issue with making PageTriage wiki-agnostic is figuring out how to support totally different deletion workflows on different wikis. The rest of it is already wiki-agnostic.

One solution would be for those other wikis to adapt their workflow to that of en.Wiki. Our en.Wiki worklfow is nevertheless surprisingly straightforward.

If you consider PROD/BLPPROD + AfD/XfD + speedy deletion "straightforward" :)

Yes. Those are pretty straightforward. I helped get one of them created. The problem is in the cognitive approach to using them - despite our efforts, a lot of people are still allowed to use these mechanisms without any knowledge of the policies that govern them. AFAIK, all Foundation Wikis have policies, and generally the same ones that are part of the basic WMF manifest. It's difficult to know what to do without introducing even more layers of bureaucracy - even at the lowest level.

Reedy removed a subscriber: Reedy.Aug 17 2017, 1:09 AM

Please, no en.wiki-centric discussion here. If you want to discuss the merits of each system, please go on the village pumps for the interested wikis (that is {id,et,fr,ur,ar,fa}.wikipedia). See links at https://meta.wikimedia.org/wiki/Distribution_list .

Why? The only real issue with making PageTriage wiki-agnostic is figuring out how to support totally different deletion workflows on different wikis. The rest of it is already wiki-agnostic.

I tried hard to make this happen as people in my community are also pushing for something like this in Persian Wikipedia but there is no proper layering, no proper tests, lots of use of deprecated (or semi-deprecated) methods that makes it really hard to clean or fix without rewritting the whole thing.

Same goes for FlaggedRevs when I tried to make it to use OOjs UI

@Kudpung Unfortunately the PROD is considered as duplicated with AFD in at least zhwiki, so applying enwiki mode globally is indeed not acceptable

I wasn't discussing whether or not these features are acceptable . It is perfectly feasible to technically exclude prod from the dropdown list of actions.

If the problem is the deletion options part, we could maybe make those per-wiki configurable via on-wiki MediaWiki pages?

The problem with PageTriage and FlaggedRevs is that they need to be rewritten from scratch...

Why? The only real issue with making PageTriage wiki-agnostic is figuring out how to support totally different deletion workflows on different wikis. The rest of it is already wiki-agnostic.

Not only this, but also many features of PageCuration are ORES -overlapped

Liuxinyu970226 changed the task status from Open to Stalled.Sep 30 2017, 12:51 AM

Still no constructive suggestions happen

//In T50552#3529261, @kaldari wrote:

The problem with PageTriage and FlaggedRevs is that they need to be rewritten from scratch..//.

ORES is not implemented on en.Wiki for new pages. Moreover it will take months if not years before it is. The requested solutions for 'enhancements' to the Curation tool are required now. The effort is to deploy Foundation staff from whatever department is now responsible - we have been told apparently that this is not the remit of the Wishlist team.

If Curation has to be rewritten, so be it, but keep its present look and feel and aim to produce the results as soon as possible please - like by the end of the year.

@MarcoAurelio's proposal seems to be the right one. As far as I know, most workflows for deletion involve:

  • A tag on the article, linking to the place where the discussion is held
  • A notification on the talk page of the user who made the article
  • Either:
    • A dedicated page like "Project:X/Articletitle" (e.g Commons:Deletion requests/File:Spam.png)
    • A section on a dedicated page like "Project:XY#Articletitle" (e.g Wikipedia:Files for deletion/20 September 2017#File:Spam.png), typically with Y being a date
    • No discussion at all (PROD and speedy processes)

Some workflows just involve putting a template on an article. In all cases, the content of tags/notifications/dedicated pages/sections is going to be the variable; other than that there are only 3-4 different systems involved.

Liuxinyu970226 added a comment.EditedSep 30 2017, 2:21 PM

@JEumerus

  • A notification on the talk page of the user who made the article

Not always, nominating deletions of Wikidata items do not require such notify.


Also, for several months I'm wondering why Collaboration team is "maintaining" MediaWiki-extensions-PageCuration related tasks, and are members of that really doing maintains? If there's benefit that this work must be continued, how about moving those tasks to another team?

@JEumerus

  • A notification on the talk page of the user who made the article

Not always, nominating deletions of Wikidata items do not require such notify.


Also, for several months I'm wondering why Collaboration team is "maintaining" MediaWiki-extensions-PageCuration related tasks, and are members of that really doing maintains? If there's benefit that this work must be continued, how about moving those tasks to another team?

They do work on some tasks there. I generally have better success getting things worked on by directly talking to a member of the Foundation staff before or shortly after I've placed the task in.

@Kudpung: I'm afraid most software development/design/research projects/teams won't be able to spontaneously drop any other plans for the next weeks. So your contributions are welcome as soon as possible please - like by the end of the year.

@Liuxinyu970226: The term "maintaining" covers a pretty wide spectrum, between "fix every sensible issue" to "only make sure the service in its current state keeps running".

@Kudpung: I'm afraid most software development/design/research projects/teams won't be able to spontaneously drop any other plans for the next weeks. So your contributions are welcome as soon as possible please - like by the end of the year.

We've been waiting SIX years for these 'hacks'. We volunteers are the people that provide the content and keep it clean. I suggest the Foundation IT staff meet their obligations and provide us with the equipment to do it. To assume that we are all computer freaks is insolence and does not help here - some of us are more qualified in our fields than you are in yours.

As a former software developer, I take great umbrage at the phrase "computer freak" to describe folks who develop software.

Volunteers come in all shapes and sizes. A lot of the folks who work on Wikimedia software are volunteers, and I think we should honor them. Part of honoring them is showing patience, and trying to convince them via reason and not insults to increase the priority of any given task.

And no, it's not insolence in any way to suggest to folks that they are welcome to contribute to software development work. If something is *that* important to you, maybe learn how to do it yourself.

Also, I will note human nature, and developers who feel insulted will likely feel less interested in assisting on this, not more.

Liuxinyu970226 added a comment.EditedSep 30 2017, 10:48 PM

@Kudpung: I'm afraid most software development/design/research projects/teams won't be able to spontaneously drop any other plans for the next weeks. So your contributions are welcome as soon as possible please - like by the end of the year.

We've been waiting SIX years for these 'hacks'. We volunteers are the people that provide the content and keep it clean. I suggest the Foundation IT staff meet their obligations and provide us with the equipment to do it. To assume that we are all computer freaks is insolence and does not help here - some of us are more qualified in our fields than you are in yours.

Oh please, do not try to explain that you're encouraging to deploy this on zhwiki or any of Chinese-Sites. Although there's discussions about it, this extension could also meet language conversation problems.

Tgr added a comment.Sep 30 2017, 11:20 PM

@Kudpung it seems like you are talking about something other than making PageTriage available for other wikis; you have more chance of getting developer attention if you comment in the task you want fixed. Also (as you no doubt know since you have participated last year) the Foundation runs a survey of technical wishes these days, and requests that rank highly tend to get resolved fairly quickly. The surveys are done towards the end of the year so I suspect the next one is coming up soonish; the productive thing to do would be to convince other Wikipedians that your software needs are important for the project and they should support it over whatever else they might want to ask for. Prioritization by voting is not perfect but a lot better than prioritization by who can shout the loudest.

Tgr added a comment.Sep 30 2017, 11:22 PM

As for this task, I still haven't seen any clear explanation of what needs to be changed to install PageTriage on another wiki, and developers can't really help without that. If no one has a good idea, maybe we could just enable it on one of the beta sites and test?

I am fully aware that this Phab task is due to a request on the Wishlist to port Curation to other-language Wiks. That's not why I am here. I am here because Wishlist rankings are being used as an excuse to not address the needs of the en.Wiki.

Furthermore, as I have stated several times, Curation is an essential, critical core process - look at it if you will as being as important as having an editing window. It is a significantly higher priority than the Wishlist for convenience gimmicks and gadgets - which, and I will also mention again, the Wishlist team have clearly expressed that Curation features are not within their remit.

It is quite obvious that one of the problems here very often at Phab is that people play 'pass the parcel', and if no one wants it, its status is conveniently changed to 'stalled' while Wikipedia volunteers are provided with no other official channels for getting urgent requirements attended to.

@Kudpung

I am fully aware that this Phab task is due to a request on the Wishlist to port Curation to other-language Wiks. That's not why I am here. I am here because Wishlist rankings are being used as an excuse to not address the needs of the en.Wiki.

Still, as Nemo bis warned you above, please do not make all Wikipedias as fully following enwiki

Furthermore, as I have stated several times, Curation is an essential, critical core process - look at it if you will as being as important as having an editing window. It is a significantly higher priority than the Wishlist for convenience gimmicks and gadgets - which, and I will also mention again, the Wishlist team have clearly expressed that Curation features are not within their remit.

This is not wanted on zhwiki, so do not say it as "essential, critical", wikis can still alive without that

It is quite obvious that one of the problems here very often at Phab is that people play 'pass the parcel', and if no one wants it, its status is conveniently changed to 'stalled' while Wikipedia volunteers are provided with no other official channels for getting urgent requirements attended to.

The most big problem is not some playing, is how to handle the entire different patroll environments between different wikis

Tgr added a comment.Oct 1 2017, 1:16 AM

I am fully aware that this Phab task is due to a request on the Wishlist to port Curation to other-language Wiks. That's not why I am here.

That's why everyone else is, though. So please respect that, and if you want some changes in PageTriage that are not related to making it work on other wikis then find or file a different task.

It is quite obvious that one of the problems here very often at Phab is that people play 'pass the parcel', and if no one wants it, its status is conveniently changed to 'stalled' while Wikipedia volunteers are provided with no other official channels for getting urgent requirements attended to.

I'd say the official channel is to file a task about the changes you need, set a high priority, explain why you think it's a high priority, and make sure the relevant team is added to it (that's probably Collaboration-Team-Triage in your case). If that doesn't work, contact the product owner of the team directly. (If that doesn't work either, then - short of applying for Dictator of the Wikimedia Movement - you are probably out of luck.)

Gergő Tisza, did you actually read what I posted? You are indeed using this task as the very reason for stalling all the other work that needs doing on Curation for en.Wiki that has already been posted for months on other Phab tasks. Your comments are really not helpful, but it's what we had already come to expect at Bugzila, and now at Phab.

Perhaps what is wanted is to allow page curation to supports variations on the workflow I proposed above. That would mean Page Triage, but with the messages/tags/notifications customizable (including no notification). And where a deletion discussion is posted would also be customizable. And how many iterations of these workflows are possible. I don't know if this all is technically feasible.

I don't know if this all is technically feasible.

Well somebody must know. Otherwise it's back to 'pass-the-parcel'. We need some help here. Perhaps the people who developed Curation should know - such as Kaldari, but he claims it is no longer his remit.

Snaevar updated the task description. (Show Details)Oct 1 2017, 3:35 PM

Perhaps what is wanted is to allow page curation to supports variations on the workflow I proposed above. That would mean Page Triage, but with the messages/tags/notifications customizable (including no notification). And where a deletion discussion is posted would also be customizable. And how many iterations of these workflows are possible. I don't know if this all is technically feasible.

It is feasible, in my opinion (as a developer who worked on the extension many years ago).

@Kudpung: The bug about adding ORES to Page Curation is T157130.

Liuxinyu970226 added a comment.EditedOct 12 2017, 10:42 AM

@Snaevar I'm afraid just modifying a js file won't be helpful in any case (if just do it can rewrite workflows then I will just submit a patch for this task). And even you did this, there could also have many other compatibility blocks such as in StructuredDiscussions, MediaWiki-Language-converter, RTL...