...as new projects get created by teams working on them and as some projects get archived.
I don't see an easy solution (except for creating Umbrella projects and Herald rules to automatically add them which is a Phab performance issue and likely not wanted by some maintainers) and while some (WMF) teams list their codebase projects they are responsible for in some places (on-wiki or Phab team project descriptions) there is no consistent approach enforced.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | srishakatux | T164084 [FY 17-18] Program 12: Onboarding new developers | |||
| Resolved | Aklapper | T176490 Goal: A learning environment and growth paths for new volunteer developers | |||
| Resolved | None | T169599 Sort out concept for overview/entrance pages targeting our developer audience | |||
| Resolved | Aklapper | T122683 Manually keeping the Phab project queries for areas on [[mw:Annoying little bugs]] up-to-date is cumbersome |
Since we have a finite number of teams, perhaps it is easier to have a proposal and explain it to those teams, rather than trying to play catch with the birth and death of repositories.
For instance, see what @CKoerner_WMF did at T139369: Better promote ways volunteer developers can be involved in Discovery projects.
A horrible hack is to create a fake user for each team / project group / whatever, make sure they are subscribed to the projects in that group and only those, and then use the "in the projects of user X" search function. The team would be responsible for adding / removing projects. Could even be automated somewhat by the fake user having a Herald rule which adds / removes projects based on the presence of some magic word (presumable a Herald rule for project description page edits is less of a performance problem).
What I see in T139369 is 1) make teams go through tasks and add the good first task tag and 2) mention easy tasks in public communication.
I'm not entirely sure how these two are related to this task, if we don't think in "WMF team" terms only when it comes to projects in Phab.
What is the future of Annoying Little Bugs from the point of view of our ongoing work at T169599: Sort out concept for overview/entrance pages targeting our developer audience?
In other words, do we still care about that page and those queries being helpful to new developers?
Certain meta-tags will "always" work, like good first task Documentation tasks. Or project that have exactly one tag, like Huggle.
Things get blurry tracking "code projects" in areas between these two poles though - if no one parent project exists, or without existing umbrella projects being added by Herald rules, the query links on https://www.mediawiki.org/wiki/Annoying_little_bugs will slowly bitrot.
So I think that criteria is the key.
Plus, after that, clarifying the actual issues with that page and its remaining lists which are currently described in this task, by explicitly describing them also on the wiki page, so any new contributors are "warned".
I went through the queries on the page, made a ton of edits, removed some projects that I consider hard to 'maintain' when it comes to Phab queries (project tags to be included) which do not have one/two 'umbrella' projects in Phab to query, and was inconsistent by keeping some (even if we do not cover all tags in a certain area, covering most works too), shortened a bunch of descriptions, fixed any Phab query links to all show more than 100 tasks and sort by latest updated tasks and not group by priority:
https://www.mediawiki.org/w/index.php?title=Annoying_little_bugs&action=history
I'd say that is sufficient here as perfect is the enemy of good. Hence closing this task as resolved.
And then I decided to change the layout in https://www.mediawiki.org/w/index.php?title=Annoying_little_bugs&type=revision&diff=2677707&oldid=2677706 which might be controversial (custom HTML and CSS). CSS3 grids behave great on small screens and boxes look way less boring. But of course it is not the "pure doctrine" and obviously not something that MediaWiki was designed for.