Wikipedia:Page Curation/2023 Moderator Tools project/Technical prioritisation
In March 2023, WMF engineers brainstormed the potential highest priority ideas to improve the technical maintainability of the PageTriage extension. Contributors to this discussion included current Moderator Tools team engineers and staff who have worked on the extension in the past.
We would like to invite volunteer developers who have worked on PageTriage to rank the potential impact of working on these ideas. We will combine these with our internal rankings of effort and impact to determine where best to spend our time. We've added two of the most active developers in the table below but please feel free to add your own column if you're a recent contributor to the extension.
Objective: The PageTriage extension is well documented, free of major bugs and code quality issues, and more maintainable.
Ideas
editPlease use your column to rank the ideas for impact between 1 and 5, where 1 means the change would have relatively little impact for you as a developer, and 5 is a very impactful change. Note that this should not be about user-facing impact, but rather how much this change would improve your ability to contribute to the codebase.
If an idea isn't clear to you feel free to ask on the talk page or just skip it. Please feel free to add additional ideas in new rows if you feel something is missing.
| Idea | Phabricator | Notes | Novem Linguae | MPGuy2824 | JSherman (WMF) | TheresNoTime-WMF | SCardenas (WMF) |
|---|---|---|---|---|---|---|---|
| Produce an architecture diagram explaining the data flow for items entering and exiting the PageTriage queue | 3 | 1 | 1 - My need is going to be a low-level understanding of the code, so I'm not sure this would help me. I might be able to *produce* a decent diagram after spending some time with the extension. | 2 | 3 - Although we will be working in-depth on the code, this will be useful in the medium-to-far future when the code's functionality fades from our memory. Having a visual aid will help new and old users navigate the code better. | ||
| Separate (as much as possible) business logic and UI | This might be more of an ongoing effort rather than a specific project. | 1 - If switching to Vue, probably don't need to spend time refactoring the old front end code. Also a lot of the view code is in Underscore files, so that's good. | 4 – this kind of depends on when the switch to vue will come. Since you guys are only prepping the codebase for the vue switch, this might be important in the meantime | TBD - I think this is a code health issue that we will address as best as possible when we replace underscore. So maybe more of a consideration or principal than a self-contained project? | 2 | 3 | |
| Prepare the codebase for an upgrade to Vue.js, replacing Backbone/Underscore | T208256 | Proof of concept at T324914. Changing the UI is not in scope here. | 5 - The front end probably does need some kind of rewrite. My eyes glaze over when looking at the front end code. My brain is expecting self-documenting classes and functions, and instead I see a bunch of function objects, JQuery, Promises, complicated abstractions (action queue, Backbone models), and comments that should be function names. I hope Vue is the right choice, but I am not sure, Vue is very new to our stack.
Keep in mind that a developer already converted Special:NewPagesFeed to Vue in a sandbox, so this rewrite might already be halfway done. |
5 | 5 - the presence of deprecated/nonstandard libraries is a big impediment to contributing to mediawiki generally. Because we have old and new side by side, contributors effectively need to become familiar with all of it to be productive. | 3 | 5 |
| Update technical documentation on installation and usage in MediaWiki | 3 - I've been updating the mw:Extension:PageTriage documentation and I left it better than I found it. Should be good enough for now. Let's keep adding to it as we explore. | 2 – the APIs could do with more documentation on the mediawiki site | 3 - I see this as closely related to the next one; It's already useful that Jdlrobson added info about draft namespace config, but I'm guessing that we'll encounter more missing bits as we dig in. Agree that this will be an ongoing activity to do as needed. | 3 | 3 - When fixing the local environment, we found that not all the database fields are documented. Having some documentation on what those fields do/when they are changed would be useful. | ||
| Fix bugs and improve process for local development setup | e.g. T333389 | 3 - Cross-extension dependencies such as ORES and WikiLove, lots of $wg settings, the use of MediaWiki: settings pages, and nobody testing this in Docker until recently makes this a challenging extension to run locally. | Fix bugs yes, not sure how much the process can be improved | 3 - I thought this was a bigger problem before we figured out the cause of the sqlite bug. I do think there's an opportunity for more of a "quick setup" recipe that would get the local environment close to enwiki production, maybe even with some fixtures for having some unpatrolled pages in the queue. | 4 — any goals which lower the barrier to new developers, and/or standardises test environments is a good use of time. | 4 | |
| Remove/replace deprecated code. Analyze what code can be changed and modernized to latest MediaWiki standards | T322818, T323552 | 3 | 5 – rating this high as this is hard for volunteers to confidently do without an extensive test suite | 5 - this overlaps with the dropping backbone/underscore | 4 — ensuring code standards are met and design methodology is modernised helps lower the barrier to newer developers (i.e., the "MediaWiki way" of doing things, which is mostly well documented, is put into practice) | 5 | |
| End-to-end browser tests (Selenium) | T320924 | Selenium can be time consuming to setup and configure. We might be better suited by focusing on unit test coverage. | 5 - Mass refactoring will break a bunch of stuff. Selenium happy path tests will help alert us to this during CI rather than after enwiki deploy. I think writing 10 Selenium tests (1 per Page Curation toolbar button, and 3 for Special:NewPagesFeed) could be worth it. | Not sure that i’m qualified to weigh in on selenium v/s unit tests. | 1 - In my experience, end to end tests bring the most value to cover crosscutting/stateful cases once you already have good unit test coverage, which we don't. Unit tests can run faster, are easier to run locally, and are less prone to breakage in our ci. | 5 — "Better tests" normally equate to more confident developers & quicker code reviews. | 3 - Selenium tests can be flaky. By adding more unit tests we can guarantee less code breakage and the rest can be covered by Selenium tests. |
| Improve test coverage for Javascript | T334506 | 1 - If switching to Vue, probably don't need to spend time adding QUnit tests to the old front end code. | 4 – my guess is that this would be lower than php even. Again depends on when the switch to vue can happen. | 5 - There is so little coverage here I would replace qunit with jest, which is gaining more usage in our ecosystem, is better supported with updates at this point, is easy to connect up with mock-mediawiki, and has handy coverage reporting tools. It's also pretty commonly used with vue, so volunteers will find lots of examples out on the web for implementing new tests over time. My understanding is that a replacement frontend will need to behave identically to the current frontend. In my experience, it's useful to have maximum test coverage for these kinds of migrations so that the new implementation can use the original tests to drive the new design and equivalent tests and prove that it does the same job. That doesn't have to be the plan here, but sometimes waiting for the "just around the corner" thing before addressing technical debt results in problems going unaddressed for years. | 4 — ditto | 5 | |
| Improve test coverage for PHP | 3 - Code coverage report. We're at around 30% overall, with good coverage of the APIs, and patchy coverage of everything else. I'd like to get integration tests in place for the daily cron job, which is hard to manually test and silently broke recently (T331548) | 4 – wow only 30% coverage | 4 - This would give contributors and maintainers greater confidence that we're not introducing regressions. Ideally, better unit test coverage would have caught that local sqlite issue before it was merged. I find test writing and documentation go hand-in-hand for gaining a better understanding of an existing codebase. While this doesn't provide direct end-user value, it's the kind of thing that new contributors generally aren't comfortable doing and fits with my skillset. | 4 — ditto | 4 | ||
| Improve documentation in Javascript | T334507 | 1 - If switching to Vue, probably don't need to spend time adding docblocks to the old front end code. | 1 – i’d suggest that you do this for any new/changed code only | TBD - The process of writing the documentation would help me better understand how things are supposed to work. I see it as worth adding alongside tests to save some mental labor for those that follow. I would recommend that we add what we think is missing as we learn how things work. | 3 | 2 | |
| Improve documentation in PHP | 1 - Seems good enough for now. | 1 – only fix any major pain points that you notice | TBD - Same as above | 3 | 2 | ||
| Write guidelines for contributing to the extension aimed at volunteers and future WMF developers | 1 - Like mw:Extension:PageTriage subpages? Would probably go unread. | If there are major differences as compared to other extensions/mw-core, then sure | 1 - I think we can simply try to adhere to the mediawiki guidelines | 4 | 3 | ||
| Extract SQL queries in PHP files into their own layer (separation of concerns) | 5 - There are SQL queries all over the place. These should be extracted from their current locations and moved to their own layer. phab:T324211 |