Remove the "invalid" label, add a "valid" label

[iritkatriel]

As discussed in https://discuss.python.org/t/improve-communication-with-contributors-on-the-issue-tracker-and-prs-language-summit-follow-up/, I suggest we remove the "invalid" label which is not very useful (just close the issue) and can come across as harsh.

I also suggest to add a "valid" label with which a triager or core dev can signal that they "acknowledge" the issue (the bug is indeed a bug, the feature should be implemented, etc) and are likely to help reviewing patches for it.

[hugovk]

One use of the "invalid" label: it (and "spam") can be used to mark a low-quality Hacktoberfest PR as not counting towards the free T-shirt.

But the repo must also be opted-in to Hacktoberfest, so if the repo is not opted-in, it doesn't really matter about labelling "invalid" (or "spam").

[iritkatriel]

I think the PR needs to have a Hacktoberfest label to be counted, so we could just remove that label, no?

[Mariatta]

We opted in for Hacktoberfest last year. If the repo is opted in, I believe it doesn't need the hacktoberfest label.

[iritkatriel]

With spam PRs we replace the title by "spam". Can we search on that title content instead of wasting a precious label on spammers?

[CAM-Gerlach]

Just to note, GitHub introduced the ability to explicitly close issues as “not planned” (a much less harsh label than invalid, IMO), which are indicated by the color and symbol of the issue icon in the UI. This should fully obsolete the need for the invalid label.

[AlexWaygood]

Just to note, GitHub introduced the ability to explicitly close issues as “not planned” (a much less harsh label than invalid, IMO), which are indicated by the color and symbol of the issue icon in the UI. This should fully obsolete the need for the invalid label.

FWIW, I have no qualms about being as harsh as possible when shutting down spammy issues or PRs — and we get a non-trivial number of those.

I agree that the invalid label is too harsh for issue filers who are simply mistaken, in good faith, about whether something is a bug.

[CAM-Gerlach]

FWIW, I have no qualms about being as harsh as possible when shutting down spammy issues or PRs — and we get a non-trivial number of those.

Right, and in the case, the existing procedure of setting the title and contents to "spam", reporting and/or org-blocking them, and (if there is any chance of redemption) sending a stern reply are of course quite appropriate—I've helped deal with several that way myself. I have every sympathy for any real humans who may be at all plausibly acting in good faith, but none for those who know exactly what they are doing and simply don't care about the disruption they cause.

This is the same strategy I use as a Reddit moderator; ironically, we just got another spam submission I will be dealing with in this manner just as I was typing this very message.

[hugovk]

We opted in for Hacktoberfest last year. If the repo is opted in, I believe it doesn't need the hacktoberfest label.

Correct, one Hacktoberfest rule is:

• "The pull/merge request must be in a participating repository, or marked as participating itself."

Either the repo must be opted in with a "hacktoberfest" topic, or individual PRs must be opted in with "hacktoberfest-accepted" label.

Just to note, GitHub introduced the ability to explicitly close issues as “not planned” (a much less harsh label than invalid, IMO), which are indicated by the color and symbol of the issue icon in the UI. This should fully obsolete the need for the invalid label.

For issues only, not PRs.

With spam PRs we replace the title by "spam". Can we search on that title content instead of wasting a precious label on spammers?

I was going to say we need an "invalid" or "spam" label to prevent low-quality PRs being credited for Hacktoberfest (plus triagers can't edit titles):

• "The pull/merge request must not be labelled as spam."

But there's a newish rule:

• "The pull/merge request must be merged, have the 'hacktoberfest-accepted' label, or have an overall approving review and be open."

None of these conditions will be met for spam, so for Hacktoberfest we don't actually need "invalid" or "spam".

[CAM-Gerlach]

For issues only, not PRs.

Oh, right. Though, if a PR is closed (particularly by someone other than the author) instead of merged, that is a lot less ambigous than an issue being closed (which may indicate it was resolved, or it may not be a valid issue to begin with); it directly implies that for some reason, that PR is not a valid canidate to be merged (whether through being rejected, spam, outdated, superceded, etc).

[iritkatriel]

To summarise the discussion so far:

1. There were no objections to adding the "valid" label.
2. There was a question about whether the "invalid" label is needed for hacktoberfest, but the answer was that it is not.

[ezio-melotti]

ISTM that the discussion focused on removing invalid, which seems ok.
Maybe the addition of valid should be discussed in a separate issue or in the Discourse thread?

[iritkatriel]

This is the issue on which the addition of valid should be discussed.

[ezio-melotti]

The SC decided to use triaged: see this discourse thread with some background on the decision and the decision itself on python/steering-council#130 (comment)

I therefore went ahead, added the triaged label and removed invalid.

There were 5 open issues and 1 open PR marked as invalid:

• Cannot override 'connection: close' in urllib2 headers cpython#57058
• argparse: successive parsing wipes out nargs=? values cpython#72920
• Encode to EBCDIC doesn't take into account conversion table irregularities cpython#74771
• [multiprocessing] Multiprocessing in spawn mode doesn't work when the target is a method in a unittest.TestCase subclass, when run either with unittest or with pytest cpython#78065
• cdll.LoadLibrary allows None as an argument cpython#78773
• Unify the definition of PyVarObject by using PyObject_HEAD cpython#31842

There were also 6624 closed issues/PRs.

[erlend-aasland]

Very few triagers and core devs actually use this new triaged label, and even Irit who championed this label is deliberately not using it. AFAICS, this label is only adding noise; it is not helpful. Perhaps we should consider removing it, and just use type-feature and type-bug instead: if none of these are present, it is neither an accepted feature, nor an accepted bug, so it is "untriaged"; if one of them are present, it is "triaged", FWIW.

For now, I'm giving up using the triaged label. Sorry, for the negative tone, but I really don't see how this label is helping us 😕

[iritkatriel]

even Irit who championed this label

I never championed this label. I suggested something very different (in purpose, in audience and in name). I was clear that I don't understand what a triaged label would mean or how it would be used.

@ezio-melotti, who did champion this label, is yet to document it.