Wikipedia:Page Curation/2023 Moderator Tools project

The Wikimedia Foundation's Moderator Tools team spent time working on improvements to PageTriage between April and approximately September 2023. Though our efforts were focused on getting the extension to a place where it could be maintained by our team more proactively than it has been in the past, we also hoped to work on some user-facing improvements.

The focused project is now completed, but the Moderator Tools team will continue to maintain the extension and provide support to volunteer developers. We used this page to provide updates, pose questions, and solicit input.

In recent years the PageTriage extension has only been lightly maintained, if at all, by the Wikimedia Foundation. The reasons for this are that it uses outdated technologies for which engineering expertise has been lacking, currently only works on the English Wikipedia, and has been the responsibility of a team which has taken on the maintenance burden for a wide range of extensions (Growth). Despite this, we know that PageTriage serves an important function for what is the largest and most-viewed Wikimedia project, and we believe it should therefore be properly maintained and free of major bugs, in agreement with the 2022 WMF letter.

As such, we are aiming to work on a project between April and June 2023 which focuses on bringing the extension to a place where we feel confident that it can be maintained in the long-term. While we may address some new feature requests during this time, we are hesitant to add additional code to the extension without first addressing major technical debt, so this is unlikely to be the priority during this timeframe. We also want to note that our existing work may run over into April, so we might not be getting started right away in that month. Either way, we're aiming to spend 3 months on this project initially.

We will clarify the details of this project closer to April - as there is ongoing work by volunteer developers and some WMF engineers to address some of these issues already - but this project may include:

• Replacing outdated technologies (e.g. JavaScript frameworks) with more modern supported technologies (e.g. T208256)
• Improving test coverage and documentation
• Refactoring functionality to make the extension easier to maintain, extend, and re-use in the long-term
• Instrumenting data collection to better understand user workflows and how these change in response to improvements
• Addressing some high priority new feature requests

Because the extension repository is now quite active, especially with volunteer developers, it’s hard to be more specific about the work we’d take on. Before April we will meet with volunteer developers and WMF staff who have worked on the extension to understand the latest changes and come to an agreement on the highest priorities for our team's contributions.

In parallel, during this quarter, the Moderator Tools team will consult with other Wikimedia communities to understand their needs around content review and reporting processes. From our previous research we know that other communities have duplicated processes and volunteer tools to perform many of the same functions as PageTriage and New Page Patrol. As the team’s engineers learn more about the PageTriage codebase and what is possible from a refactor, we will be able to better understand the overlap between the functionality provided by this extension and the needs of other communities.

Towards the end of this quarter, we will reassess the situation to make longer-term plans for the following fiscal year. If technically possible, and we discover the potential for value in other communities, we may begin making PageTriage, or elements of it, wiki-agnostic.

We'll share updates on our progress here as and when we have them.

As we’re coming to the end of our time spent on dedicated work on the PageTriage extension I wanted to post a final update giving an overview of what we accomplished and what support from our team will look like going forward. As always, please share your thoughts and questions on the talk page!

As described above, at the outset of this project we decided along with community members that rather than simply adding new features to PageTriage in its existing difficult-to-maintain form, we wanted to make it easier for volunteer developers and the Wikimedia Foundation to improve PageTriage going forward. Therefore, we set out to address technical debt which had built up over the years. With outdated Javascript frameworks, low levels of test coverage, and a lack of maintenance, we wanted to tackle this project from the perspective of ensuring that PageTriage was more reliable to work with in the long term, not just adding a few new features and walking away, only to need to come back in a year because functionality had broken again.

Since February we:

• Researched the New Page Patrol process by interviewing active patrollers. This enabled us to develop a shared understanding of what the patrolling process entails, and we wanted to identify whether there were any high-priority workflow-breaking bugs being encountered by patrollers. The results of this research were published here.

