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…
GitHub Issues-only project management
21–30 of 125 posts
Re: GitHub Issues-only project management
#22Yep, I do the same. I also combine with github wiki for larger projects and documentation (often these will reference a bunch of issues).
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
#23Re: GitHub Issues-only project management
#24Re: GitHub Issues-only project management
#25GitHub 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?
Re: GitHub Issues-only project management
#26Re: GitHub Issues-only project management
#27Having 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…
Re: GitHub Issues-only project management
#28There 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.
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
#29Earlier 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?
Re: GitHub Issues-only project management
#30Having 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.
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.