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 ( https://github.com/npm/npm/issues/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)

[Qard]

I'd be glad to help with labelling stuff, and closing issues that obviously aren't useful or going anywhere.

[bnoordhuis]

@rvagg I agree. Do you think that is something that should be brought up at a TC meeting? If it were up to me, I'd just add @Fishrock123, @Qard and anyone else we deem trustworthy as collaborators now.

[rvagg]

@bnoordhuis it's on the agenda to look through the people in that list, we probably should stick to process but this ought to apply some pressure to the TC to get the list expanded. Putting @Fishrock123, @Qard on the list is probably a good idea since they've been very helpful in support and issue management--worth discussing how that aspect of contributing feeds into the decision to add people.

[piscisaureus]

I made a suggestion here for a workflow: https://github.com/indutny/caine/issues/30#issue-51734266

[Fishrock123]

Does anyone object to me adding the discuss, ideas, future, and investigate labels? I feel these in particular could be helpful as high-level labels.

[sam-github]

I strongly agree with @chrisdickinson on https://github.com/iojs/io.js/issues/26#issuecomment-65324244 on avoiding the indefinitely growing pile of open issues and PRs.

PRs should be progressing or closed (reopening is cheap).

Issues should be dealt with (or not) and closed. In particular, feature-requests that the io.js collaborators have not comitted to implementing themselves should be closed, with either an encouraging "send us a PR", or a "sorry, for X reasons, we don't think this would be acceptepted". Closed feature-requests can still be commented on, found be people searching for information, and even reopened.

The labelling helps make sense of a giant pile of issues and PRs, and its worth doing, but decreasing the size of the pile should be the ultimate goal.

To that end, I think labels that indicate how close to resolution an issue is would be pretty useful: bug, verified, unreproducible, rejected, etc.

[jbergstroem]

I like how the rocket repo has a "help wanted" tag. Not sure what state it represents, but having something for low hanging fruit could be a great way to get first time contributors.

[mikeal]

I like how the rocket repo has a "help wanted" tag.

Similarly, request has an "easy-fix" tag so that we can point new contributors looking to get involved at all the low hanging fruit in the project. Once easy-fix is added the regular contributors try to stay away from fixing the issue unless it's absolutely necessary so that we have more for new contributors to take on.

[Fishrock123]

We also have a help wanted tag, but I feel it is more for when something is too advanced?

easy or some form of low-hanging-fruit would be good.

[vkurchatkin]

@Fishrock123 as alternatives: good first bug (react) or Good for New Contributors (ember.js)

[aredridel]

Love it.

[othiym23]

I agree with everything @sam-github says, and am thinking about how to adapt that to the npm issue pile. Leaving issues unclosed (which is really a third state existing between "open" and "closed") because nobody knows what to do with them (or, worse, doesn't want to poke the bear) dramatically decreases the value of the issue tracker for everyone.

[brendanashworth]

As specifically this issue seems to be fixed - especially with the new collaborator onboarding process and the new labels, I'm going to close this for now.