Inspired by T213880: Cleaning up #Mediawiki-extensions-other
Where it makes sense to do so, new component projects should be created for tasks that otherwise just sit in MediaWiki-General but are clearly tied to a specific feature / component
Recently created projects for core components:
MediaWiki-Parser-TrackingCategories (converted from tracking task)
MediaWiki-Page-rename
MediaWiki-MergeHistory
MediaWiki-Core-Hooks
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T249999 Cleaning up #mediawiki-general | |||
| Declined | None | T249998 Create #mediawiki-namespaces | |||
| Declined | None | T268386 Create #mediawiki-actions component |
Currently in process (have been proposed): T249995: Create #mediawiki-global-scope, T249998: Create #mediawiki-namespaces
The grouping of tasks should be based on code that is maintained together as a system.
For example, the following are not useful as components to split from "general":
Because these are not components, and cannot be separated from the rest, and would not have anyone triaging the issues or improving their system. If there is significant interest from volunteers in some of these as a way to help discover other components, then they might be useful as a general tag.
For example, a new contributor interested in javascript (but has no preference for which component) the general tag JavaScript could be combined with patch-welcome in a search to find those. Note that for this scenario, the tag is not only for all components of MediaWiki core, it is also for all software at Wikimedia (including outside MediaWiki core).
But for a thing like JavaScript, we would not untag MediaWiki-General because it is not a real component.
@Krinkle MediaWiki-Special-pages already exists - should it not?
What about splitting blocking (MediaWiki-Blocks) out of MediaWiki-User-management - a clear component that covers api (un)blocks, Special:(Un)Block, partial blocks, etc
In an ideal world, it should not.
What about splitting blocking (MediaWiki-Blocks) out of MediaWiki-User-management - a clear component that covers api (un)blocks, Special:(Un)Block, partial blocks, etc
(Note that MediaWiki-Blocks exists since yesterday.)
Yeah, not for individual page implementations. But we do need a componont for the general system in core, its base classes, factories, related db tables, and maintenance scripts.
Most special pages already are no longer tracked here (see the project description). But a few them stil are. This is mainly because they do not currently have a team acting as steward and also do not have an obvious component that it belongs to.
Creating separate projects for these as-is is difficult though. It might wrongly give the illusion that issues are being being tracked, when the arent'. And we'd have to change it again once the component boundary is drawn for that particular feature.
Where it makes sense to do so, new component projects should be created for tasks that
@DannyS712: Are there any specific proposals? This task currently looks unactionable (as in: neverending, like "Make sure all images on Commons have categories") to me so I'm not sure what to make out of it, apart from one item about user blocking which should be a dedicated task with folks working in this area subscribed and involved (e.g. recently created MediaWiki-Blocks).
Well I proposed T249998: Create #mediawiki-namespaces that is a clearly defined part of the code base
Will probably make a proposal for MediaWiki-Blocks after I gather a list of the classes
@DannyS712: That's good and specific. :) I am only wondering what are the criteria when to call *this* task "resolved".
I'm proposing to close this task, as I am not aware of any clear criteria when to define this task as "resolved" and as tasks should not be neverending.
Can we keep it open until some more progress have been made? True, there is no clear criteria, but, eg, T249998: Create #mediawiki-namespaces should be resolved first (and I'm not going to proceed with that until someone comments endorsing it)