-
Notifications
You must be signed in to change notification settings - Fork 1
Determine and document process of working on issues #137
Comments
I have ZenHub set up on this project for things like epics, backlog management, etc. I plan to keep using this, and would be happy to give access to anyone who needs it (I think I need an email address to invite you; I don't think I can invite just by GH user - if you want an invite, DM me on Slack with the email address). The upside of Zenhub is that it's a lot easier to order things in priority, etc. Of course, you only see this ordering if you're viewing Zenhub; the issues in GH still are ordered by other methods. My general thought is that we use the following buckets for issues:
These buckets will also have an associated GH label with them, so even if you don't use Zenhub, you can, for example, filter to find issues with the tag of "Status: Ready" and find something to work on, etc. |
@mattstratton does ZenHub respect / replicate tags from GH issues? The reason I ask is that with the above proposal we'll have three buckets of issues that aren't ready for work, with four total being categorized as "not working on yet". Could we use a "groomed" tag to denote the state of an issue and slim up our work buckets?
These columns would be supplemented by the following tags:
|
Labels There are a lot of various labels in this repo, which illustrates that I've messed around with different ways of categorizing the issues. Here's the ones that I think we will keep and what they mean: Status Labels
Type Labels
A couple other labels that will probably stick around:
|
@richardboydii turns out that zenhub doesn't update GH labels based upon the bucket they are in, but as the backlog manager I can manually do this when I move them around (it's not a big deal). "Frontlog" is basically what I was calling "Ready". "New issues" is basically an unlabeled issue and it is a zenhub bucket; the idea there is that those are issues that need intial grooming as in "do we even want them in the backlog, period". Nothing should live in "new issues" for very long; it will be a quick "is this a clear Things get pushed into icebox after having been in backlog for too long, imho. So the general flow of an issue would be like this (maintainer right now is just "Matt", but we can add more owners later):
and so on... |
There's an ability in zenhub to mark an issue as dependent on another issue, and that will be reflected in github somehow too IIRC |
Up until now, the only contributor to this project was @mattstratton , so the process didn't matter much. Given that we have other folks who want to work on this, having a lightweight (please!) way to determine priority of issues and what should be worked on would be really helpful.
Let's use this issue to talk through how this might work, and once it's decided and documented, we can mark this issue as done!
The text was updated successfully, but these errors were encountered: