Repository navigation
Remove the "invalid" label, add a "valid" label #465
Description
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.
Metadata
Metadata
Assignees
Projects
- Status
Activity
hugovk commentedon Jun 22, 2022
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 commentedon Jun 22, 2022
I think the PR needs to have a Hacktoberfest label to be counted, so we could just remove that label, no?
Mariatta commentedon Jun 22, 2022
We opted in for Hacktoberfest last year. If the repo is opted in, I believe it doesn't need the hacktoberfest label.
iritkatriel commentedon Jun 22, 2022
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 commentedon Jun 22, 2022
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
invalidlabel.AlexWaygood commentedon Jun 22, 2022
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
invalidlabel is too harsh for issue filers who are simply mistaken, in good faith, about whether something is a bug.CAM-Gerlach commentedon Jun 22, 2022
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 commentedon Jun 23, 2022
Correct, one Hacktoberfest rule is:
Either the repo must be opted in with a "hacktoberfest" topic, or individual PRs must be opted in with "hacktoberfest-accepted" label.
For issues only, not PRs.
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):
But there's a newish rule:
None of these conditions will be met for spam, so for Hacktoberfest we don't actually need "invalid" or "spam".
CAM-Gerlach commentedon Jun 23, 2022
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 commentedon Jun 24, 2022
To summarise the discussion so far:
ezio-melotti commentedon Jun 24, 2022
ISTM that the discussion focused on removing
invalid, which seems ok.Maybe the addition of
validshould be discussed in a separate issue or in the Discourse thread?iritkatriel commentedon Jun 24, 2022
This is the issue on which the addition of valid should be discussed.
ezio-melotti commentedon Jul 13, 2022
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
triagedlabel and removedinvalid.There were 5 open issues and 1 open PR marked as invalid:
There were also 6624 closed issues/PRs.
erlend-aasland commentedon Aug 30, 2022
Very few triagers and core devs actually use this new
triagedlabel, 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 usetype-featureandtype-buginstead: 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
triagedlabel. Sorry, for the negative tone, but I really don't see how this label is helping us 😕iritkatriel commentedon Aug 31, 2022
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.