In preparation for T193782, we need to think through what it will take distinguish "submitted drafts awaiting review" from all drafts so that they can be displayed as such in the New Pages Feed interface.
The background is that new users create pages in the draft namespace, but then go through a separate step to "submit" them for review by Articles for Creation (AfC). This step applies a template and category to the draft. Those submitted drafts await review by an AfC reviewer, who can accept them and move them to the main namespace, or can decline them and send them back to the author for improvement and resubmission.
One additional element is that we want to prevent multiple AfC reviewers from reviewing the same draft at the same time. The gadget that most AfC reviewers use, AFCH script, allows users to mark drafts as "under review", which could be used to prevent other reviewers from selecting that draft.
Therefore, there are two main user stories here are:
- As a reviewer, I need to be able to filter to only those drafts that have been submitted to AfC and are awaiting review. This would include drafts that are awaiting their second, third, etc. review, but it would exclude drafts that have been submitted for review, have already been reviewed, and awaiting resubmission by their authors.
- As a reviewer, I need to not accidentally attempt to review a draft already under review by another reviewer.
Some technical considerations that have been brought up so far in discussion of these user stories (though there are likely many more):
- What work will it take to identify which drafts have the status of "submitted and awaiting review"?
- Will we be able to exclude drafts under review from being present in the New Pages Feed list? Review typically takes only a couple minutes, so this type of exclusion would essentially need to be realtime.
Deliverables
- Create list of Phab tickets for a rough implementation plan
- Identify & document any dependencies and risks
- Answer technical consideration questions above.
Investigation:
The {{AFC submission}} template is put on drafts (in any namespace but usually Draft), and this puts the pages into Category:Pending AfC submissions.
They also get put into other categories in addition (but these do not need to be examined as they don't contain pages that are not in the above category):
- Pending AfC submissions in article space
- Pending AfC submissions in userspace
- Pending template and disambiguation AfC submissions
Some pages will also be in Category:Pending AfC submissions being reviewed now, and these pages should *not* be added to the queue.
We currently add to the page triage queue when a page is created (PageContentInsertComplete), moved (SpecialMovepageAfterMove), or edited (NewRevisionFromEditComplete), and add it if it's in one of the permitted namespaces (a some other checks). The namespaces are defined by $wgPageTriageNamespaces and are currently main (0) and User (2); we'd add Draft (118). There's no need to worry about NS IDs outside English Wikipedia.
This discussion has been around adding the Drafts NS, but perhaps what's actually needed is a 'Pending AfC submissions' filter? i.e. add to the list of 'Show' checkboxes in the filter a new 'Submitted pages'. (As well as an extra filter for NS, but that is not as crucial and could even be left out.)
How about this?— We add two new config variables: $wgPageTriageSubmissionsCat and $wgPageTriageSubmissionsInProgressCat, and hook on CategoryAfterPageAdded and CategoryAfterPageRemoved to add or remove pages from the traige queue when they're in the appropriate combination of categories. This would mean that pages wouldn't appear in NewPagesFeed while they're under review (although, is it meant to be able to do that live? that'd be a separate thing).
As for storing the status of the page, pages are tagged with some number of (pre-defined, boolean) tags. We'd add a new tag afc_status which would be toggled as required, and with which we could query the relevant pages.
There's certainly stuff that I'm not familiar with in the whole process, so please tell me where I've gone wrong in the above!