Live data from Hacker News

GitHub Issues-only project management

blog.placemark.io

21–30 of 125 posts

Re: GitHub Issues-only project management

#21

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.

In a previous workplace, our security operations team (firewall) had several options for project tracking: Nothing, or Gitlab issues. Generically, we're talking "Kanban board" with swimlanes for the status, tags for categorization, and comments/attachments for discussion tracking. I'm currently in a position to get some people sync'ed on projects for a client, and I am going to recommend we use Trello. Kanban is just…

I find it to be unusable for projects of any decent size. There's pretty much zero visibility on what everybody else is doing, discussions are hard to use when they go over five comments (for example, you can't easily binary-search a large discussion with Home/End or my favorite vim-like navigation plugin, because you don't have the full page right away and it loads a few comments at a time). It's very JS-heavy and writes multiple gigabytes of data to localStorage every hour (which wears down my SSD needlessly) — the only web application I've ever seen doing that. I can go on.

Re: GitHub Issues-only project management

#22

Yep, I do the same. I also combine with github wiki for larger projects and documentation (often these will reference a bunch of issues).

Me too. I haven’t tried jamming sales into issues but for product dev it is all issues and wiki for docs.

I also use high med low customer impact and low med high difficulty labels as advocated by yc to organize priority.

Re: GitHub Issues-only project management

#23
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 Github issue for every email thread. You can then communicate back and forth with sender by starting a comment with "@reply" to send a reply email.

Re: GitHub Issues-only project management

#25
post #11

GitHub issues + ZenHub is a great combo.

I tried ZenHub back before GitHub had Projects, but I thought that Projects had feature parity with ZenHub. What’s the advantage of using ZenHub at this point?

We used it as a layer for rough point / estimation tracking. Not sure that's needed though TBH, in another iteration we had just put estimates as labels and that worked well. I really don't care for burn-down charts and the like, but it's useful to see easily sum up how many points you have in a sprint. I always wondered why github didn't add this one feature... but at the same time I think it's such a better tool than Jira because it's so much simpler.

Re: GitHub Issues-only project management

#27

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…

I think anything that reduces the number of different places that information or discussion may happen is good. The thought of having a mix of code/code review/wiki/other wiki/email/chat/list archives/jira/shared inbox/trello is not appealing to me. There’s some continuum where adding a system changes things from good to annoying and I think my own feelings put that place more towards the “fewer systems” end than where other people put it.

Re: GitHub Issues-only project management

#28
post #15

There are a plethora of reasons not to put sales data into github issues. I appreciate the idea of reducing complexity. Focusing things around issue tracking gives a good workflow for opening and closing, and also provids a finite goal, but theres often needs which cannot be met. I also dont think that its necessary to point out but I would not advise handing over all business organizing to github as a platform.

> There are a plethora of reasons not to put sales data into github issues.

Thanks for the details.

Anecdotally; the author of the blog post and work environments I’ve been in did just that and … reality still exists.

Me thinks personal opinions on how to store data are … personal opinions.

Re: GitHub Issues-only project management

#29
post #12

Earlier quoted context omitted.

I actually still use it all the time. Just a habit from when I started using what was then OS X in '08.

Oh, sure, I don’t mean “why does this app exist”; I mean “why isn’t its underlying data model merged/synchronized with that of the other OS note-taking app.” Why can’t I see my computer’s Sticky Notes on my iPhone in Notes under “Sticky Notes - [Computer name]”? Why can’t I add a sticky note to my computer by putting it in such a folder?

It might be that the future of sticky notes is Quick Notes as in iOS 15, but they do different things, I agree. Apple really should integrate the concept of sticky notes into both Notes and Reminders, to create a bit of a hybrid - a sticky note that can act as a reminder, etc. Even better would be sticky notes that reveal themselves when using certain macOS or iOS modes, so that when I’m at work I see my work stickies, and when I’m at home I could see some home stickies, etc. It should also be easy to remove a sticky by converting it permanently to a note or reminder, or maybe even a calendar event or contact.

Re: GitHub Issues-only project management

#30

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.

JIRA is a pile of bolted-on features, and no one has ever measured what is essential to project management, so this point strikes me as sort of an ad populum than an argument that JIRA or whatever is more fit for some PM task than Github Issues.

This is what kills me about software project management, at least in Enterprise where I work: its about people consistently communicating to one another; that's it, lest there's something else we can extract as somehow more primordial. Somehow people consistently communicating over a topic has been reified to the point that we mistake the reified things for the thing-in-itself.

Post reply on HN