• Rewrote Special:NewPagesFeed using Vue.js and incorporated some elements from Codex. This moves the extension away from old Javascript frameworks which are not commonly used in the MediaWiki ecosystem, instead utilising the framework which is becoming the standard for MediaWiki development. Updating to modern standards makes PageTriage easier to maintain, less prone to bugs, and enables us to leverage centrally designed and maintained UI components. This change has now been deployed, with minimal UI differences - please let us know if you encounter any bugs! (T324914)
  • We also started on a similar transition for the Curation Toolbar, however we were unable to finish this work due to time constraints. Once this is done, the overall transition to Vue will be complete for this extension. We will look for opportunities to spend some time on this, and are happy to support volunteer developers with code review. (T340130)
• Updated deprecated code - MediaWiki features are regularly deprecated in favour of new implementations, and we reworked a substantial amount of deprecated code in the PageTriage repository. This ensures that when this code is removed from MediaWiki, PageTriage will still function as expected. (e.g. T330690, T312480, T335749)
• Increased test coverage, to ensure that future code changes made by volunteers and staff are less likely to break existing functionality, and moved from QUnit to Jest as the Javascript testing framework.
• Ensured that PageTriage will continue to behave as expected with the introduction of temporary accounts (IP masking). (T337788)
• Fixed or provided code review for a number of miscellaneous bugs. (e.g. T315591, T339831, T336535, T333389, T331598, T344359, T156595)

Looking to the future, although our team doesn't expect to spend dedicated time on PageTriage in the near-term, we have taken over as official maintainers of the extension from the Growth team. In this role we expect to have more bandwidth for tackling high priority bug fixes, code modernisation, and will continue providing code review for volunteer patches or those from other Wikimedia Foundation teams, alongside our other work.

We want to take the time to thank PageTriage’s volunteer developers, particularly Novem Linguae, for their support on this project. A number of the highest priority bugs facing patrollers were fixed between the time the open letter was published and when our team got started, and you have all been great collaborators over the past months. We think this has been a great example of how Wikimedia Foundation and volunteer developers can collaborate effectively - it felt like we had an extended team of staff and volunteers working on this.

In the course of talking with PageTriage volunteers, ideas came up around improving how newcomers create articles in the first place. The Growth team has picked up those discussions, and you can join them here.

The Moderator Tools team will now be focusing our efforts on the Automoderator project, to support patrollers across Wikimedia projects by providing tools to automatically revert vandalism. While we expect this project will provide the largest benefit to other language Wikipedias that don’t have robust bots, we’re particularly interested in English Wikipedia’s perspective on this project given the longstanding benefits of ClueBot NG. We’d love to hear your thoughts on this on our local project page.

TL;DR: We need your help to test a new version of the NewPagesFeed. Head over to Special:NewPagesFeed?ui_version=1 to test it out, and report issues and feedback on the talk page or in Phabricator. The default experience of Special:NewPagesFeed is currently unchanged.

As part of our efforts to make technical improvements to PageTriage we have extended DannyS712's patch to migrate the NewPagesFeed to the Vue.js Javascript framework. Moving away from deprecated Javascript frameworks to a modern, MediaWiki-wide supported, framework makes PageTriage:

• Easier to maintain, because developers can use the same Javascript framework as is becoming the norm in other areas of the MediaWiki codebase and don't need to learn a new syntax.
• Less prone to bugs, because the code is laid out in a way which makes it easier to write tests for.
• Able to leverage the benefits of centrally designed and maintained UI elements from Codex. These have had a lot of design effort put in to them to ensure that they're accessible, function on a wide range of supported devices, and are properly internationalised.

Overall, this upgrade will make it substantially easier to build and maintain new features for PageTriage in the future, and less likely that errors will be introduced.

In moving the NewPagesFeed to Vue.js we have tried to retain the current visual layout and style as much as possible. Although some spacing and UI elements have changed a small amount, now using those centrally-maintained elements from Codex, you should find that the experience overall is the same as it has always has been.

