Breaking this task out from T139210: Abandon (or at least strongly simplify) project creation policy as it's really orthogonal to that discussion.
In T139210#2492581, @Jdforrester-WMF wrote:In T139210#2491737, @Aklapper wrote:In T139210#2472729, @mmodell wrote:
- Currently we have a bunch of teams creating milestones which most people outside the team don't care much about.
- Release-Tagger-Bot creates weekly release tags which are generally useful but they are ugly and numerous
- related problem: these aren't actually milestones because the bot predates milestones
I can make them milestones, it just needs someone to decide what the parent project is. :-)
- Does ReleaseTaggerBot only tag WMF deployments (a la WMF-deploy-2016-07-12_(1.28.0-wmf.10) or also supports other projects with their own milestone schemes?
It currently only supports the former, but other schemes could be written. There's already T100814: Have ReleaseTaggerBot also tag versioned libraries we control for libraries, for example; that task could be expanded for other areas.
- If the latter: Would you like to create a task to make ReleaseTaggerBot create milestones (assuming the API allows)?
Currently the projects are manually created (by me), not by the bot; back then, we weren't sure we wanted to give it project admin rights as it was a simple test. A task to do this already exists: T100812: Have ReleaseTaggerBot automatically create new deploy branch (release) projects.
- If the latter: Could ReleaseTaggerBot automatically archive a milestone after a certain time (currently this seems to be done manually) to remove the milestone from typeahead proposals?
I manually archive them when they're no longer on the cluster; this could be automatic, yes.
- If the former: I assume this problem will get solved by fixing T89945: Merge to deployed branches instead of cutting a new deployment branch every week.?
You say "fix", I say "will break a critical workflow". :-(