Page MenuHomePhabricator

Create #dependency-injection
Closed, ResolvedPublic

Description

A tag should be created to track work related to dependency injection (DI)

See T384: RfC: Dependency Injection for MediaWiki core and T124792: RFC: Service Locator for MediaWiki core for some background within mediawiki core

Event Timeline

Restricted Application added a project: User-DannyS712. · View Herald TranscriptMar 13 2020, 5:44 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.
DannyS712 updated the task description. (Show Details)

As a component, this can be created without discussion[1], but just wanted to make this task to see if there were any objections. Will create in a few days if there are none

[1] https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Creating_new_projects

DannyS712 renamed this task from Create #dependency-injection tag to Create #mediawiki-dependency-injection.Mar 13 2020, 5:48 PM
DannyS712 updated the task description. (Show Details)
Demian added a subscriber: Demian.Mar 13 2020, 7:07 PM

To help me understand, what would be two example tasks that should receive this new tag?

Krinkle added a subscriber: Krinkle.EditedMar 13 2020, 11:03 PM

"Depedency injection" is not a component in MediaWiki core, and I'd be against a component named "MediaWiki-Dependency-Injection" for that reason. For the generic wiring logic around this, there is the MediaWiki-ServiceContainer which exists already.

For the short/mid-term effort of making use of the service container and decoupling specific parts of MediaWiki, the individual tasks should be filed under the relevant component they are about (e.g. under Parsoid or Flow, not under ServiceContainer).

It is imho best to avoid generic workboards like "MediaWiki-DI" as there is no clear owner for them. The same way that there could not be a clear owner for "MediaWiki- PHP code" or "MediaWiki- Undefined variables". It just makes it look like the tasks are organised when they are actually ignored/invisible.

  • If it's useful to track some of this work (which work?) in a single place (for whom?) a tracking task could be created instead.
  • Or if it's for yourself, perhaps a column on User-DannyS712 would help you.
  • For the decoupling effort happening this/next year, there is also a milestone workboard at Platform Team Initiatives (Decoupling (CDP2)) which covers this in a central place already.

If you'd like to track just any work (now and in the future) relating in some way to decoupling of software that is deployed at Wikimedia, then perhaps a yellow topic tag would make sense (not specific to MediaWiki). For example Code Coupling Issues. Notethat we already have Technical-Debt and Code-Health as well, which might be serving the same purpose already, e.g. search and discovery for tickets relating to this kind of work for interested volunteers.

DannyS712 updated the task description. (Show Details)Mar 13 2020, 11:09 PM

"Depedency injection" is not a component in MediaWiki core. There is the MediaWiki-ServiceContainer which has a component already.

For the short/mid-term effort of decoupling more parts of MediaWiki, the tasks should be filed under the relevant component they are about, to be triaged and worked on by teams that steward those components.

It is imho best to avoid generic workboards like "MediaWiki-DI" as there is no clear owner for them, and it just makes it look like the tasks are organised when they are actually ignored/invisible.

  • If it's useful to track some of this work (which work?) in a single place (for whom?) a tracking task could be created.
  • Or if it's for yourself, perhaps a column on User-DannyS712 would help you.
  • For the decoupling effor this/next year, there is also a milestone workboard at Platform Team Initiatives (Decoupling (CDP2)) which also covers this in a central place already.

If you'd like to track just any work (now and in the future) relating in some way to decoupling and/or dependency injection, perhaps a yellow topic tag could be created like Code-Coupling-Issues. Note though, that we already have Technical-Debt and Code-Health already which seem to already be serving the purpose of search and discovery for tickets relating to this kind of work (e.g. for volunteers).

Converted to a proposal for a tag for the topic generally, rather than trying to represent a component

DannyS712 renamed this task from Create #mediawiki-dependency-injection to Create #dependency-injection.Mar 13 2020, 11:09 PM
Aklapper added a comment.EditedMar 14 2020, 9:28 AM

I often don't understand the use case for going more and more fine-grained, as that comes with costs (someone needs to triage and add all these tags, people need to remember the existence of all these tags. Otherwise search results become very incomplete and a tag becomes useless which is not immediately obvious to people).
Given that we already have Platform Team Initiatives (Decoupling (CDP2)), MediaWiki-ServiceContainer, Technical-Debt, which real problem is solved by having another tag here?

Or in different words: Which of the bullet points listed by Krinkle (thanks for that helpful comment!) above were the motivation for creating this task?

It would be useful for myself (point 2) and perhaps others who are interested in contributing to the use of DI, but I'm not the only one working on these tasks, so a column on my workboard probably isn't the best. A tracking task would work, but since it would be Tracking-Neverending I thought it would be a bad idea to use

I'm personally still not convinced that people cannot look at open tasks in Platform Team Initiatives (Decoupling (CDP2)) and/or MediaWiki-ServiceContainer to find DI tasks, but I won't block creating this tag either if someone is really committed to constantly triage tasks to consistently set this tag.

I'm personally still not convinced that people cannot look at open tasks in Platform Team Initiatives (Decoupling (CDP2)) and/or MediaWiki-ServiceContainer to find DI tasks, but I won't block creating this tag either if someone is really committed to constantly triage tasks to consistently set this tag.

Its tasks I'm interested in working on too, so while I'm here I should be able to be triaging and adding the tag

Seeing no further objections, {{doing}}