The NewPagesFeed has not been updated yet - to test the new version you can head to Special:NewPagesFeed and use the ?ui_version=1 URL parameter (direct link). If you're not using this parameter, the feed should remain unchanged.

If you find any bugs with the new interface, or have strong feelings about any of the UI changes, please let us know on the talk page. We're already aware of a number of bugs, filed as subtasks at T324914.

We’re closing in on the end of our focused time improving the code quality, test coverage, and documentation of the PageTriage extension. We plan to post a full report of our work in the next update!

We’re really close to finishing the NewPagesFeed Vue patch - we’re making sure all the i’s are dotted and t’s are crossed in code review so that we can get it out for testing. I really hope to have a more concrete update on this soon!

Looking ahead to August, we’ll be wrapping up our core work on this project, and will be looking to ensure that PageTriage is ready for the changes coming with IP Masking. This will be focused on any technical migrations which need to happen, but please let me know if you think there are any features which will be less effective as a result of unregistered users using cookie-based temporary accounts rather than being IP-based. We can then look at prioritising bridging those gaps where possible.

• T325448: Consistently call phpunit functions in PageTriage
• T339799: Add Jest code coverage report somewhere
• T335749: Refactor ILBFactory $lbFactory to IConnectionProvider $dbProvider in ServiceWiring of PageTriage
• T339831: CurationToolbar gives "mw.pageTriage.contentLanguageMessage is not a function" error when trying to add a speedy deletion tag (fixed a bug introduced by previous patch; thanks to Jon Robson for the follow-up test addition)
• T340112: PageTriage: Add example jest smoke test for curation toolbar

• T324914: Add User:DannyS712/VueNPP.js to PageTriage repo
• T341313: Replace getPrimaryConnection and getReplicaConnection with $this->db in PageTriage tests
• T340126: SPIKE: Are undeleted mainspace articles added to the PageTriage queue?

Just a quick update this week. In the past two weeks we’ve been able to get a number of backend patches merged, improving testing and migrating to new code standards.

The NewPagesFeed Vue patch is still progressing well, albeit on a longer timescale than we'd hoped - thanks to DannyS712 for the valuable code feedback!

• T335542: Get Jest to run in PageTriage continuous integration
• T339831: CurationToolbar gives "mw.pageTriage.contentLanguageMessage is not a function" error when trying to add a speedy deletion tag
• T331548: Write integration tests for cron job updatePageTriageQueue.php
• T335748: Migrate Database::delete usages to DeleteQueryBuilder in PageTriage
• T312480: Migrate usage of Database::select to SelectQueryBuilder in PageTriage
• T339373: PageTriage should use packageFiles (included migrating QUnit tests to Jest; done by Jon, we just reviewed)

• T335749: Refactor ILBFactory $lbFactory to IConnectionProvider $dbProvider in PageTriage
• T324914: Add User:DannyS712/VueNPP.js to PageTriage repo

Hi all, apologies for missing an update last month - quite a few members of our team were out for various lengths of time recently, and some other work had our attention, so we didn’t have much to report! I’ve got a quick update on where we’re at and the work we have lined up.

The NewPagesFeed Vue migration is progressing well, and we hope to have that demo for you very soon. We’ve reviewed our roadmap and decided that we would like to have both this and the Curation Toolbar migration deployed before we wrap up our focused work on PageTriage. As such, we’re extending the time we’re spending through to approximately the end of July. This should give us enough time to wrap these projects up as well as giving us a little time to fix a few user-facing issues.

We do expect to continue working on PageTriage a little beyond this, as IP Masking is now underway in earnest. Our team will be reviewing the extensions we’re responsible for to make sure nothing is going to break, which includes this one. We do also expect to continue maintaining the extension and reviewing patches in the long-term, but I’ll have more details about that towards the end of our planned work.

Alongside our work on the Vue migration, we’ve been continuing to replace deprecated code while improving test coverage.

