The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy.
This create-a-subissue-when-needed way is more sensible.
I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
Yeah we ended up doing this. You should basically never use Epics or Subtasks in Jira because they have weird unnecessary restrictions that don't apply to normal tasks, especially around putting them in sprints.
Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago.
Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).
GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?
Great, a few more decades and it might become a usable bugtracker.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
Totally off topic, but Tags can be moved too. ;)
It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
I think 99% of the problems with Jira stem from trying to use it for too many things at the same time.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
> At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.
You jest, but I tested this and it turns out that it was JavaScript, not slow networking, that made Jira so slow for me. (I was trying to figure out how to locally cache assets to speed it up.)
The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.
My guess is that self-hosted versions have an infinitely simpler user experience when it comes to accounts and visibility. Jira Cloud is definitely angled towards always being behind some sort of an account system, which used a real, costly backend, but the self-hosted one can get by with the local hosted IdP or an LDAP server.
I don't have practical experience with JIRA Cloud Operations, or JIRA on-prem operations, but if I compare on-prem vs SaaS of our own solutions, the answer is scale and focus.
If I combine our three internal ticketing systems, we end up with something like 200k - 300k tickets, with maybe up to 5M comments on those in JIRA-Terms. If you throw a small-ish, decently configured postgres with 8GB - 16GB of memory at it, it'll keep most to all of that in memory at all times, indexes will be analyzed and fine-tuned to your specific dataset. It will answer queries very, very fast. Any cache in the application servers will also be primed with your data 24/7, speeding it up even further.
JIRA Cloud is most likely not an in-memory problem as a whole at a database layer, so it is at quite the disadvantage performance wise for a small customer.
(In case this turns into a SaaS-Hate-Thread: Yes our customers could have a faster system if they were on-prem. If they had the same experience and expertise running postgres as well as all the other necessary middlewares. And then we're not talking about non-functional operational requirements such as availability, emergency scalability or backups yet)
Yeah I have no confidences in GH to become viable for issue management for large commercial projects.
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.
I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.
IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
Let us comment on the commit messages and create a better UI for editing messages for teams that take git history seriously, please. Are there no linux kernel devs at msft who can make this happen?
In the same vein, better reviewability of series of commits. It's absolutely baffling to me that
GitHub still doesn't support the original workflow for Git.
I'm remembering the Redmine slide from Zach Holman's talk, where he makes fun of the overly complicated Redmine issue creation screen, compared to what the GitHub screen looked like (back in 2011).
This is fiction considering Microsoft is extensively using Azure DevOps internally and is still developing it. Moving projects away from it and to GitHub is impossible because they're incredibly far from having feature parity.
Feature parity is probably not required as long as the different teams are able to adapt their workflow to GitHub's approach. Anecdotally, every employee from Microsoft I've talk to about this point during the last two years keep telling me that ADO is over.
Feature parity is absolutely required. We are ADO customer because A) Inertia and B) GH Actions is nowhere close to features of ADO Pipelines.
Every conversation we have with Microsoft about our ADO -> GH migration is either get GH to feature party or if you force us to migrate, we will evaluate ALL our options.
People have been saying this for half a decade, and fearmongering everyone into moving elsewhere (sadly my team fell for it).
Azure Devops is such an underrated tool, it's a shame that it's being ignored by Microsoft. Not only that, but they're enshittifying it by turning into Github. I kid you not, it actually went backwards in terms of features. E.g. Instead of nifty UIs that was implemented for their pipelines, we now instead have to write shitty yaml files with absolutely no validation and guidance. This is the same company that (re)wrote Word, Excel and Powerpoint in the browser! The mental whiplash from witnessing this is very jarring.
That's not how it works. It is going the way of Jira. What you mean is if it keeps going that way it will be Jira.
Until we get to the point we can decide things are finished and move on to other problems, everything will turn into Jira eventually. It's like entropy. We have the power to stop it, but it wouldn't guarantee those sweet, sweet growth targets.
The problem is Microsoft has two products in this space but everyone hates Azure DevOps which is supposed to be a JIRA competitor and GitHub is where all the momentum is. They'd love to ditch having to maintain ADO and GitHub long term but that means crapifying GitHub so they can migrate their ADO customers. At the same time they're hoping to pull Atlassian customers that use JIRA and GitHub to ditch the latter and just entirely be on GitHub.
What well end up with is a service that sucks to use for all cases.
I really dislike the use of former and latter. It’s confusing, people get it wrong, and it can be interpreted at least two different ways to make it ambiguous.
ADO almost made me want to use Jira instead.
Turned out that,
while the product it not great,
the pain I experienced using it had more to do with corporate processes than the software itself.
Overall, the claim above, as written, is a rather generalized prediction, not an inevitability.
Enterprise buying power and expectations create various pressures, sure. But there are other pressures and factors that need to be accounted for such as demands from other types of customers and the company’s expertise with what has worked well so far (simpler is better, compared to Jira).
Entropy is a law of physics, sure, but the ways and degrees to which it manifests in software is far from obvious or inevitable.
We live in a world of possible future scenarios, not of narrative-based certainties.
I predict GitHub Issues will remain considerably simpler than Jira for the next five years at least. As code analysis tools improve (traditional static analysis as well as LLM-based), I think we will see a lot of experimentation in this space.
It is less simple, but nowhere Jira-level, and yet still more useful (for my team and I).
We've been using GH Projects at my current org and program for two years. The one feature I wish it had was nested issues.
In Jira, you had Epic > Task > Sub-task and that's it. With GH, you can just have issue > issue > issue (insert "it's turtles/issues all the day down meme"). So it's more powerful, but can be ignored by folks who don't want to do this.
GitHub is free for most people, so they are only beholden to large organizations and their feature requests. This is how it seems now - a feature creep by committee. It's getting more and more bloated and unwieldy, sort of like what happened to AWS.
They also changed the design of issue comments, but seemingly reverted it back to the old design in production? (If you check the first video on the blog you can see e.g. the profile picture inside of the comment, while the old and current version has it on the outside.)
> This means there are no new UI patterns to slow you down,
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
Longer paths, especially ones like these that require keyboard input, are especially painful from an accessibility perspective, where for most cases such typed fields make things take exponentially longer than if it can be achieved by just clicks/tabs/arrows.
There is a huge wall of placeholder being replaced with issues when the issues tab loads, which is pretty annoying when you got used to the old UI.
But it’s nice to see M$ can still deliver features without Autocomplete Integration forced in it.
It's neat there are more options for filtering though ime the new issues UI is less responsive, showing placeholder skeletons more frequently than I'd like. Perhaps less noticeable when a fast connection is always available but even just showing the total Open/Closed ticket counters can take a few seconds when it used to be instant.
From Copilot integration that you can’t disable if you accidentally clicked something once (you can only now as of a few days ago hide the UI, but you are still not able to disable it in settings), to this issues UI aglomeration.
The Microsoftization/enshittification of Github continues apace.
Not bad, but I still have to say that zenhub does it better
Used that at an old job and it was the only project management software I didn't grow to hate. Fast, "built into" GitHub, and adds other value across the site, I miss it now at my current jira gig
Its one of those things that I will forever evangelize for, because the one time I was able to use it, I had my most productive year ever. My github activity graph for the 18 months I got to use zenhub looked like a beautiful green meadow.
I've tried most other project management software. They all stink in one way or another. JIRA is a known problem, ClickUp, Monday, and friends aren't much better. I never liked pivotal, and its dead now, so doesn't really matter. And Github's projects feature is just too spartan to be useful
I, for my part, would be happy if they could make basic search work for a start. Will the advanced search finally allow us to find the most basic things reliably?
A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.
Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
GitHub doesn’t have ads and makes its money off of enterprise subscriptions (and Copilot), so I don’t think “engagement” is a very important metric for them.
Wait if it's not their core product, what is? GitHub is, at its core, a file/history browser + issue management system + merge request system built around Git. There's not that much to it other than issue management.
It's core product is git hosting, you use it to host your git repositories. You use features such as Pull Requests to power how you merge within your git repositories. If the issue system isn't working it's not a big deal, but if we can't use git it's a massive deal. It's all in the name GIThub
Most companies don't use GitHub's issue management system they use issue management tools such as JIRA, Trello, etc. Issue management, project management, CI/Actions, wiki, discussions, etc are all nice to haves and are probably more aimed at the open source projects that are used as a marketing tool.
Most open source projects (you know, the thing GitHub claims to exist for) do pretty much exclusively use GitHub issues for issue tracking though. GitHub makes it pretty difficult to be on GitHub and not accept GitHub issues.
For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.
In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.
The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.
We made a similar thing too for our community discord where you can add an Emoji on a message and it will look for similar issues with a simple RAG. That saves us so much time when a user asks if a feature is planned or not.
We also ask them to go upvote the issue or create one in the response.
Not open source right now but if people are interested I could clean up the code.
Oh yeah, that looks super similar. I remember the similarity score being tricky to get useful signal out of, for the underlying model I had used back then. Similar and dissimilar issues all hovered around the 0.80 mark. But surely not hard to improve on, with larger models and possibly higher-dimension vectors.
If only Microsoft was interested in finding actual useful use-cases for their machine learning tech instead of constantly selling everyone on their chat bot...
If we're talking issues (i.e. reports from external parties, like OSS users, and not internally defined tasks), then care is needed to avoid it working out like the Stack Overflow experience. What is it, you ask?
[Closed; Locked: not constructive; Duplicate of: #1701, #74656]
Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.
Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.
--
[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.
I refuse to work with projects with a stale bot. As if ignoring an issue will just magically resolve it. I also refuse to use products with a stale bot once I discover it is used; they are usually bug ridden due to uncovered issues being ignored.
this happens after I've moved everything to height. downside is it was a lot of work. upside is height is amazing and I'm pleased with the choice. anyone else using it?
We are loving it and we aren't even using it fully to its ability. For example we do almost no communication in the 'chat' that exists for each issue (in place of comments) since we are a very small team and still are talking mostly in slack about the issues, but I predict as we grow this will become a useful feature for us.
In the meantime we are loving the 'every issue can have sub-issues' and have customized the fields to our liking.
This is a tool with a lot of power. I can see a well-intentioned PM going crazy with it, but for our needs I was startled with how great it is.
Instead of these features I want them to stop spam issues on my repos. All the issues I've gotten in the last year on my project are completely nonsensical. It's not even spam it's just like random URLs or complete nonsense from freshly created accounts that aren't trying to sell anything or just the issue template. And every time it costs me 2 clicks to click on "report" then I have to type "spam", click the spam category, then I have to type "it's spammmmmmmmmmmmmmmmmmmmmm" to hit the 15 character report description requirement, then I have to solve a captcha. All this despite the fact that I've had a GitHub account for like a decade and I've filed like 30+ spam reports, none of which were frivolous.
I opened GitHub after typing this comment and there it was, a notification from an obvious bot account opening an issues that's just 5 meaningless Korean letters with no description.
Ah this really feels like they could have tackled https://github.com/orgs/community/discussions/4993 too, what a missed opportunity, I'd love to be notified about some repositories again, which I had to unwatch now because of daily autobuild spam.
212 comments
[ 5.0 ms ] story [ 242 ms ] threadGood that issue types can be user defined.
This create-a-subissue-when-needed way is more sensible.
I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
https://en.wikipedia.org/wiki/Windows_Registry
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags.
How do you envision this differing?
I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
Based on my experience that doesn't exist.
Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah.
A colleague joked that we need a "waiting for Jira" Jira task.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.
If I combine our three internal ticketing systems, we end up with something like 200k - 300k tickets, with maybe up to 5M comments on those in JIRA-Terms. If you throw a small-ish, decently configured postgres with 8GB - 16GB of memory at it, it'll keep most to all of that in memory at all times, indexes will be analyzed and fine-tuned to your specific dataset. It will answer queries very, very fast. Any cache in the application servers will also be primed with your data 24/7, speeding it up even further.
JIRA Cloud is most likely not an in-memory problem as a whole at a database layer, so it is at quite the disadvantage performance wise for a small customer.
(In case this turns into a SaaS-Hate-Thread: Yes our customers could have a faster system if they were on-prem. If they had the same experience and expertise running postgres as well as all the other necessary middlewares. And then we're not talking about non-functional operational requirements such as availability, emergency scalability or backups yet)
https://thedailywtf.com/images/200802/manualJira.jpg
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-bui...
I guess it's Microsoft slowly making it cater to their enterprise clients
Every conversation we have with Microsoft about our ADO -> GH migration is either get GH to feature party or if you force us to migrate, we will evaluate ALL our options.
Azure Devops is such an underrated tool, it's a shame that it's being ignored by Microsoft. Not only that, but they're enshittifying it by turning into Github. I kid you not, it actually went backwards in terms of features. E.g. Instead of nifty UIs that was implemented for their pipelines, we now instead have to write shitty yaml files with absolutely no validation and guidance. This is the same company that (re)wrote Word, Excel and Powerpoint in the browser! The mental whiplash from witnessing this is very jarring.
Until we get to the point we can decide things are finished and move on to other problems, everything will turn into Jira eventually. It's like entropy. We have the power to stop it, but it wouldn't guarantee those sweet, sweet growth targets.
What well end up with is a service that sucks to use for all cases.
Overall, the claim above, as written, is a rather generalized prediction, not an inevitability.
Enterprise buying power and expectations create various pressures, sure. But there are other pressures and factors that need to be accounted for such as demands from other types of customers and the company’s expertise with what has worked well so far (simpler is better, compared to Jira).
Entropy is a law of physics, sure, but the ways and degrees to which it manifests in software is far from obvious or inevitable.
We live in a world of possible future scenarios, not of narrative-based certainties.
I predict GitHub Issues will remain considerably simpler than Jira for the next five years at least. As code analysis tools improve (traditional static analysis as well as LLM-based), I think we will see a lot of experimentation in this space.
We've been using GH Projects at my current org and program for two years. The one feature I wish it had was nested issues.
In Jira, you had Epic > Task > Sub-task and that's it. With GH, you can just have issue > issue > issue (insert "it's turtles/issues all the day down meme"). So it's more powerful, but can be ignored by folks who don't want to do this.
Microsoft is a juggernaut.
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
The Microsoftization/enshittification of Github continues apace.
Used that at an old job and it was the only project management software I didn't grow to hate. Fast, "built into" GitHub, and adds other value across the site, I miss it now at my current jira gig
I've tried most other project management software. They all stink in one way or another. JIRA is a known problem, ClickUp, Monday, and friends aren't much better. I never liked pivotal, and its dead now, so doesn't really matter. And Github's projects feature is just too spartan to be useful
Also see https://news.ycombinator.com/item?id=35144250
Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
Why not? Companies love to boast about MAUs and similar metrics (even if completely bogus), it has good effect on stock prices.
Most companies don't use GitHub's issue management system they use issue management tools such as JIRA, Trello, etc. Issue management, project management, CI/Actions, wiki, discussions, etc are all nice to haves and are probably more aimed at the open source projects that are used as a marketing tool.
You can easily disable issues.
For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.
In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.
The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.
https://github.com/alexpovel/issuedigger
Not open source right now but if people are interested I could clean up the code.
So I wrote a simple app for fun to navigate and search GitHub issues like emails and even reply
Screen recoding https://x.com/justruky/status/1878507719520387347
But you’re completely right, GH search is truly bad
[Closed; Locked: not constructive; Duplicate of: #1701, #74656]
Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.
Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.
--
[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.
We're looking for a new home, with Pivotal Tracker shutting down on April 30th (101 days left!). I had not heard of Height before.
On first glance, it looks like a genuinely modern project management service -- which is both interesting and unsettling.
In the meantime we are loving the 'every issue can have sub-issues' and have customized the fields to our liking.
This is a tool with a lot of power. I can see a well-intentioned PM going crazy with it, but for our needs I was startled with how great it is.
https://github.com/orgs/community/discussions/52932
I opened GitHub after typing this comment and there it was, a notification from an obvious bot account opening an issues that's just 5 meaningless Korean letters with no description.
I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.