Categorization of Issues on Github

[kareila]

Hi all! During Saturday's dev chat, one of the discussions that came up was the current status of our work on improving the process of using Github Issues as our bug tracker.

Here is where we are right now:

It is now possible for anyone to use inline text tags to categorize new issues. fu has put up a rough draft of the instructions for this process, along with a list of the labels that are currently recognized. We are also planning to allow issues to be "claimed" in a similar manner, although the format for doing that hasn't been finalized yet.

Another part of Github Issues that we've been experimenting with is the use of milestones. If you look at the milestones on dw-free you can see, for example, the status of open bugs on certain major projects like Foundation and mobile styles. I think this could be really useful, especially in light of recent comments saying that we haven't been doing a good job of communicating the progress of our major development projects within the development community.

There are also other milestones currently displayed on that page such as "unclaimed", "curated", and "in progress" - a lively discussion ensued as to whether these would be better used as tags instead of milestones, and I'd like to continue that discussion below. The main issue with milestones on Github in general is that a bug cannot be assigned to more than one milestone. From a workflow perspective, we would expect to see a progression of untriaged -> unassigned -> claimed/in progress -> pull request -> closed, and the fact that an issue cannot exist in more than one of those states at a time makes it a good candidate for the use of milestones - but could conflict with using milestones for the purpose of tracking large projects.

There was also a great deal of confusion as to what "curated" was supposed to mean in this context. mark said what he desired was a list of three or so "top priority" unclaimed bugs, so that he could easily decide what to spend his limited time on. Again, this may be a better candidate for a tag than a milestone, and maybe with a label that is easier to interpret.

The last issue mentioned is that we still haven't come up with tags for indicating which area of the code is involved with a bug (e.g. styles, notifications, etc.), which is something we relied on pretty heavily with our previous Bugzilla setup in order to find new things to work on.

Please continue the discussion in comments!

Comments

[kaberett]

I really want a babydev-bait tag (or moral equivalent with less informal language, depending on discussion)

[alierak]

That's sort of like "effort:lower", except not to trivialize the actual amount of work it would be for a beginner?

[foxfirefey]

There are certain classes of bugs that are really really trivial to implement if you are familiar with the codebase that make really good bugs for beginners (for instance, adding embeds--very well defined on what you do so a beginner can focus on everything else). There are other classes of bugs that are fairly trivial to implement if you are familiar with the codebase that aren't such good bugs for beginners. That's why "effort: minor" on Bugzilla could never be given out as a babydev bait list--there was no distinction.

Perhaps "effort:introductory" would be applicable here?

[kareila]

I like this, or also "effort: beginner" (easier to spell).

[afuna]

+1 with this sentiment (no strong opinion on effort: beginner/effort: introductory)

[denise]

I like effort: introductory, but history has proven I am very bad at judging this, so other people should be the ones to tag it :P

[fu]

I think that kaberett and foxfirefey have been doing a good job of picking out babydev bugs!

Thought -- two tags "curated: beginner", "curated: highpriority/rahsaysso"?

[foxfirefey]

I like the though of being able to match "curated: beginner" up with "effort: minor"!

[kareila]

I could get on board with that!

(curated: mostwanted?)

[denise]

I like mostwanted!

[kaberett]

I think there's a difference between a low-effort bug for someone familiar with the codebase, and the kind of bug that's a good introduction to a particular area of the code/how to get set up with a Dreamhack/etc.