Background
The 1.3 KR is all about guiding editors to patrolling tasks and demonstrating impact. The features we develop for this KR are going to be working with recent changes which has run into DB scalability limitations that require SRE-owned schema and/or SRE expertise. Problems with recent changes start when a wiki gets really large due to bot edits or just the size of the wiki. For example Wikidata's rc table right now has 22M rows which is clearly bigger than what it should be. Currently, only three wikis have issues with recent changes table: English Wikipedia, Wikidata, and Wikimedia Commons T307328.
T396489 includes a summary of options proposed to help with the scalability/timeout issues. The same proposal are listed here. One of the proposed solutions is to move category changes (since this makes up of a large amount of edits that are added/removed for category changes) to a dedicated table as one of the ways to improve the recent changes table performance T399458. This could be done by:
- Creating a new special page (and API endpoint) for category changes
- Making category changes an exclusive choice on all interfaces; category changes and recent changes rows don't ever show up together in a list
Creating a new special page would fragment the experience more. The proposed designs are for #2 where category changes are an exclusive choice on all interfaces.
Currently, category-related filters can be selected in 'filters', 'namespaces' and 'tags' (tags could differ across wikis). In the designs, when any category-related filter is selected under 'filters', 'namespaces' or 'tags', no other filter will be able to be selected and the already selected filters will be disabled.
Designs
| 1) Filters | 2) Filters warning | 3) Namespaces | 4) Namespaces warning | 5) On hover over disabled filters |
 |  |  |  |  |
2 & 4: When a category-related filter is selected, all of the other filters become disabled and an inline warning message appears. The in-line warning message copy:
- Filters: For performance reasons, if category changes is selected, no other filter can be applied.
- Namespaces: For performance reasons, if category and/or category talk is selected, no other filter can be applied.
- For namespaces, it might be the exception that 'category' and/or 'category talk' may be selected simultaneously.
5: Active filters that were selected before a category-related filter is selected also become disabled. When the mouse hovers over the disabled filter chips, a popover appears with the following copy: Selecting filters related to categories disables the previously selected filters. To view results from the other filters, please deselect the category-related filter.
- This behavior is similar to the current behavior when multiple filters that belong to the same category are selected.