Comments on: Our Label Ontology For Issue Tracking https://blog.beeminder.com/buglabels/
Tue, 06 Mar 2018 18:07:00 +0000
hourly
1 https://wordpress.org/?v=5.1.1
By: Daniel Reeves https://blog.beeminder.com/buglabels/#comment-83807
Thu, 25 Jan 2018 00:05:00 +0000http://blog.beeminder.com/?p=1313#comment-83807Update another year later: I’m nixing the idea of nixing the nix label. Sometimes an Issue was just wrongheaded. Maybe a feature you thought you wanted but come to realize would be bad (even if development time were no object).

Conceivably you could break down the reason for nixing something. Like “bad” for “turned out to be a bad idea” or “mut” for “ongoing evolution of the project made this moot”. But I think that can be clarified in the comments. The thing we want to know is that nix’d Issues are ones that are wholly rescinded.

]]>
By: Daniel Reeves https://blog.beeminder.com/buglabels/#comment-83733
Fri, 03 Mar 2017 22:45:00 +0000http://blog.beeminder.com/?p=1313#comment-83733I’m realizing that, at least for Trello and GitHub, we can always close an issue without giving it a label at all. Which is a lot like closing it as “nix”. So all the more reason for nixing “nix”. The only counterargument I can think of is that it makes it more annoying to filter for all the things closed for no reason:

is:closed -label:zap -label:zzz -label:cnr -label:dup -label:aok

]]>
By: Daniel Reeves https://blog.beeminder.com/buglabels/#comment-83732
Fri, 03 Mar 2017 17:49:00 +0000http://blog.beeminder.com/?p=1313#comment-83732Oh, yes, thank you for helping us with the ontology! That was dumb of me to forget to mention your help! The only ones from you that I jettisoned were “user confusion” (I figured those should mostly count as bugs) and “integrations/autodata” (YAGNI — https://en.wikipedia.org/wiki/You_aren't_gonna_need_it — another thing I should’ve mentioned in the post!) and “needs triage” (I figured lack of labels indicates that).

Good question about when to close with “nix” (aka “won’t fix”). Joel does have an example in his article. The equivalent for us might be a bug in one of our autodata integration partners’ products. Reproducible, not by design, but not something we can fix.

I think you just convinced me to nix “nix” though. You should either decide it’s “aok” or if it’s out of your hands then close it with “zzz” (postponed) so it’s still in the bug database as an issue and maybe in the future you’ll be able to work around it or it will otherwise resolve itself. Technically you might still want to distinguish between “not ideal but not worth fixing now” vs “not ideal and not worth fixing ever” but I think that’s too fine a distinction. Just put all those things to sleep with “zzz” and worry about them later!

Thanks again for the help with all this!

]]>
By: Kenn Hamm https://blog.beeminder.com/buglabels/#comment-83731
Fri, 03 Mar 2017 02:05:00 +0000http://blog.beeminder.com/?p=1313#comment-83731Heh, I was prepared to complain that you had ruined the label scheme I set up months ago, but it actually looks pretty similar.

“Category” labels like “ABC” make sense if there are different people or teams who would be interested in or able to work on particular issues. That can change over time as the people and how they are organized changes.

When would you ever use “nix” rather than a more specific reason for not fixing something? Joel’s article doesn’t explain this either.