issue labels

[Fishrock123]

I'm going to begin copying over from io.js. We can discuss any additional ones / changes here.

[jasnell]

👍

[brendanashworth]

some things I can come up with:

• lets just use either feature request or enhancement, not both
• can issues be marked as semver, can pull requests be marked as bugs or feature requests?

[Fishrock123]

1. Indeed, I already dropped enhancement from here, feature request is much more useful.
2. sure, sure? if you feel it's appropriate. We have pr's marked as bugs especially when there isn't an issue for it already.

[brendanashworth]

@Fishrock123 2 probably isn't worth the discussion anyways, we can let people label as they feel I guess. those are my only wishes for the labels!

edit: what are peoples thoughts about PR status labels?

[silverwind]

How about we follow a colorization guideline like this:

https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/

As a reference, I really like how servo is doing this:

https://github.com/servo/servo/labels

[jasnell]

@Fishrock123 ... do we need to keep this one open?

[brendanashworth]

+1 for what @silverwind said. I went ahead and made some platform labels (P-windows, P-osx, P-freebsd, etc) just to see if anyone likes them.

[silverwind]

Here's a categorized list of labels based on io.js's current one. Note the leftover category are things we treat as submodule right now, but I think it should be in another category, not sure what to name it. Anything missing?

dependency - c-ares
dependency - http_parser
dependency - icu
dependency - libuv
dependency - npm
dependency - openssl
dependency - v8
governance - meta
governance - tsc-agenda
governance - tsc-meeting
language - c++
language - js
leftover - benchmark
leftover - build
leftover - install
leftover - test
leftover - tools
platform - arm
platform - freebsd
platform - linux
platform - osx
platform - smartos
platform - windows
status - discuss
status - future
status - good first contribution
status - help wanted
status - in progress
status - land on master
status - mentor available
subsystem - assert
subsystem - buffer
subsystem - child_process
subsystem - cluster
subsystem - console
subsystem - crypto
subsystem - debugger
subsystem - dgram
subsystem - dns
subsystem - doc
subsystem - domain
subsystem - events
subsystem - ffi
subsystem - fs
subsystem - http
subsystem - https
subsystem - module
subsystem - net
subsystem - os
subsystem - path
subsystem - process
subsystem - querystring
subsystem - readline
subsystem - repl
subsystem - smalloc
subsystem - stream
subsystem - string_decoder
subsystem - timers
subsystem - tls
subsystem - url
subsystem - util
subsystem - vm
subsystem - zlib
type - bug
type - feature request
type - question
versioning - semver-major
versioning - semver-minor
versioning - v1.x

[srl295]

I would propose an Intl ( akin to joyent/node's i18n ) label. It would supersede dependency - icu. Probably Intl instead of i18n to match the Intl WG name

[Fishrock123]

@srl295 it's like a subsystem tag. I'd just add it after mentioning here with no objections. (maybe intl since our tags are mostly lower-case.)

[brendanashworth]

'cuz i'm opinionated, some thoughts (just bikeshed):

1. how about instead of tags for specific versions (v0.12, v1.x), we just use a single LTS tag?
2. I think meta is more for type, not governance
3. let's get rid of the future tag, if it isn't pertinent immediately (PRs and issues), it should be closed and sent to NG until it is pertinent?
4. no js tag, maybe?

[Fishrock123]

1. What if we need to know where a specific patch would land? There has been discussiona bout using tags and tooling for this.
2. Huh? meta is for anything like not-code not-docs kinda. Just an "everything else about the project and how it is run".
3. Hmmm, not sure. Not everything in future is necessarily NG-future?
4. There's a js tag? Considering it;s our main language and what most people are able to contribut to there shouldn't be.

[silverwind]

I added the js to the list because we have a c++, but I'm fine leaving it out ;)

[srl295]

@Fishrock123 I'm fine to take it off the agenda, sounds like it is well in hand.

[brendanashworth]

1. Good point, nvm then.
2. I think it specifies the type of issue it is more rather than something pertinent to governance - like tsc-agenda. All it does is change the color of the label though, it doesn't really matter to me that much.
3. It's just an idea to try and keep issues / PRs low on the tracker - future tagged stuff usually doesn't have Actionables and are for "when xyz occurrs... maybe do this?", afaict. I just think stuff like that should be dealt like this. IMO this probably belongs in NG. ¯\_(ツ)_/¯
4. I just think its sort of expected - you hear from a lot of collaborators that they don't know C++, but if they even found the repo they probably don't need to know that a specific PR has js. 😉

edited for format

[brendanashworth]

.. mm, fwiw this repo will be moved and the io.js repo will take over, so the labels there would take the cheese.

[srl295]

Ok- I'd still like an intlish label please

[silverwind]

I added an intl label to nodejs/iojs for you, feel free to change the color if you like. 😉 I plan on doing a pass on labels and their colors soon, so that they're colored by category.

[rvagg]

closing because this repo is now archived