GitHub Issues-only project management • Hacker News Board

Re: GitHub Issues-only project management

#41

Post by simonw » Sat, Aug 21, 2021, 7:20 PM UTC

dan-robertson wrote: post #27

quesodev wrote: post #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 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 whe…

Tool proliferation is definitely a problem, but at larger organizations I'm not sure how feasible it is to keep everyone using the same small set of tools.

At my last large employer I ended up putting together a custom search engine that searched across a bunch of different places where important stuff ended up - Google Docs and GitHub Wikis and Markdown-in-GitHub and Confluence and Salesforce Support and a mailing list archive and a few others.

Having a single place to search really helped: I had thought that we had bad documentation, but it turned out we actually had pretty good documentation just distributed across too many different places.

Re: GitHub Issues-only project management

#42

Post by simonw » Sat, Aug 21, 2021, 7:22 PM UTC

mwcampbell wrote: post #3

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.

I don't see why that's a sign of the wrong tool: if it's OK to use a GitHub repo for code and not for issues, why not use one for issues and not for code?

I drop a single README.md in the root of the repo that links to the issues and leave it at that.

Re: GitHub Issues-only project management

#43

Post by simonw » Sat, Aug 21, 2021, 7:24 PM UTC

erhk wrote: 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.

Is your concern that GitHub employees might access your confidential sales data if it's in issues in a private repository?

Because if you're worried about that, there's probably a whole bunch of even worse things that they could be doing with access to your source code, secrets and CI infrastructure.

Re: GitHub Issues-only project management

#44

Post by robertwt7 » Sat, Aug 21, 2021, 7:24 PM UTC

I actually really liked this approach compared to having to switch to jira/notion everytime.

I think some big names are using this approach to right. Like aspnetcore and some other microsoft products

Re: GitHub Issues-only project management

#45

Post by simonw » Sat, Aug 21, 2021, 7:29 PM UTC

TeMPOraL wrote: post #37

Nope. Having worked in a shop that used GitLab issues for project management, I've come to realize GitHub-style issue trackers work if all your project management boils down to creating and tracking bite-sized blobs of work. It stops being sufficient when you need to actually plan ahead . FWIW, so does Trello. Couple reasons why: - Issues are flat. Work breaks down into a tree. And no, "epic / ticket / checkboxes in…

"Issues are independent. Properly broken down, work in a project has dependencies"

A trick I use a lot is to open a "tracking issue" and then link to it from other dependent issues by mentioning its #ID in those issue's descriptions.

The tracking issue automatically shows the open/close status of those other issues, which means I can see at a glance if all of the dependent issues have been completed.

Here's an example: https://github.com/simonw/datasette/issues/1105

It's not nearly as sophisticated as what you're looking for in terms of date estimates and critical paths, but it does work well for light-weight dependency tracking.

Re: GitHub Issues-only project management

#46

Post by orcasushi » Sat, Aug 21, 2021, 7:30 PM UTC

I am sometimes thinking about use master branch of my repo and add a folder called 'tickets'. Then in this folder create issues as markdown files. Use some Vscode, Emacs or Vim plugin to automatically number these markdown files and present comments as lists.

No more dependency on online saas tooling and you can use the search option of your ide / os / command-line to search through them.

Re: GitHub Issues-only project management

#47

Post by codesternews » Sat, Aug 21, 2021, 7:34 PM UTC

quesodev wrote: post #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 G…

Not related but your landing page is good. May I know what template/how did you build it. Thanks

Re: GitHub Issues-only project management

#48

Post by nkozyra » Sat, Aug 21, 2021, 7:41 PM UTC

mwcampbell wrote: post #3

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.

You don't really need this, though. Github has a project board, too, and it's ... pretty good!

My gig is still in Trello-land and I'd like to move away from it but companies have a tendency to include biz folks in Trello whereas Github is scary tech world to a lot of them.

Re: GitHub Issues-only project management

#49

Post by judge2020 » Sat, Aug 21, 2021, 7:44 PM UTC

nkozyra wrote: post #48

mwcampbell wrote: post #3

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.

You don't really need this, though. Github has a project board, too, and it's ... pretty good! My gig is still in Trello-land and I'd like to move away from it but companies have a tendency to include biz folks in Trello whereas Github is scary tech world to a lot of them.

Worth checking out the new GitHub Issues beta: https://github.com/features/issues/

Re: GitHub Issues-only project management

#50

Post by pbiggar » Sat, Aug 21, 2021, 7:45 PM UTC

judge2020 wrote: post #49

nkozyra wrote: post #48

Earlier quoted context omitted.

You don't really need this, though. Github has a project board, too, and it's ... pretty good! My gig is still in Trello-land and I'd like to move away from it but companies have a tendency to include biz folks in Trello whereas Github is scary tech world to a lot of them.

Worth checking out the new GitHub Issues beta: https://github.com/features/issues/

Signed up for it to use with darklang a few weeks ago but haven't heard anything - are they adding more people to the beta?