Repository navigation
GitHub issue management #26
Description
Activity
In addition, I'd like to point out in specific that broad use of the
questionanddiscusslabels 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.
@mikeal
tc-agendais an excellent example, thanks.pr-welcomeis also a good one. It encourages contribution and hints that a thing is wanted, but low priority.+1 to the
pr-welcomeI think it would help folks that are looking to become involved in the project a starting off point.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
Perhaps, but not by much. We should still have things like
questionordiscuss, etc. (alsoreleasefor release meta-issues is nice.)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 XA-macos + E-hard + I-crash + P-high, etc. The multi-dimensional aspect makes it pretty effective.@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.
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.
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.
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.
I've found having a
feedback-requestedor 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.
25 remaining items
Love it.
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.
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.
- added 2 commits that reference this issue
on Aug 13, 2015
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.