• T324914: Investigate/Explore adding User:DannyS712/VueNPP.js to PageTriage repo
• T312480: Migrate usage of Database::select to SelectQueryBuilder in PageTriage
• T335748: Migrate Database::delete usages to DeleteQueryBuilder in PageTriage

We only have a brief update this week to say that we’re continuing with the work highlighted in our previous update. The NewPagesFeed Vue/Codex upgrade is coming along nicely - we hope to have a demo soon - and after getting stuck for a little while we’re now progressing well again with replacing deprecated code and improving test coverage.

• T331279: Migrate Database::update usages to UpdateQueryBuilder in PageTriage
• T336535: PageTriage ORES tests should mock calls for scores
• T324913: Curation toolbar fails to load occasionally for pages in the PageTriage queue (The Moderator Tools team reviewed this but credit for the fix goes to Chlod and Jon Robson)

• T324914: Investigate/Explore adding User:DannyS712/VueNPP.js to PageTriage repo
• T312480: Migrate usage of Database::select to SelectQueryBuilder in PageTriage

This is a quick status update on how we’re progressing so far, what work we’ve done, and what we’re seeing as the next priorities. We’ll aim to post another update in two weeks’ time, though we may have a demo to share before then demonstrating some minor UI changes. As always, feel free to post on the talk page with questions or comments at any time.

In the last update (below) we noted that we’re prioritising testing, documentation, and moving towards Vue.js as the extension’s Javascript framework. Over the past two weeks we’ve been investigating how each of these lines of work could proceed, and have decided to start with the Vue.js transition. We initially considered starting with improving test coverage, but in doing so we discovered that we would need to rewrite a substantial amount of code. As such, we figured that we would start with the Vue.js migration, and improve test and documentation coverage as we go, rather than refactoring code twice.

Moving away from backbone.js and underscore.js will be a big boon to the technical maintainability of the extension. These technologies aren’t used anywhere else in production MediaWiki, making them a blocker to developers who might otherwise be able to contribute more easily. The standard that we’re moving towards in MediaWiki is Vue.js, using the Codex component library as the standardised set of UI elements. Using Codex means that we gain the benefit of shared design components which have been thoroughly tested, are accessible, support right-to-left languages, and will receive centralised support going forward.

There has been some concern about changing the way PageTriage looks and feels if we use Codex, so I want to confirm that we’re going to try to change as little as possible about the experience of using PageTriage. Although this change might involve the visual style of some elements like buttons and icons changing, our goal is that the extension should feel more-or-less the same as it does today. Whenever we are going to make a user-facing change, we’ll make sure to post mockups or demos here for you to review in advance. I've posted an example - to the right - of the level of change we're talking about - the 'review' button in NewPagesFeed changes from one style to another, but is otherwise in exactly the same place and functions in the same way as always (the 'potential issues' information is only missing from the second screenshot for technical reasons).

Our engineers are currently building on the great work of DannyS712 to set up a Vue.js + Codex demo of the NewPagesFeed (T324914). Visual changes should be limited to simple components like button styles, and should not substantially alter the layout of the page. Once we’ve got this closer to being done we’ll set up a demo for you to try out.

In addition to the above, we’ve also been updating some deprecated code and improving test coverage alongside this.

• T334642: Investigate switching Javascript unit tests from QUnit to Jest

• T324914: Investigate/Explore adding User:DannyS712/VueNPP.js to PageTriage repo
• T331279: Migrate Database::update usages to UpdateQueryBuilder in PageTriage
• T312480: Migrate usage of Database::select to SelectQueryBuilder in PageTriage
• T335329: Get PageTriage QUnit tests working on localhost

This project is now underway in earnest! Our team's engineers have started working on their first tickets and submitting patches, and we've been engaging with WMF staff and volunteer developers to understand the highest priority work we can do over the next few months to make PageTriage an extension that's easier to maintain and improve in the long-term. As noted above, we didn't want to simply add more technical debt to the extension, making it even harder for future maintenance and improvements, but rather want to focus on ensuring that this extension will continue to function and receive updates for as long as it's valuable to editors.

