Entry tags:
Categorization of Issues on Github
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!
Here is where we are right now:
It is now possible for anyone to use inline text tags to categorize new issues.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
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.
![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
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!
no subject
Use the "status" keywords for untriaged (already implemented), unassigned/unclaimed, and claimed/in progress. I believe PRs and closed issues are already handled without labels, but if a PR comes in on an unclaimed issue, the status could be automatically changed. Get rid of the milestones for these, to avoid overlap with other milestone uses.
Use the milestones only for long-term projects and for the individual bugs that are "curated" or equivalent term.
no subject
I'm torn between "curated" as milestone or label though. I think if we had a concrete goal "these bugs should be done by code push on date x", then I could see it as being more of a milestone. Otherwise, it seems closer to a label.
no subject
Curated should definitely not be a milestone, if milestones are being used for anything else - because it could overlap with almost any other taxonomy.
I'm afraid I still don't understand what we gain by trying to shoehorn something into the Milestones system rather than using tags. Is it just that we want to use it because it's there? ;-)
no subject
The way I see it, all the project-based tags will be done at some point. The mobile friendly styles one, for example, is eight bugs away from completion. At that point we can close the milestone and consider it done.
If it were a tag though then we'd just have an obsolete tag hanging around forever....
no subject
I assume GHI doesn't have any concept of dependancies? (ie x blocks y, which then allows you to create a metabug for a major project)
no subject
No sadly. I've had that problem with filing a bug for making the entry page into foundation -- since we have a milestone for the entry page and another for foundation. Eventually I decided to use the more concrete one.
I think that it'll be relatively rare -- at least rare enough that we can handle them on a case by case basis :)
no subject
no subject
no subject
Perhaps "effort:introductory" would be applicable here?
no subject
no subject
no subject
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
no subject
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"?
no subject
no subject
(curated: mostwanted?)
no subject
I like mostwanted!
no subject
no subject
no subject
no subject
I'm against opening an issue for all pages that need foundation conversion though. That would flood our bug tracker unfortunately.
no subject
/dodges fruit
(In seriousness, the categorization I'd really like is the site-section ones because then I don't have to scan the whole list for styles bugs)
no subject
APIs (RPC, XML, Flat): 63
Browser Issues: 28
Circle/Relationships: 41
Communities: 120
Crossposter: 101
Feeds: 42
Icons: 29
Importer: 76
Inbox/Notifications: 211
Invite codes: 34
Journal contents: 333
Misc Backend: 529
Misc UI/Frontend: 1303
Mobile: 5
Modernization: 188
OpenID: 29
Payments: 62
Registration: 25
Routing/TT: 67
S2 Backend: 109
Search: 55
Site Administration: 251
Site Layout/Navigation: 63
Style System: 923
Tags: 47
Testing: 13
Unknown: 80
Hope that helps!
no subject
....was that only open, or all bugs, closed and open?
(mostly I'm going @.@ at 900+ style system bugs)
no subject
no subject
Phew, okay. That's a little less worrying.