GitHub introduces sub-issues, issue types and advanced search
29 comments
·January 16, 2025decide1000
captn3m0
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).
Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-bui...
Gigachad
I can handle these 3 changes but if they take it any further it's going the way of jira..
globular-toast
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.
paradox460
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
eviks
> 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
Calzifer
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.
IshKebab
> well administrated Jira
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.
StableAlkyne
> Maybe priority/severity or status/resolution?
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?
chrisandchris
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).
politelemon
The issue types are similar to labels. I wonder why they didn't build on that.
Springtime
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.
kkaatii
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.
WorldMaker
It's also not that different from what people have been using Task Lists for today: https://docs.github.com/en/get-started/writing-on-github/wor...
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?
trallnag
You can use a single type of issue in Jira and just rely on linking them together
IshKebab
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.
kkaatii
Wow i didn't know that.
whataguy
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.)
Wicher
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).
prymitive
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.
stock_toaster
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.
bnewman85
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?
atq2119
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 am not sure if I am going to like this feature. I miss the simplicity. Guess those times re over.