At /Technical prioritisation we've summarised the range of technical priorities we brainstormed internally. Active volunteer developers have now shared their prioritisation rankings with us and we're discussing those on that page and in the NPP Discord, for quick thoughts & feedback. In summary, we're likely to focus our efforts on:

• Improving the state of software tests: If we have good test coverage, then when anyone makes changes to the PageTriage extension we can have a much greater confidence that those changes work correctly and will not break existing functionality.
• Improving documentation: There is a substantial amount of code-level documentation missing. This makes it harder for engineers to understand how the codebase works, slowing their work. We hope to improve this as we work on the extension as an ongoing effort, so that future developers are less likely to encounter this problem.
• Working towards upgrading from deprecated Javascript frameworks to Vue.js. Needing to learn a Javascript framework which is deprecated in MediaWiki is one of the biggest blockers to WMF support for PageTriage, so there is agreement to move to Vue.js, which is the new standard. This may be a large project so we're only committing to moving towards this goal at this stage.

We haven't forgotten about user-facing changes! Although these will be a proportionally smaller amount of our time over the next few months, we will still work on some. There are a substantial number of large and small feature improvements and bugs already listed on the Phabricator board, including a number which came up from our February interviews. Now is a good time to take a look through those and post any updates, clarifications, or +1s so that we can best understand which changes to focus on.

• T330690: Refactor $lbFactory->getMainLB()->getConnection in PageTriage
• T333389: make pagetriage_tags.ptrp_tags_updated nullable in database

Over the last few weeks we interviewed six active New Page Patrollers, learning how they patrol articles, what tools they use, and what frustrations they have. We've published a summary of this research at /Interview research.

Please have a read and let us know your thoughts on the talk page!

In the past couple of weeks we've started interviewing active New Page Patrollers and have been learning a lot about what patrolling looks like today. These interviews are continuing over the next week or two, after which we'll summarise what we've learned on this project page.

We've also started diving into some data for a quantitative view of the process. Some statistics uncovered so far, looking at the date range March - September 2022:

• Approximately 560 new non-redirect articles are created every day on the English Wikipedia
• 60% of those (~340) are made by users without the autopatrolled user right, and therefore require NPP review.
• Nearly 600 pages are marked as reviewed each day (the excess includes redirects and pages which were not newly created, e.g. converted from a redirect to a page)
• In this time period, 495 editors marked at least one page as reviewed. 189 editors marked at least thirty pages as reviewed.
• Of the 8,057 newly created articles which were moved to the Draft namespace, 6,171 (77%) of them were either still in Draft space or had been deleted by January 2023. 1,864 (23%) were moved back to article space.

We're also starting to think about our prioritisation process for deciding what our team works on. Our current expectation is that we'll aim to spend around 70% of our time, likely mostly at the outset of the project, working on technical issues which are unlikely to affect the user experience. These improvements are critical to ensuring that we can maintain the PageTriage extension long-term and have a solid base for making improvements. We do, however, then plan to spend around 30% of our time on feature improvements. While the technical priorities are likely to be determined by the team's engineers and volunteer developers specifically, we'd like to design a broader participatory process for deciding which features get worked on. If you have any thoughts on what that should look like, please share them on the talk page.

Although we're not delving into this project in detail just yet, we are getting some of the foundations in place so that we can hit the ground running in April. To summarise:

• This project page has been created and shared. We plan to update it as we progress. Once we have some tangible questions or items for feedback we plan to ping all participants of the 2022 WMF letter.
• We're starting enwiki user research - we want to learn how patrollers currently use PageTriage to patrol new articles. If you're interested in participating please see this message.
• We're also making more thorough plans for how we're going to learn about new page patrolling in other communities, such as which Wikimedia projects we'll target, what we want to learn, and where we want to be after interviewing editors.