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

GitHub issue management #26

Closed
Fishrock123 opened this issue Dec 2, 2014 · 39 comments
Closed

GitHub issue management #26

Fishrock123 opened this issue Dec 2, 2014 · 39 comments
Labels
discuss Issues opened for discussions and feedbacks.

Comments

@Fishrock123
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@Qard
Copy link
Member

Qard commented Dec 2, 2014

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

@TJkrusinski
Copy link

+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
Copy link
Contributor

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
Copy link
Contributor Author

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

@piscisaureus piscisaureus self-assigned this Dec 2, 2014
@bnoordhuis
Copy link
Member

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.

@mikeal mikeal removed the tc-agenda label Dec 2, 2014
@Fishrock123
Copy link
Contributor Author

@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
Copy link
Member

Qard commented Dec 2, 2014

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@smikes
Copy link
Contributor

smikes commented Dec 3, 2014

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
Copy link
Contributor

mikeal commented Dec 3, 2014

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

@smikes
Copy link
Contributor

smikes commented Dec 3, 2014

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
Copy link

@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
Copy link
Contributor

mikeal commented Dec 3, 2014

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
Copy link
Contributor

smikes commented Dec 3, 2014

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
Copy link
Contributor

othiym23 commented Dec 4, 2014

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
Copy link

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

@Fishrock123
Copy link
Contributor Author

See also #69

@kenperkins
Copy link
Contributor

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

@smikes
Copy link
Contributor

smikes commented Dec 4, 2014

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
Copy link
Contributor Author

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

@rvagg
Copy link
Member

rvagg commented Jan 18, 2015

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issues opened for discussions and feedbacks.
Projects
None yet
Development

No branches or pull requests