Disclaimer: I despise Jira with the energy of a thousand suns.

With that out of the way, yes, we use GitHub Issues for managing projects. We have about 40 repos, each with their own issues but each repo is pretty much a standalone project. Every repo gets a sprint planner "project board" which allows us to track progress and see who is working on what. The fact that we can automate some stuff with strings in commit messages is useful, and the paper trail left by doing so is incredibly helpful. Plus it's fast enough that you can actually get stuff done, rather than sitting watching Jira load some text at 56kbps modem speed over your 1gbps fibre.

Things that it lacks - any kind of sane permissions stuff. For a user to be able to add a ticket to the sprint planner, or even move one I think, requires giving that user write access to the repo. This just seems batshit crazy to me. We have clients who, if they so wished, could hose the entire repository just because we wanted them to be able to use the sprint planner.

That’s interesting about the permissions. Should be mitigated to some extent by branch protection rules?

GitHub has a new version of "projects" in Beta. We've been using it with a small team of developers for a few months and it is amazing. It matches exactly with my mental model of project management.

We have a single "project" for all backend development that contains issues from multiple repositories. We have three views over the project:

- Backlog, which contains all open issues

- Current sprint, which is an agile board with todo, in progress, QA and done columns

- Next sprint, same has current sprint except all issues are in todo

The key aspects that other solutions like Trello don't have is the ability to group issues from multiple repositories and have multiple views over these issues. Last time I checked Gitlab had the ability to do something similar but it was tied to an expensive enterprise tier.

We've been using GH issues and project boards for about 5 years now. Sometime next week we will be into our 12,000th GH issue.

The biggest secret to making issues work for us is that we maintain a monorepository for the org. This means that each issue can cover an atomic pr/commit that updates everything. This also means that we have one monotonic integer sequence that identifies all problems we care about. When someone says "issue #1234", we know the precise URL already. The links between PR/issue/code are invaluable too. It's all right there.

I haven't been using the project boards as much, but others on the team report good results with these (esp. the new beta one)

For me, the biggest PM tool for issues are the labels. Most of our process centers around 5-6 labels that the team knows how to respond to.

GitHub issues are great from a developer perspective, much easier to work with than Jira and most other solutions.

But from a project management perspective it does lack in some perspectives. This mostly depends on what you need and how you use it. Unlike Jira, Github issues does not come with plugin support and can't be customised as much. This makes it easier to work with for developers but might not give you all the power you might want while planning the project. For example, to my knowledge, theres no way of assigning "Story points" and having "burn down charts" in Github issues; as its not a tool ment for doing Scrum. But if you're not doing Scrum then it doesn't matter. It also doesn't have a concept of sprints and epics. But I does have both tags and releases which you can use for planning.

And the new Github Issues beta looks to add a lot of features: https://github.com/features/issues

We have just sanitized our process of using GH as our primary project tracking tool. I have been a huge fan of Kanban and I have set up the process around it.

The top level stories are tagged as Epic and it is easy to create sub-tasks. You can create a checklist item and convert it into an issue. Every Monday, we look at the project board, pick issues that we want to get closed that week and assign them to a specific engineer which shows up as To-do in the project board. There are always slightly more in To-do than can be completed in a week and the cycle repeats.

I found this very comfortable to work with. I know what is being worked on at any given time and what the next set of priorities are. Engineers like this because they can plan their time and creating sub-tasks is easy. Every task is associated with a commit (we use a monorepo).

I used it a few jobs back. By management decree we were supposed to be using Asana for everything, but it was extremely painful not being able to format snippets of code or cross-reference code or commits. Maybe Asana can do those things now, but luckily we managed to convince them to let us use GitHub issues.

It was a small company with a single small dev team, so we didn’t really feel a want for any JIRA-like features. But after that I’ve only worked for big multi-team JIRA shops. But I’m not sure if the whole JIRA bureaucracy is actually necessary or even all that helpful at scale.

It’s ostensibly a solution to the velocity problem, but even with a perfect burndown chart we tend to spend an order of magnitude more time than anticipated, only to discover in the end that we built the wrong thing.

