issue labels: ['invalid'] + ['wrong repo']

[refack]

Again I'm not sure if this is the right forums, but my intuition says it is. When a user post a "support" issue, we should refer him to nodejs/help, but them sometimes to tag the issue invalid. I feel that's a harsh word, and we should add a support-request tag for such situations, since the issue is valid, just posted in the wrong forum. IMHO this will be more inline with our CoC:

• "We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic."

and the contrib-guide

• "Courtesy should always be shown to individuals submitting issues and pull requests to the Node.js project."

[vsemozhetbyt]

A recent example of confusion: https://github.com/nodejs/node/issues/12386#issuecomment-293855707

[refack]

Found a basis for my intuition: from GOVERNANCE.md [edited]

Core Technical Committee

... The CTC has final authority over this project including:

• Project governance and process (including this policy)
• Contribution policy
• GitHub repository hosting
• Conduct guidelines

[vsemozhetbyt]

I think something like invalid could remain, but with a more friendly wording, like works-as-intended.

[refack]

I think something like invalid could remain, but with a more friendly wording, like works-as-intended.

Or even stay invalid, because something issues are "invalid", but should be used sparingly (maybe "against" experienced/collaborators), and so also add a works-as-documented (maybe intention is not well documented).

[refack]

Another example https://github.com/nodejs/node/issues/12338

[vsemozhetbyt]

Personally, I abstained from tagging invalid issues as invalid many times. I just feel awkward with this wording. Maybe I feel this word wrong and it does not seem somehow abrupt for native speakers.

[bnoordhuis]

The issue template is clear on what you should and shouldn't post to nodejs/node. If you then go on to post something that is out of line, 'invalid' seems apt.

I'll allow that the way we use 'invalid' sometimes conflates 'works-as-intended' with 'bogus'.

A recent example of confusion: nodejs/node#12386 (comment)

That was a confused person to start with. He first posted the same question to nodejs/LTS, then proceeded to double-post to nodejs/node and nodejs/help.

[refack]

I think we all agree these bugs should be closed and ignored (in both examples). We're just suggesting different tag names. Trying to pass the message that "the nodejs.org believes you have a valid issue, you're just using us wrong"

[refack]

Maybe instead of support-request add refered to nodejs/help

[aqrln]

The invalid label should definitely stay but it indeed may be a good idea to differentiate between issues and PRs like this one or this one and the issues that are just more appropriate for another repo like nodejs/help (and use a different label for the latter). I'm not sure about which specific wording might be best for such a tag, though. It would be odd to have a support-request label in a repo that doesn't provide user support.

[refack]

So how about two new referred-to-nodejs/help & works-as-documented

[MylesBorins]

what about wrong repo

[refack]

what about wrong repo

Better, it's simpler and applies to npm node-gyp bugs as well.

[gibfahn]

I don't think we want to have more than one label for this, the number of labels is pretty large already, and that's extra pain for new collaborators to understand (do we document what all the labels mean in the COLLABORATOR_GUIDE?)

Changing Invalid to something else seems reasonable, +1 to wrong repo. I think that can also cover the works as intended or works as documented use case as well, because in that case it's an issue that should really be raised in nodejs/help.

[refack]

Well someone added wrong-repo (I swear it wasn't me this time), thank you.

[MylesBorins]

it was me... I had a response penned but never sent.

On Mon, Apr 17, 2017 at 3:09 PM, Refael Ackermann notifications@github.com wrote:

Well someone added wrong-repo (I swear it wasn't me this time), thank you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nodejs/CTC/issues/102#issuecomment-294562506, or mute the thread https://github.com/notifications/unsubscribe-auth/AAecV0ESGCOjmVUKCre3DetAN5vGzQ-Nks5rw7jQgaJpZM4M9qsM .

[jasnell]

@refack ... creating labels is cheap and easy. We generally have not had any policies governing it. For labels that are currently used, the general rule of thumb is don't remove them without checking first. Adding new labels, or even renaming existing labels can be done any time but giving a heads up is always a good thing.

[refack]

Who removed the wrong repo label? I thought we have a concensus here, and now that information is lost from issues.

[refack]

/cc @nodejs/collaborators

like @jasnell said "the general rule of thumb is don't remove them without checking first"

[mscdex]

I prefer to keep and only have 'invalid' because it can cover many other cases than just 'wrong repo' and having less overlap in labels makes it easier to think/reason about IMHO.

For example, someone may submit a bug report but then later find out there was a typo somewhere in their code or that they needed to upgrade a third party module dependency. In those cases the repo they chose was correct, but the bug report was still invalid as the cause was not within node core.

Other times there are users who submit general help questions to the issue tracker that need to be redirected to the appropriate place(s) and for that 'invalid' also works because it's not the type of issue that the nodejs/node issue tracker is "designed" to attract. As Ben noted, we're already even explicitly clear in the issue template text (that everyone sees after they click the 'New Issue' link) that such general help questions should be directed to nodejs/help. Short of Github supporting forced checkbox filling before an issue can be submitted, I don't think there is much else we can do for that kind of situation.

[refack]

Up till now the decision was to have both. And as said above, feel free not to use it.

IMHO invalid is too harsh word, while wrong repo is not attractive, but not dismissive. Labels on the issues can change during issue triage and handling, but later we can get insights, how much is the node board attracting support seekers, and how many bugs are just invalid.

@mscdex if you feel strongly that only one label should stay I would suggest the classic not a bug

[mscdex]

I should also add that I personally do not think of 'invalid' as a 'harsh word' or an otherwise 'unfriendly' term.

[refack]

But some users do https://github.com/nodejs/node/issues/12386#issuecomment-293855707

[gibfahn]

I prefer to keep and only have 'invalid' because it can cover many other cases than just 'wrong repo' and having less overlap in labels makes it easier to think/reason about IMHO.

I think wrong repo is really clear, this question was posted in the wrong repo.

invalid suggests to people that their question is invalid, which is in the wrong repo case not correct. It's clear for us but not for the average poster. If we want to keep invalid for actually invalid bug reports then that seems reasonable, but for me having invalid mean two different things makes it harder to reason about.

[refack]

That was resolved with the addition of wrong repo