GitHub issue management

[Fishrock123]

I firmly believe it could greatly help the project if we had more people able to actively sort though issues, as well as good labels to sort them with.

Sorting issues with good** labels has helped a lot with managing issues over at express, and I'd like to bring that to core.

Core is, however, much larger, and we'd need more people who can do the sorting imo.
I understand that not everyone may be comfortable with more people with commiter permissions, but the reality is git is distributed and it is easy enough to fix things if anything goes awry. I think people could also be more comfortable with a boarder community "managing" the project in this way.

I propose we use some modified / extended list of express's labels, which can be found here and here. (we have a tool that helps manage them too.)

(** What makes a good issue label? I'm not 100% sure, but I feel most in the example are pretty good.)

p.s. I have bugged GitHub about an issues management repo permissions level for a long time. I'll be writing them a detailed support email shortly.

[Fishrock123]

In addition, I'd like to point out in specific that broad use of the question and discuss labels has been useful, as it is much clearer to understand what those issues revolve around.

Furthermore, if answered questions can be closed, it could help reduce the backlog of a lot of non-issue issues.

[Fishrock123]

@mikeal tc-agenda is an excellent example, thanks.

[Qard]

pr-welcome is also a good one. It encourages contribution and hints that a thing is wanted, but low priority.

[TJkrusinski]

+1 to the pr-welcome I think it would help folks that are looking to become involved in the project a starting off point.

[max-mapper]

I added this yesterday, so that should limit the scope of issue tags we need in the core repo https://github.com/iojs/io.js/blob/v0.12/CONTRIBUTING.md#issue-contributions

[Fishrock123]

Perhaps, but not by much. We should still have things like question or discuss, etc. (also release for release meta-issues is nice.)

[bnoordhuis]

I like the Rust taxonomy where issues have area, effort, impact and priority tags. A simple documentation fix gets tagged A-docs + E-easy + I-papercut + P-low, a crash on OS X A-macos + E-hard + I-crash + P-high, etc. The multi-dimensional aspect makes it pretty effective.

[Fishrock123]

@bnoordhuis I see the appeal, but I feel generic tags are better along, or would definitely add to the usefulness.

@piscisaureus I listened to the TC, I think milestones are great for "owning" issues, but I think sorting could still help with knowing what to deal with, and in part, what has already been handled, and where the community can help out.

[Qard]

The rust tags seem a bit unfriendly to me, though I certainly see the appeal of multi-dimensional data. Perhaps if the tags didn't reduce the type word to a single character it'd be more clear to newcomers.

[Fishrock123]

The rust tags seem a bit unfriendly to me, though I certainly see the appeal of multi-dimensional data. Perhaps if the tags didn't reduce the type word to a single character it'd be more clear to newcomers.

Yeah, I agree.

[chrisdickinson]

I'm a huge favor of anything that helps us collectively draw PRs and issues to definite outcomes -- we should not let the issue tracker grow unbounded. Perhaps in lieu of focussing on classification of subsystem, platform, ease and severity with labels (which I think we all agree make good labels!) we should explore how we can use the tracker to set reminders for taking action on an issue. Milestones may be a good avenue for this -- perhaps issues and PRs should never be without an assigned milestone signifying a definite "this is when this will be addressed -- closed, merged, etc" by? I'd like to hear folks' thoughts on how best to keep issues and PRs from "falling through the cracks" using the github machinery.

I would also dearly like to have a guide for reviewers, with subsections on things like docs, style nits, etc.; something that would give folks who want to review a decent basis on what's good to comment on, and existing reviewers a place to link to when leaving comments. With things like docs or nits, it would be best if we could reduce friction by noting the nits in the PR -- so the submitter is aware of them -- but fixing them ourselves before committing.

I want to make it easy and comfortable for people to submit issues and code -- {node,io}js is an intimidating enough codebase as it is! -- we should keep in mind the experience for newcomers as we figure out how best to run the tracker.

[kenperkins]

I've found having a feedback-requested or something to this effect makes it easy for a project to keep track of issues where the burden is on the submitter to provide more information.

I've had a number of cases where I have dozens of issues that aren't directly actionable as we're waiting on feedback. Alternately, you could simply optimize for closing issues of this class, but I find that to appear dismissive to the submitter.

[Fishrock123]

I have applied jshttp's labels to https://github.com/iojs/iojs.github.io as a test bed for these sorts of labels. :)

[smikes]

I propose that io.js core team immediately create a new repo support for support issues and have that be the front line for questions/support reqs and (possibly) even bug reports against io.js.

I have just spent a little time working though npm's issue backlog ( npm/npm#6692 ) and one of the barriers to involvement is that write access to the npm/npm issues is === write access to the npm/npm repository. This means even a trusted community volunteer cannot be given the right to tag, close, reopen issues without also granting write access to the repo. It would be good to avoid the same problem here.

/cc @othiym23 and @iarna for their perspectives (as the people with write access to npm/npm)

[mikeal]

@smikes how is that different from https://github.com/node-forward/help ?

[smikes]

No different, and any issues target other than this one will work. node-forward/help is perfectly reasonable, though will it be moved to iojs/help?

I'm just speaking from the experience of looking at 800 issues, many of them abandoned, and not being able to use the power tools on them because they are locked in the same compartment as the code -- code I don't need access to in order to process issues.

[alexgorbatchev]

@mikeal at a glance https://github.com/node-forward/help doesn't not appear to be related https://github.com/iojs. I'm also in favor of https://github.com/iojs/help

[mikeal]

so, we're talking about end user help right? because if that is the case there shouldn't be any need to fracture the community or try to make providing this help about node.js vs io.js. that's why I'm suggesting that node-forward/node should be sufficient.

[smikes]

Sorry, I didn't realize that node-forward would remain as an organization distinct from io.js. In that case I have to think about this some more.

[othiym23]

Sorry, I didn't realize that node-forward would remain as an organization distinct from io.js. In that case I have to think about this some more.

I think this is a fine distinction that is likely to be lost on the people trying to get help, so this is going to require a lot of evangelization, redirection, and patience. I do want to amplify @smikes's point about laying down cowpaths to support that lead people to different places if they're just looking for help or have actual bugs or technical / architectural issues to discuss. I would like to see iojs and node-forward consolidated at some point for this reason.

Sam is absolutely right that it's a drag on team productivity that the people doing the most to support users aren't able to directly deal with issues, and he's also right that handing out commit bits to people helping with support (as valuable as that work is) isn't the right answer. Wherever we end up, we need to make sure that the messaging is very clear, and that everybody involved knows where to send the various kinds of issues.

[iancrowther]

If a waffle board is setup, will it / can it be public?

[Fishrock123]

See also #69

[kenperkins]

I opened #69 to be more explicit about a single proposal. Easier to +1 or -1 when it's a bit more concrete.

[smikes]

If a waffle board is setup, will it / can it be public?

@iancrowther AFAIK, as long as the underlying issues list is public, yes. There is already implicitly a waffle group for this issues list: https://waffle.io/iojs/io.js

[Fishrock123]

Issues are beginning to pile up a bit. Would be a good time to revisit this.

[rvagg]

not sure what the best course of action is here but steps I'd like to see are:

• additional collaborators added to the project
• all collaborators being told that they should feel free to close issues they believe are stagnant, don't contain actionable items or just aren't going to lead anywhere

We're going to have issues with ideas in them that don't generate meaningful discussion, I'd like to see those closed and encourage people to come up with code or post broader ideas to the iojs/roadmap repo for larger potential discussion (or further stagnation)