I suspect that the real reason is that the devs and domain experts consistently fail to communicate, and when they try they rarely even use the same language to describe the same domain concepts. I think that if we can solve the domain communication problem the velocity problem will solve itself without JIRA style bureaucracy.

Github issues isn't really a team management tool IMO. It's more of a support desk for users of that specific repo. You can try to bend it into a team management tool, but it is limited and probably won't work well unless the team is tiny.

I've seen Github issues work well in a few cases:

- Open source project needs a public facing place to collect tickets specific to that repo - works great!

- Internal tools team needs an easy way to collect bugs and issues from other teams in the company using the repo.

- You are a two-person start-up with exactly one repo and just don't need anything more complicated yet.

But beyond that, you will pretty quickly hit the limits of GitHub issues. Assuming all your code isn't just in one repo, it will become impractical to manage tasks across projects.

Jira is a pain to learn and configure, but it works pretty well after you get it set up and it scales well as the company scales. There are probably 20 other task tracking tools that work well enough for a small team. But Github issues is probably too limited except for a tiny team IMO.

We do, extensively, both internally and externally. In fact, we don't have any other explicit way to order engineering work. (There's always the "inside the CTO's head" priority list, but we strive to get that into GH issues.)

https://github.com/fusionauth/fusionauth-issues/issues is our main external facing repo. We use it:

* to track issues. Every code change should tie back to an issue in this repo.

* to get feedback from the community. People can upvote issues that are important to them.

* to take input from the community. If someone wants a feature added or a bug fixed, we ask them to file an issue. This is a desired bit of friction (if you can't be bothered to file an issue, then you probably don't care that much).

* to expose the near term roadmap to customers and community members (we do this using milestones)

* to expose our decision making and prioritization process. We've had customers say they loved that about our product. The product is not open source, but the development process is as transparent as we can make it (see https://github.com/FusionAuth/fusionauth-issues/issues/1577 for example).

It's great for all those things. On to your concerns:

* bug reporting: yes, but make sure you use templates

* sprint/epic management: okay for that. Not easy to tie bugs together in any structured way (we use a 'related bugs' section of the issue description, but that depends on frail humans to keep it up to date)

* release management (from development, to code review, to QE verification, to release): less familiar with this, I know there is a kanban view that we've used. Milestones are useful here.

* integration with non-engineering teams (ie, letting customer support/customer success tag issues that customers have brought up): as long as they are GH knowledgeable, it'll work.

From my limited jira experience, it's much more powerful when you have teams of teams and need reporting and customization. But for a team our size (<10 engineers), GH issues has been great.

Kinda unrelated, but I actually had never thought about doing a "reverse open source" like this, with open development but closed source.

Having worked in strictly open products in the past, there's a lot to be gained having your issue tracker public, and letting anyone interested joining the discussion.

It's not like you are doing military stuff or anything that needs to be that secretive, and if there is something secretive, you can just use another project.

Yup. The value from people being able to make and find feature requests and vote on them far outweigh the value of a "secret roadmap".

We've definitely guided large chunks of our development effort from this issues list.

Jira is almost always overkill IME. We used GH issues at ZEIT (now Vercel) back when I was there and were considered quite the productive team. I still stand by that decision, though I don't know if Vercel still only uses GH issues or how that's scaled for them since I left.

It's noticeable that although Jira auto-links to GH branches and PRs, they don't do the same for issues -- I guess they would rather you use their application for that. That they put their own interests before those of their users is revealing.

We mainly use Jira which manages more then just dev tasks and the we use BoardGenius.io to sync Jira dev tasks and comments to Github issues which our devs like to use. It also keeps them focused and out of the Jira mess.

For integration with non-engineering teams, a good idea is to create a separate repo that just contains issues to reduce how many people have access to the code. You can still link to prs from your code repo(s) within the issues and they can be closed automatically when the pr is merged.

I'd suggest you also take a look at Linear (https://linear.app). I've been using it at my current and previous company, and for personal project management - it's simply flawless!