PSA: new tag "regression"

[refack]

There is a new tag for issues (available also for PRs) called "regression" please use it in addition to "confirmed-bug" to indicate that something that used to work has stopped working, or in the case that CI for master turns red.

IMHO we all should be more attentive to this list:
https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3Aregression

Looking for advice as to how to document this in the guides

I believe this should be reflected in one of the guides, I'm not sure which and exactly how. I'm seeking your advice.

some personal opinions

For me personally an ignored red CI is perceived as an act of disrespect to your fellow devs, and I find that offensive.

1. These issues may arise from a user report, where I believe acknowledging that this is indeed a regression will help communicate that we are taking this seriously. IMHO even a lively discussion helps the reporter feel that they are being heard (e.g. v7.x undocumented backward incompatibility of url.format() #11103)

2. Since the CI turning red for master is a situation that frustrates other contributors, and may lead to waste of others time, I posit that the respectful thing is for "landers" to run a post land CI job and in cases that CI turns red, open a "regression" issue, so that they can recruit help solving the issue ASAP. In cases where a solution seems to be far, I recommend reverting, and reopening the PR for improvement.

[Fishrock123]

Please also label these with confirmed-bug or they will not be seen.

[mscdex]

Yeah I'm not sure it makes sense to label something as a 'regression' without 'confirmed-bug' or some other 'confirmed' status.

[refack]

I'm not objecting, but since only Contributors can tag, I tought "regression" means confirmed regression.

[jasnell]

@refack ... I think the issue is more than the existing confirmed-bug label is something many of us already actively watch for. If things are marked regression without also being marked confirmed-bug (which such things are) then the likelihood of those being missed rises significantly.

[refack]

@refack ... I think the issue is more than the existing confirmed-bug label is something many of us already actively watch for. If things are marked regression without also being marked confirmed-bug (which such things are) then the likelihood of those being missed rises significantly.

Gotcha! 👍

[refack]

Added "confirmed-bug" to first comment.

[sam-github]

Is meaning of regression documented somewhere? How is it different from a confirmed-bug?

[refack]

Is meaning of regression documented somewhere? How is it different from a confirmed-bug?

👍
I'm looking for suggestions as to where and how to document this.

P.S. "confirmed-bug" is very sparsly documented: confirmed-bug - Bugs you have verified exist

[refack]

As I wrote in nodejs/CTC#106. "confirmed-bug" could have been there for ever, and just been discovered.
"regression" means something that used to work stopped working (my hated example, CI on master goes red)

"confirmed-bug" could stay orphan forever (as is in OSS). While a "regression" even if not solved could always be reverted.

[joyeecheung]

Another idea: we can use the regression tag to mark PRs that cause regressions and should not land alone(instead it should land together with another fix)

[refack]

Another idea: we can use the regression tag to mark PRs that cause regressions and should not land alone(instead it should land together with another fix)

Sounds good, since I can't think of a really good use for regression on PRs.

_{Ideas I thought about, but am ambivalent about
-maybe PRs that fix regression bugs, and should be fast-tracked
-maybe as a post-mortem marking of PRs that caused regression}

[addaleax]

I don’t think this needs to remain open at this point, feel free to re-open if I’m wrong.