Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta: new labels for (not-)issues #13565

Closed
vsemozhetbyt opened this issue Jun 9, 2017 · 7 comments
Closed

meta: new labels for (not-)issues #13565

vsemozhetbyt opened this issue Jun 9, 2017 · 7 comments
Labels
meta Issues and PRs related to the general management of the project.

Comments

@vsemozhetbyt
Copy link
Contributor

vsemozhetbyt commented Jun 9, 2017

As I recall, we already had some discussion about this, but it was extemporaneous.

In the last hour, I've seen just two issues that remind me of that discussion:

#13563
#13564

Currently, we have some labels that are near such cases, but not ideally:

invalid — some collaborators consider it too abrupt and abstain from using.
known limitation — obvious.
question — for valid questions without aftereffects.
wrong repo — for redirecting.
wontfix — 'small core' and similar decisions.

I propose a poll (with not mutually exclusive options):

  1. invalid is sufficient label. Click 👎
  2. Replace invalid with works as intended. Click ❤️
  3. Add works as intended alongside with invalid. Click 👍
  4. Add doc improvement needed if an issue is caused by omissions/obscurity in docs. Click 🎉

Please propose other variants.

@vsemozhetbyt vsemozhetbyt added the meta Issues and PRs related to the general management of the project. label Jun 9, 2017
@mscdex
Copy link
Contributor

mscdex commented Jun 9, 2017

FWIW invalid can be used in many different scenarios not already covered by recently added labels and a works as intended label would not necessarily be correct. One example would be someone that submits an issue thinking there is a bug in node core, but then they later discover that it was simply an error in their own code. In that case working as intended doesn't really make sense because there was no issue to begin with nor was there any behavior to confirm (so the 'issue' is/was invalid).

@vsemozhetbyt
Copy link
Contributor Author

vsemozhetbyt commented Jun 9, 2017

@mscdex So maybe we can think up a more euphemistic wording. Something like not a [Node.js] bug. Because somebody may feel clicking invalid as clicking you are a fool.

@mscdex
Copy link
Contributor

mscdex commented Jun 9, 2017

not a node.js bug could cover any of those new labels though. I honestly don't see the need for most of these new labels. IMO wontfix, invalid, and question are all that's really necessary.

@refack
Copy link
Contributor

refack commented Jun 9, 2017

I tend to go 👎, maybe maybe add not a node.js bug (or replace invalid)
If I understand the motivation correctly, it is too explain why we are closing issues without a fix, right?
So as I see it there is a difference between issues we "reject" to those we "accept":

  • wontfix can mean works as intended -> we Close
  • wontfix + feature request = "small core" -> we Close

IMHO wontfix sais we decided not to fix, doesn't mean it's not a bug or that the users is fullish

or the other hand

  • for doc improvement needed can use the doc tag + edit description -> but we should keep Open

@vsemozhetbyt
Copy link
Contributor Author

vsemozhetbyt commented Jun 9, 2017

@refack For me, wontfix implies there is something that can be fixed but will not be. It is an acknowledgment of some bug or deficit.

@refack
Copy link
Contributor

refack commented Jun 9, 2017

@refack For me, wontfix implies there is something that can be fixed but will not be. It is an acknowledgment of some bug or deficit.

I agree, but I think of it as we acknowledge it might be a bug for the user, but we will not fix it. The reason why can be feature request, known limitation, or just something explained in one of the last comments.

@vsemozhetbyt
Copy link
Contributor Author

It seems we have a majority for 'invalid is a sufficient label'. So be it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests

3 participants