Live data from Hacker News

GitHub Issues-only project management

blog.placemark.io

81–90 of 125 posts

Re: GitHub Issues-only project management

#81
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:

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.

Re: GitHub Issues-only project management

#82

Having to create issues-only repositories seems like a sign that one may be using the wrong tool. But the simplicity of GitHub Issues, and the fact that most issues on my plate are related to a particular repo, makes it tempting.

> Having to create issues-only repositories seems like a sign that one may be using the wrong tool.

Use it to track white papers, project planning documents, a project-wide wiki, et c., if you want to feel like it's for more than just issues. Though having an issues-only project doesn't seem worse to me than using any other stand-alone issue tracker, separate from GH.

Re: GitHub Issues-only project management

#83
post #8

Tangent, but: > or the macOS “Sticky Notes” app that somehow still exists in 2021 Why isn’t Sticky Notes just a view into a particular folder in Notes.app, anyway?

Notes.app can hold so much more than would work in a sticky. Whole embedded PDFs in the middle of a note, images, tables.

Re: GitHub Issues-only project management

#85

I'd love to use this approach if only I could save issues in, you know, git. Which isn't tied to Github.

Precisely! Locking yourself to github platform and then being unable to react to whatever strange rules Microsoft applies to it, doesn't sound exciting. I suppose there could be a script that uses github API to effectively scrub all the data off a repository?

Re: GitHub Issues-only project management

#86
post #34

One issue I still have with github (issues) is, that they only allow a very small set of file types to be uploaded. You can get around this by gzipping everything, because they allow .gz, however I still don't see why I'm not allowed to upload .diff or .patch files.

Pretty sure gitlab allows for any file type to be uploaded and they also support issue only projects.

Re: GitHub Issues-only project management

#87

Having run several engineering teams (15-20 people), I used this approach extensively. It meant one less place to go and one less tool to use. I liked this approach so much, I also wanted to use Github Issues for internal and external customer support instead of having another help desk tool involved. I created https://hubdesk.io/ as a side project to do this. Forward your support emails to HubDesk and it creates a G…

The open source company im at uses Github Issues/Projects exclusively for project management, and I'm not a fan, though I do think it's the least worst option - using any other system would require a really weird and bad way to sync the issues that are reported publicly.

Github just lacks the few necessary to do project management well, I think. I would love a "backlog view" for Github Projects.

Re: GitHub Issues-only project management

#90
It's what we do at SerpApi (https://serpapi.com)!

Having everything as GitHub issues has several benefits: Everyone knows how to use them, great markdown support including images, ability to react and thumb up issues and comments, deep integration in the actual code - well it's github, and it feels rock solid!

Post reply on HN