In T51188#1339454, @Tgr wrote:

How is this related to the Schema-change project? Is that project supposed to cover all schema changes, whether the extension is deployed on WMF wikis or not?

Correct.

This tracking task could be converted into a project (eg #wmf-schema-change) but I'll leave that to @Springle and @jcrespo.

https://wikitech.wikimedia.org/wiki/Schema_changes says "We use a tracking ticket in Phabricator to list all schema change tickets": is that still accurate?

According to https://phabricator.wikimedia.org/T69223#1847831, it's possible that a report now needs to be tagged in 5 different ways:

1. tracking bug,
2. Schema-change, Schema-change-in-production and DBA,
3. Cc.

If this is correct, please update the instructions. Should we mass edit the reports? In the meanwhile, I'll move some stuff from WMF-General-or-Unknown, since #Wikimedia-Database aka #DBA became a component.

@Nemo_bis the latest instructions say to prefer tags over tracking bugs. In my opinion, this tracking bug is redundant with Schema-change, not with the "new" tags, as they should only be applied to subtasks (and other DBA tasks that are not schema changes). I do not have the weight to delete one or another.

In other words, either they have a #mediawiki-something component + Schema-change tag, or it is a blocked-by task with DBA component (+optionally Schema-change-in-production). I am not touching nor redefining "your" tags without your permission, but here is the proposal. Note: I am saying you and us as "mediawiki hackers" and "WMF infrastructure owners", but that is very relative. But my suggestion would be to get rid of this "tracking" bug. Let me know your thoughts on that and I of course will help migrating tickets.

Things are mostly

Not my call, but there are other comments above on deprecating the tracking task so you could do that easily enough (just mark this invalid, add the relevant project to all blockers of the tracking bug and update the wiki page).

As for the other 4 markings, the differences are still too hard for me to grasp (see also comments on the proposal talk page) so I'll personally just use all of them simultaneously on tasks I care about, until I understand better.

@Nemo_bis I am still writing the documentation: everything here and here is false and outdated. I want to make sure that everybody agrees on the change, and that includes you understandin the process (which just officializes and coordinates what was done before in a way that one can check what changes are pending). Before that it was almost impossible to know what are the pending changes.

Please contact me, I will explain it and help me clarify the proposal for others. The proposal has not been resolved, and I would be glad with having your input, although as I said, it does not modify existing tags, only adds extra ones for operations.

This tracking task could be converted into a project (eg #wmf-schema-change) but I'll leave that to @Springle and @jcrespo.

I am about to deprecate this tracking task- the documentation on schema changes workflow was updated a long time ago on: https://wikitech.wikimedia.org/wiki/Schema_changes#Related_tags

Most of these are probably never going to be merged because they are stuck on eternal discussion, but I will give a look at the ones open to see if something got forgotten.

I think Reedy has triage all of this tickets, so this tracking task can be archived (deprecated by Schema-change-in-production)