We just moved to GitHub for issue tracking to reduce friction for contributors. However, this choice was made at the expense of core contributors who could work more efficiently using a more powerful tool like Phabricator or Monorail.
Here's a list of important missing features we encountered:
Recursive issue dependencies. We used to use issue dependencies as a powerful project management tool in Phabricator:
It's possible to roughly approximate this by manually curating lists of blockers, but that's nowhere as useful. We could build a bot which edits issues to insert a similar tree of issues.
Issue resolutions (i.e. Wontfix, Resolved, Invalid...), rather than just "Closed".
Ability to watch labels to be notified only about specific components in our monorepo, rather than watching the whole repo. This isn't just impossible to do in the UI, you can't even filter email messages since they don't include the labels!
Hotlists for triage/grooming.
Marking issues as private (for security issues to be unrestricted eventually, or collaborating with customers - we could abuse Security Advisories for some of that, but those aren't usable for day-to-day issue tracking).
A Write role equivalent only for issue tracking. Some triage tasks like creating labels require Write permissions, which also allows creating releases/tags or merging PRs.
Complex queries for labels (like searching for "needs triage" OR "hotlist-123").
Custom linkify for issues (we currently have to write out monogon-dev/monogon#123 for fully qualified issue references, rather than being able to use a custom format like mng.link/123).
UI annoyances:
The issue list is hard to navigate with many issues and labels. Compare the Kubernetes issue tracker to the Gerrit one - the dense Monorail UI looks a bit unfriendly, but is much more useful for triage and backlog management (and note the grid view and how any label can be made into a column!)
No way to mass edit issues (both Monorail and Phabricator have nice batch edit UIs).
We just moved to GitHub for issue tracking to reduce friction for contributors. However, this choice was made at the expense of core contributors who could work more efficiently using a more powerful tool like Phabricator or Monorail.
Here's a list of important missing features we encountered:
Recursive issue dependencies. We used to use issue dependencies as a powerful project management tool in Phabricator:
It's possible to roughly approximate this by manually curating lists of blockers, but that's nowhere as useful. We could build a bot which edits issues to insert a similar tree of issues.
Issue resolutions (i.e. Wontfix, Resolved, Invalid...), rather than just "Closed".
Ability to watch labels to be notified only about specific components in our monorepo, rather than watching the whole repo. This isn't just impossible to do in the UI, you can't even filter email messages since they don't include the labels!
Hotlists for triage/grooming.
Marking issues as private (for security issues to be unrestricted eventually, or collaborating with customers - we could abuse Security Advisories for some of that, but those aren't usable for day-to-day issue tracking).
A Write role equivalent only for issue tracking. Some triage tasks like creating labels require Write permissions, which also allows creating releases/tags or merging PRs.
Complex queries for labels (like searching for "needs triage" OR "hotlist-123").
Custom linkify for issues (we currently have to write out
monogon-dev/monogon#123
for fully qualified issue references, rather than being able to use a custom format like mng.link/123).UI annoyances:
None of these features appear to be on the public roadmap: https://github.com/github/roadmap/issues
(we use Gerrit for code review, so this list doesn't include missing features related to that)
CC @q3k