I like this post—or at least the way it starts out—subject to some important constraints.
> I think it’s worthwhile to lay out an alternative, which is my default: just use GitHub issues for everything.
Insofar as this article is an argument against using Trello etc instead of bug trackers, it's a great article. But insofar as it is really, actually suggesting you use GitHub issues, its value is thin. My rationale is closely related to my stance on Lawrence Kesteloot's essay Java for Everything:
This is one of my favorite blog posts of all time—and yet, I don't actually use Java, and I don't exactly think that you should, either. Funnily enough, it has a lot to do with why you shouldn't literally use GitHub issues.
The worst part about Java is actually dealing with the kinds of things that Java programmers do and the general experience of dealing with the Java ecosystem.
Likewise, the worst part about using issues on GitHub is the GitHub community. (The first example cited is a good example of this: "The company internal blog was an issue-only repository. Blog posts were issues, you’d comment on them with comments on issues." This is awful.)
Bug isolation, bug triage, and (most importantly) discipline in your approach to coming up with a fix for a given bug are all excellent skills that can be applied to many things to great effect, but you wouldn't know it looking at the way people use GitHub. It's still far from a norm for people to even provide steps to reproduce a given bug, not to mention the wanton abuse of comments. The example given ironically demonstrates why GitHub issues is _not_ the place that you should be taking cues from.
I especially find the claim that "GitHub issues make it harder for you to procrastinate and pretend" to be pretty comical. GitHub overall seems to favor people doing things that make them look busy (including actually being busy, if only, though, because of how inefficient GitHub's traditional workflows are) at the expense of actually doing things well.
> I think it’s worthwhile to lay out an alternative, which is my default: just use GitHub issues for everything.
Insofar as this article is an argument against using Trello etc instead of bug trackers, it's a great article. But insofar as it is really, actually suggesting you use GitHub issues, its value is thin. My rationale is closely related to my stance on Lawrence Kesteloot's essay Java for Everything:
<https://www.teamten.com/lawrence/writings/java-for-everythin...>
This is one of my favorite blog posts of all time—and yet, I don't actually use Java, and I don't exactly think that you should, either. Funnily enough, it has a lot to do with why you shouldn't literally use GitHub issues.
The worst part about Java is actually dealing with the kinds of things that Java programmers do and the general experience of dealing with the Java ecosystem.
Likewise, the worst part about using issues on GitHub is the GitHub community. (The first example cited is a good example of this: "The company internal blog was an issue-only repository. Blog posts were issues, you’d comment on them with comments on issues." This is awful.)
Bug isolation, bug triage, and (most importantly) discipline in your approach to coming up with a fix for a given bug are all excellent skills that can be applied to many things to great effect, but you wouldn't know it looking at the way people use GitHub. It's still far from a norm for people to even provide steps to reproduce a given bug, not to mention the wanton abuse of comments. The example given ironically demonstrates why GitHub issues is _not_ the place that you should be taking cues from.
I especially find the claim that "GitHub issues make it harder for you to procrastinate and pretend" to be pretty comical. GitHub overall seems to favor people doing things that make them look busy (including actually being busy, if only, though, because of how inefficient GitHub's traditional workflows are) at the expense of actually doing things well.