GitHub Issue Tracker conventions for ValidateThis

[Jamie Krug]

Issue tracking has come up in two different threads today, so I thought I'd break it out here...

Bob suggested going with GitHub issue tracking. You can't argue with it's simplicity :) Bob also asked me for some tips on issue tag/label conventions, and I found a great suggestion here:

http://blog.h3rald.com/managing-your-backlog-with-github-issues

Basically, just numbered labels for releases, with a light-colored palette; "ON HOLD" and "REJECTED" as gray and black, respectively; and then some feature/bug labels. The sets of three check marks and X's for features and bugs is a little abstract for my taste. I might just suggest a single green "feature" label and a red "bug" label--maybe throw in a yellow "enhancement" label?

We could optionally add some sort of priority labels, such as priority-1, priority-2 and priority-3. I'd suggest priority-high/medium/low, but they don't sort properly alphabetically, and that seems the only way labels are displayed in GitHub's issue tracking--minor detail, I guess.

For tracking who is working on what, rather than adding too many labels, I think I'd suggest simply using issue comments for this purpose.

Best,
Jamie

[Jamie Krug]

To be clear, maybe, here are the issue labels I might suggest starting with:

0.99

1.0

1.x

Bug

Feature

Rejected

Best,
Jamie

[Bob Silverberg]

Sounds good, Jamie. I've created labels for each of those. I guess we
can add priority labels as we need them, but for now I don't think we
have enough issues to require them. I'm not sure about whether to use
labels or comments for developers. We don't have that many developers
currently, and if it will make it easier to see who's working on what
at a glance then maybe having labels for developers is a good idea.

Thanks for looking into this and coming up with these suggestions,
Bob

> --
> You received this message because you are subscribed to the Google Groups
> "ValidateThis-dev" group.
> To post to this group, send email to validate...@googlegroups.com.
> To unsubscribe from this group, send email to
> validatethis-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/validatethis-dev?hl=en.
>

--
Bob Silverberg
www.silverwareconsulting.com

[Jamie Krug]

On Mon, Feb 28, 2011 at 4:30 PM, Bob Silverberg <bob.sil...@gmail.com> wrote:

Sounds good, Jamie.  I've created labels for each of those. I guess we
can add priority labels as we need them, but for now I don't think we
have enough issues to require them.

Great, and I agree on skipping the priority labels for now.

 

I'm not sure about whether to use
labels or comments for developers. We don't have that many developers
currently, and if it will make it easier to see who's working on what
at a glance then maybe having labels for developers is a good idea.

Ya, I was torn on that one as well, and it's true that there aren't too many code contributors at the moment. One other possibility would be to simply use an "Accepted" or "Assigned" or "In Progress" label, so you can at least see what's being worked on or up for grabs and such.

 

Thanks for looking into this and coming up with these suggestions,

You bet!

Jamie

[Jamie Krug]

Interesting... I just opened an issue and found that I'm not able to add labels. I'm assuming only the project/account owner has that permission, unless you're able to configure that permission to individual users or groups. It makes sense to limit the label management permission, but if Bob wants any assistance there, he'll have to dig into security options at GitHub.

[Bob Silverberg]

ValidateThis is a GitHub organiztion, so I imagine that I can just add
you as a member. I'll try that and please let me know if you're then
able to add a label.

Cheers,
Bob

[Jamie Krug]

Still can't apply a label to an issue, since the team "Contributors" has "Pull Only" permission. The only other options provided by GitHub are "Pull and Push" and "Pull, Push and Administrative," so I don't see a granular permission that is specific to issue management. Oh well.

[Bob Silverberg]

That's no problem. I can give all you guys full access which should
allow you to assign labels. I'll get to that tomorrow.

[Bob Silverberg]

I've now given you full access. Can you let me know if you can label issues now?

Thanks,
Bob

On Mon, Feb 28, 2011 at 7:07 PM, Bob Silverberg

--
Bob Silverberg
www.silverwareconsulting.com

[John Whish]

Thanks Bob - I can now add labels to issues.

[Jamie Krug]

Ditto, thanks Bob.

[Jamie Krug]

Hey dudes, I just happened to notice that GitHub Issues now offers fields for assignee and milestone. These two simple additions really round out the only big missing pieces, for me, to now provide a very lightweight but useful issue tracker for OSS.

Cheers,
Jamie

[Bob Silverberg]

I thought I saw mention of those awhile ago.  Do you want to make some recommendations as to how we should use them for VT?

Cheers,

Bob

[Jamie Krug]

On Sun, May 8, 2011 at 12:46 AM, Bob Silverberg <bob.sil...@gmail.com> wrote:

I thought I saw mention of those awhile ago.  Do you want to make some recommendations as to how we should use them for VT?

Sure, I'll give my initial thoughts, off the top of my head; and then I may have more thoughts once I get through cf.Objective() ;-) We can also riff about all things VT and OSS CFML *at* cf.Objective() too!

So, the assignee is pretty obvious I guess. If you know who will work on a given issue, or you've started working on an issue, it makes sense to have the issue assigned to that person. Anything entered as backlog or just unknown can remain unassigned at first. Generally on this list it seems folks will mention when they're going to take a stab at implementing/fixing something, so it will just be nice to see tickets for each task assigned to folks working on or planning to work on it.

I assume a milestone would likely be best used to represent each release/goal. So, ideally, I'd see the separate road map document becoming unnecessary. When you're seeing a release or need for a hotfix or whatever, you can just create a milestone and gather the relevant tickets--the tickets then represent a road map to a release before implementation and release notes after completion.

Okay, back to polishing and reviewing my preso...

Cheers,

Jamie