Could you elaborate how/for what this is being used?
Is there some analysis by you or in your team how many tickets got marked as regressions?
Is there some progress in place to triage tickets and consistently add that tag?

I am reluctant to add tag projects just because we can if noone consistently uses them (or even remembers them because there are too many; seen that pattern in Mozilla Bugzilla often enough).

For the records, there are 527 Bugzilla tickets with the keyword.

No involved analysis. But if we have bugs in it that stay open for long it would indicate we break stuff and then do not bother to fix it. There is no process to consistently make sure that this is added when it would be correct to do so and I don't intend to propose one. I just use it to clarify the impact or importance of bugs when i feel like it.

Does it somehow hurt to have this additional information for some tickets but not for most?

In T75894#790954, @JanZerebecki wrote:

No involved analysis. But if we have bugs in it that stay open for long it would indicate we break stuff and then do not bother to fix it.

Wouldn't a better and more complete indicator to simply search for the word "regression" in the text of tickets?

Does it somehow hurt to have this additional information for some tickets but not for most?

To me that contradicts the first sentence a bit - if you want to have an overview whether you bother to fix regressions or not, you need to have sufficient datapoints to get an impression?

The text search has the problem that once someone mentions regression that can then not be removed if it is not the case.

If there are open bugs tagged with this we know that we didn't bother to fix those yet. I assume even that has value. Unless we should avoid handling a bug that is a regression differently from a bug that is not. Do we want that?

We don't know based on that how many there are/were in total. It shows presence but can't show absence. But that is true of bugs in general and true of every tag, especially in phabricator, because it allows bugs with no tags and multiple. Another example where we have no more of a process to add the tag is #structured-data because it probably always overlaps with at least one other project tag.

Again, if there is a process in place to actually look at that "this is a regression" information, I'm fine with adding that information. But I'd like to see such a process in place first before creating work for triagers etc.
I'm reluctant to add a tag in Phab just for the sake of having a tag which isn't used for anything afterwards. My guts tell me that we've done that a lot in Wikimedia Bugzilla because some people love categorizing (for the sake of categorizing?) but I don't want to encourage such use of everybody's time if that tag isn't used to analyze stuff in the end.

For the records, I queried Wikimedia Bugzilla for tickets in Wikidata projects that either had or have the "code-update-regression" keyword, and I got zero results. So at least that team has never used that keyword. :)

(I couldn't find Chris McMahon, I'll ping him about this one.)

As a bug reporter, I always find useful to note when a bug is a regression. A Regression tag might be useful if the QA people follows it as a pointer to see where automated testing is especially welcomed.

I do not plan to follow the tag.

There is something I don't understand. We didn't drop keywords, we converted them to projects. If code-update-regression was a keyword, it should be a project now, right? I could not find it, though.

The ticket linked in the description said that you dropped some of the keywords on import/migration.

@Qgil: See T266

I would find it useful if there was a way I could follow regressions for MediaWiki releases, maybe a search with "regression" and "1.24 release". So, yes please!

Two questions how to deal with the tickets we imported from Bugzilla. Would be cool to get your input; then I'll create the tag here.

• As expressed before in T266, we did not take over the "code-update-regression" keyword from Bugzilla. There were 66 open tickets with that keyword in Bugzilla. I can easily mass-add that tag project again to those imported tickets in Phab if that is wanted.
• I'm not convinced if I should create notification noise by also adding that keyword/tag back on those 461 closed tickets - historians could still query old-bugzilla as long as it's available? But sure I could also do that if wanted.

(And I might bikeshed on semantics but I personally wonder if at some point something is not considered a regression anymore if that regression happened ages ago? I see open tickets which have not been touched for 3 1/2 years with that keyword in Bugzilla. Nothing to "decide" on though, just a thought and it's late night here and you can imagine me with a glass of whiskey and a cigar brainstorming on issue management. Not. :-)

At this point, I would add the tag (generating email notifications) only to the open tickets.

A regression is a regression, now and in a hundreds years.