I think the biggest weakness of github issues is that the main content it shows when you visit an issue page is the original report.
That's very often unhelpful because:
- it's likely that the actual problem wasn't understood at that point (it's likely to be describing a symptom, rather than a bug)
- it's quite possible the original reporter wasn't very good at writing bug reports
- issues often remain open after the main underlying problem is fixed, because there's some small remaining part that's unsettled.
I'd much prefer it if the topmost part of the page was reserved for a space, maintained by whoever's responsible for dealing with the issue, describing the current understanding of the problem and the current status.
Then the orignal report and further discussion could be laid out under that as at present.
It's possible to get roughly this now, by repeatedly editing the initial message. But the UX isn't ideal, and more importantly it isn't culturally expected.
(Of course this isn't a github-specific problem. But github are in a better position than most to offer a fix.)
GitHub issues have edit history now IIRC, so the maintainer can just edit the ticket in these cases, and still have the original text available under the "edited" submenu.
Noooooo! I’ve been hoping for years and years to eventually land on a team that uses GH issues so I can not hate our ticket tracker for once, but they’re gonna shit it up like ADO and Jira and Asana before that can happen. They’d already made it borderline too complicated, this will complete the transition from productivity to “legibility”.
Just to add a different opinion: I have been using Jira my whole life and I am now using GitHub issues full-time and I like it a lot, I also like these new changes and I'm looking forward to even more to dependencies between issues.
This is the constant problem with issue trackers. You start simple and over a few years various people have legitimate needs that the system isn't solving so they make some small changes to work better. Then one day you look and realize the system is far too complex so you start over with a simple system - which of course doesn't meet the needs of the people above and so they slowly get that complexity added back. I've seen it over an over again, and I expect to see it again because what I need is a simple system, but there are other parties who need various complex things that I can't keep track of.
The simplification above isn't all bad - you often discover that 25% of the complexity in the system isn't needed anymore and so that doesn't come back. However there is always new/different complexity needed.
Couldn't agree more. Creating taxonomies has to be a dopamine hack or something, because humans will spend hours and hours on them. They will be left feeling rewarded and accomplished, despite accomplishing very little. It's playing Solitaire in a way that keeps your boss happy.
If it turns out to be too complex, Codeberg and SourceHut are some actually nice alternatives that exist now. Not like GitLab which brought its own complexity.
This was inevitable. Microsoft probably doesn't want to support both Azure DevOps and GitHub long term. GitHub needs to gain the most important features of ADO that ADO customers care about.
ADO has felt borderline abandoned since MS bought GitHub, and honestly good riddance, it feels terrible to use.
For example having more than 1 user edit anything is almost unsupported, and pages will regularly do things such as telling you that you ought to refresh to see changes, rather than just showing you the changes.
Or on other pages, anyone elsewhere changing anything at all will just trigger your page to refresh so you lose your place. This is particularly noticable on the sprint board, where if you view "all expanded" or "all collapsed", the refresh will often also reset that and throw you to a completely different part of the board.
The code review is even worse, despite some modest attempts at improvements, because you can't stage a batch of comments. Each and every comment is hand-delivered with a notification email to the recipient, so writing out a bunch of comments feels like a disruptive activity.
If Issues could be restricted to repo maintainers (with everyone else using Discussions), it would make contributing to F/LOSS projects far easier because you could easily see what the team was "thinking" (PR lists aren't like that).
As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.
I have no interest in the Jirafication of Issue though. None at all.
I agree. The issue with Issues and Discussions is no one knows where to put content. Most falls into Issues because Discussions aren't always enabled and Issues were the original dumping ground.
It would be nice to know that if you want to ask random questions or get guidance on how to use the project, go to Discussions. If you're looking for real bug reports, go to Issues. I'm not sure how to enforce Issues being only bug reports though. The first thing that comes to mind is having a triaging mechanism, but that puts more onus on maintainers to actually look through everything submitted and make a decision on it.
I'm sure you know but just to make sure. You can use Issue Templates to steer people towards Discussions. It's not perfect but it can help a bit at least.
Yes, we've got that and it does help a bit. But we're often forced to be heavy-handed and just close junk issues with a comment asking the poster to open a Discussions thread. I feel bad about doing that though as it's hard not to come across as unfriendly.
I do some things to try to separate and subtly prioritise bug reports and discourage excessively cluttering the tracker with ideas (some are useful to discuss there, but not all).
- Issue types, using labels: (Almost) every issue’s first label is A-BUG in weighty red or A-WISH in less substantial pink. The spellings keep these two first among labels and most visible. The word “wish” is carefully chosen. I attach one of these on first sight of a new issue.
- Shortcut urls that redirect to a view of one or the other of these, making it easy (for me at least) to focus: bugs.foo.org and wishes.foo.org showing just those, issues.foo.org showing both, prs.foo.org, regressions.foo.org, etc.
- New issue template that gives (short!) guidance and a hint that mail list and chat room are good for discussion and brainstorming. (GH Discussions would be pleasant now, but I’m not keen to fragment discussion more, or lock in even more on GH)..
I feel this new version could help with that if unapproved users are restricted in the types of issues they're allowed to create. Something like "external". Or vice versa, they can't create "Internal" issues. But I immediately see a problem which is that types are not tags so the dichotomy of internal/external means that types now can't be used for type-of-work, only channel-of-input. So you'd be back to using tags for the former...
I've observed it has become much better on my repository over the past few years.
Discussions took a while to be adopted and I have to guide users to discussions through the CONTRIBUTING.md and issue template.
For the few questions that still comes in the issues, i'm immediately converting them into discussions.
> As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.
Totally agree. They should have some AI solution categorize the issues and separate actual issues/tickets from support requests and other noise.
I built the last major update to GitHub Issues over a decade ago now, and I was... kind of hoping for more. Feels more like it's checkbox-driven development instead of sitting down and really planning long-term about what improvements could be made. Also it has React.
Zach your conference presentations back when you were at github were amazing to me, and were such a huge reason I applied for a job at github. I've been there for 7 years now and I just wanted to thank you for being you.
I don't get the negativity. This is a great upgrade for enterprise user persona and is a catch up comparing to Gitlab Issue or Linear. I hope they put more effort into this.
Serving the “enterprise user” (the enterprise project manager and product owner, specifically) personas is why most other solutions are already so unproductive and unhelpful for the people doing the actual work. That’s where the negativity comes from. It’s like a mechanic’s ratchet having all kinds of bullshit attached to it to measure how many turns it makes and which socket’s getting used the most: that’s probably useful info for someone, but now the tool is terrible for the mechanic.
I think that's one way to look at productivity. I used to think like that when I was in a dysfunctional team as well. However, I do see value in issue tracking as I have seen how it helped drive top-down decisions on a large scale with high impact. An effective issue tracker can improve how resources are allocated, and create incentives, and promotions in smaller teams. The bigger the org, the harder it is to make this kind of decision correctly so there is value to be made here.
Tracking’s important. I think most of what matters could easily be achieved with simpler tools and less-intrusive processes, though, and in practice most of these attempts at hyper-legibility are misguided, largely because nobody’s even measuring the full cost of them.
Please god add a “closed - duplicate,” “closed - won’t fix,”and maybe “our bot closed this because no one commented on it for 6 weeks” status.
Nothing is more frustrating than finding an issue that exactly describes what your are experiencing marked “closed,” scrolling through months of comments only to find that the issue still exists and it’s been closed for one of these reasons.
Labels have been able to do this for years, why are they not a sufficient solution?
And even if they elevated these to first class items, nothing is stopping maintainers from still closing them or letting them be closed without the issue having been actually fixed.
Your suggestion is to add a field that will only be used in a single status, which goes against the simplicity of GH Issues (which this update already makes contentious enough, looking at the comments here).
Also, realistically, there will be a mention of the issue in the final ticket, so is scrolling down to the bottom of the issue that hard? You're making it seem like it'd be buried in the middle of the timeline and while that can happen, I don't see that being anything but an edge case. Most tickets won't be referenced after they're closed as dupes.
This tension is why issue systems become too complex. The ask is reasonable, but implementing it makes the issue system more complex until all the simple asks make the system collapse under the weight of it...
Absolutely. The sum total of reasonable requests can be an unreasonable system. It’s a paradox just like Gabriel’s horn: finite volume, infinite surface area.
Reading through this comment section makes me see exactly how something simple like a GitHub issue becomes a JIRA issue.
This is why I like simple, opinionated solutions. This kind of discussion becomes superfluous.
I'm shocked they haven't added this. Especially with so many projects using bots to close issues just because of inactivty (annoyingly when the inactivity is on the side of the develops, not the person raising the issue).
I'd also say the fixed issues should immediately tell you what PR fixed the issue if possible. It frustrates me to no end when someone says the issue is fixed and they are 5 to 6 referenced PRs in the issue and it's unclear which actually fixes the issue or just mentions the issue in a comment for some reason.
A recurring pattern I see is someone will add an issue comment like "This is great but we need to fix 1. this, and 2. that", and it's just a mess keeping track of discussion threads related to 1 and 2, who is assigned to fix them, and if they're done.
A hack is to add a [ ] checkbox in front of each task (by editing the comment yourself if needed), but then it's not clear if the person that thinks they've completed the task ticks it, or if the original commenter ticks it after they've reviewed the work, and the comment will eventually get folded/hidden.
Another hack is to add a review comment to a pull request anywhere in the code, which at least gives you threaded conversions and a resolved status, but you can't mark who it's assigned to.
Any more hacks here?
Maybe sub-issues will solve this, but if it's similar to creating new issues, that's quite heavy for small items.
Biggest issue with GitHub issues is that large open source projects can't easily signal to viewers which issues are a priority and which are dead or spam. Anytime I see a project with a bazillion issues (like Element), I worry about it's health when maybe I shouldn't because the project is actually fine and the maintainers just use some other ticketing system outside of GitHub.
Aggressive moderation to keep the # open is possible, but not ideal because it causes anxiety for issue-creators and prevents maintainers from finding out about bugs and feature reqs. Some first-class way to differentiate between backlog and todo on the repo would be my #1 request.
I'm unclear myself. For a start, unlike labels, an issue can only have exclusively one type.
From the docs this appears to be how they envision people using this:
Default issue types are included in every organization, but these can edited, disabled, or deleted. The default types are task, bug, and feature.
On the one hand there's already precedence for this, since PRs are sorta just issues that live in a different tab. If issue types actually let people create new top-level tabs in the UI, that might be interesting. Also it looks like there's a maximum of 10 user-defined types per repo, so it wouldn't even threaten to mess up the UI that much if they did so.
We use labels as module tags; e.g. this PR/issue applies to the "filter" module. Having types be its own thing helps separate the two logical categories and enforce "one type per ticket" at the same time.
Our org/team was very heavy users of the never-broadly-released tasklists revamp from a while back, and I was a huge fan of them.
I really liked the organic approach to project management - soft-epics and soft-subtasks, without Github Issues just turning into Jira. It felt like really neat product design (even though it often did have a bunch of sync bugs them them trying to do too much in markdown)
So I was disapointed to see they weren't happy with that and rolled it into an explicit subtasks instead. I haven't used it seriously yet for a project yet though. We'll see how it goes.
Was expecting a link to an outage report . . . pleasantly surprised as I'm currently on-boarding my team to Jira and it's important that every innovation in this space is over-engineered :)
This would cause more distraction than good on most teams I've been on. I have watched coworkers make it their entire career to play around with the GH project management & issue stuff. The more features, the more distracted these people become. I have even caught myself getting distracted from time-to-time.
If we can't effectively communicate work priorities between titles, comments & labels, maybe we need to go back to email for a while.
sub-issues sound nice for grouping issues. But I think there could be an even better solution: Make it possible to declare issues to depend on other issues and milestones. That way you can filter issues out that can not be worked on because some more fundamental infrastructure has to be put in place first.
A PR can be linked to an issue. It should be possible to link issues to other issues and milestones.
if GitHub really wants to fix issues, fix the god damn pagination. the current system is basically:
comment
comment
[bunch of hidden comments]
comment
comment
this is not better, at all. to get all comments, you have to constantly click "more" until all are loaded, IN A SINGLE page. then if you accidentally refresh or navigate away from the page, boom you have to redo the entire process.
Yeah that’s the key question. To actually be competitive with Linear, etc. we need client side rendering and local caching. A basic create-react-app + React Query stack feels much better than GitHub due to the constant SSR for all routing.
Out of curiosity, what would you expect any such UI to look like in that case? Merging the comments? Even right now one can comment "closing as it is a dupe of #666" and GH will cheerfully create bidirectional links, the link in the comment and the other issue will get a "mention" comment
However, it made me think of how much time and money is spent just on organizing things, even when organizing something doesn’t make things go better.
In fact, the best teams I’ve worked on have a bias against organizing and a “just do it now” mentality. It depends on the specific case of course. But as a culture, software engineers have a bias towards organizing too much as opposed to not enough.
This is why a board with sticky notes "TODO - In Progress - Done", is still the way to go for most projects. Easy to manage and you don't need to "groom the backlog" or any of that nonsense. If it's important, it goes on the board. When a bunch of things get done, the notes just go in the trash and you move on to the next thing. If there's too many notes, toss some in the trash and forget about it (if it ends up being important, it's really easy to just write a new note).
The amount of productivity lost to make it quicker for some PM to add a bar graph to a PowerPoint emailed to an exec, that the exec will look at for five seconds and move on if they even bother to open the email, is astounding.
Maybe I am misunderstanding you somehow, but you can turn off Issues without archiving a repository, I have several like that. If I attempt to navigate to `/issues`, it redirects me to `/pulls`. And the Issues tab is not visible whatsoever.
Have you tried `/settings` -> Features -> [ ] Issues ?
History disappears, which is a bit annoying if ppl have invested energies there. I'd personally prefer it possible to lock them without archiving nor making them disappear from the internet :)
Is it an intended that a history disappears, though? I would assume most people wouldn’t expect it to happen when they disable new issues (for instance - temporarily because of taking a break from a project)
> Earlier this year, we introduced the private beta of increased project item limits, expanding the capacity from 1,200 to 50,000 items in a project.
This reminds me why smaller companies can steal market share from larger companies. I can understand that at GitHub scale, it's probably difficult to support more that 1,200 items per project. The result? The entire ecosystem has these limits imposed on them. A smaller company could easily support 50,000 issues for a repository since they are hosting fewer repositories.
Those smaller companies are usually just burning money in an attempt to gain traction. Free services usually have all harsh limitations when the company has to earn their own food. The main reason for this is usually the abuse of those services, not so much that they can't afford it.
I thought this was where OP was going with this comment. My inner LLM predicted the next sentence after “This reminds me why smaller companies can steal market share from larger companies.” to be: Larger companies get bogged down with heavy backlogs where it’s hard to tell what’s actually important to work on anymore. Small companies can stay nimble and focused more easily.
50K tasks in a single project is a joke. People should be forced to konmari it. Put a capacity diagram in their face so they have to constantly confront the reality of their lack of organization.
In GitHub, if you want to put an issue from a repository on a Project board it creates a project item to reference it, thus using an issue. If you have a large project (which I have where we hit the capacity of project items) then you are forced to start deleting issues from the project. Which in my opinion isn't great, because that limit includes project issues that have been marked "done". Then you lose the history of maybe why things were done a certain way.
I think the biggest weakness of github issues is that the main content it shows when you visit an issue page is the original report.
That's very often unhelpful because:
- it's likely that the actual problem wasn't understood at that point (it's likely to be describing a symptom, rather than a bug)
- it's quite possible the original reporter wasn't very good at writing bug reports
- issues often remain open after the main underlying problem is fixed, because there's some small remaining part that's unsettled.
I'd much prefer it if the topmost part of the page was reserved for a space, maintained by whoever's responsible for dealing with the issue, describing the current understanding of the problem and the current status.
Then the orignal report and further discussion could be laid out under that as at present.
It's possible to get roughly this now, by repeatedly editing the initial message. But the UX isn't ideal, and more importantly it isn't culturally expected.
(Of course this isn't a github-specific problem. But github are in a better position than most to offer a fix.)
GitHub issues have edit history now IIRC, so the maintainer can just edit the ticket in these cases, and still have the original text available under the "edited" submenu.
I often edit the title and description of issues.
I usually let the original content after a
### Original message
...
Noooooo! I’ve been hoping for years and years to eventually land on a team that uses GH issues so I can not hate our ticket tracker for once, but they’re gonna shit it up like ADO and Jira and Asana before that can happen. They’d already made it borderline too complicated, this will complete the transition from productivity to “legibility”.
Just to add a different opinion: I have been using Jira my whole life and I am now using GitHub issues full-time and I like it a lot, I also like these new changes and I'm looking forward to even more to dependencies between issues.
https://github.com/github/roadmap/issues/956
I understand that this is your opinion but there are others out there with differing ones :)
This is the constant problem with issue trackers. You start simple and over a few years various people have legitimate needs that the system isn't solving so they make some small changes to work better. Then one day you look and realize the system is far too complex so you start over with a simple system - which of course doesn't meet the needs of the people above and so they slowly get that complexity added back. I've seen it over an over again, and I expect to see it again because what I need is a simple system, but there are other parties who need various complex things that I can't keep track of.
The simplification above isn't all bad - you often discover that 25% of the complexity in the system isn't needed anymore and so that doesn't come back. However there is always new/different complexity needed.
Couldn't agree more. Creating taxonomies has to be a dopamine hack or something, because humans will spend hours and hours on them. They will be left feeling rewarded and accomplished, despite accomplishing very little. It's playing Solitaire in a way that keeps your boss happy.
i have always admired GitHub's issues system for its simplicity.
s/have/had/
If it turns out to be too complex, Codeberg and SourceHut are some actually nice alternatives that exist now. Not like GitLab which brought its own complexity.
This was inevitable. Microsoft probably doesn't want to support both Azure DevOps and GitHub long term. GitHub needs to gain the most important features of ADO that ADO customers care about.
ADO has felt borderline abandoned since MS bought GitHub, and honestly good riddance, it feels terrible to use.
For example having more than 1 user edit anything is almost unsupported, and pages will regularly do things such as telling you that you ought to refresh to see changes, rather than just showing you the changes.
Or on other pages, anyone elsewhere changing anything at all will just trigger your page to refresh so you lose your place. This is particularly noticable on the sprint board, where if you view "all expanded" or "all collapsed", the refresh will often also reset that and throw you to a completely different part of the board.
The code review is even worse, despite some modest attempts at improvements, because you can't stage a batch of comments. Each and every comment is hand-delivered with a notification email to the recipient, so writing out a bunch of comments feels like a disruptive activity.
Overall the experience of ADO is horrible.
As long as they don't add workflows, we're safe.
Love to drag my Jira ticket through like three different approval stages, none of which are relevant to my team.
They kind of have them already in GitHub Projects.
If Issues could be restricted to repo maintainers (with everyone else using Discussions), it would make contributing to F/LOSS projects far easier because you could easily see what the team was "thinking" (PR lists aren't like that).
As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.
I have no interest in the Jirafication of Issue though. None at all.
I agree. The issue with Issues and Discussions is no one knows where to put content. Most falls into Issues because Discussions aren't always enabled and Issues were the original dumping ground.
It would be nice to know that if you want to ask random questions or get guidance on how to use the project, go to Discussions. If you're looking for real bug reports, go to Issues. I'm not sure how to enforce Issues being only bug reports though. The first thing that comes to mind is having a triaging mechanism, but that puts more onus on maintainers to actually look through everything submitted and make a decision on it.
I'm sure you know but just to make sure. You can use Issue Templates to steer people towards Discussions. It's not perfect but it can help a bit at least.
https://docs.github.com/en/communities/using-templates-to-en...
Yes, we've got that and it does help a bit. But we're often forced to be heavy-handed and just close junk issues with a comment asking the poster to open a Discussions thread. I feel bad about doing that though as it's hard not to come across as unfriendly.
I do some things to try to separate and subtly prioritise bug reports and discourage excessively cluttering the tracker with ideas (some are useful to discuss there, but not all).
- Issue types, using labels: (Almost) every issue’s first label is A-BUG in weighty red or A-WISH in less substantial pink. The spellings keep these two first among labels and most visible. The word “wish” is carefully chosen. I attach one of these on first sight of a new issue.
- Shortcut urls that redirect to a view of one or the other of these, making it easy (for me at least) to focus: bugs.foo.org and wishes.foo.org showing just those, issues.foo.org showing both, prs.foo.org, regressions.foo.org, etc.
- New issue template that gives (short!) guidance and a hint that mail list and chat room are good for discussion and brainstorming. (GH Discussions would be pleasant now, but I’m not keen to fragment discussion more, or lock in even more on GH)..
I feel this new version could help with that if unapproved users are restricted in the types of issues they're allowed to create. Something like "external". Or vice versa, they can't create "Internal" issues. But I immediately see a problem which is that types are not tags so the dichotomy of internal/external means that types now can't be used for type-of-work, only channel-of-input. So you'd be back to using tags for the former...
I've observed it has become much better on my repository over the past few years. Discussions took a while to be adopted and I have to guide users to discussions through the CONTRIBUTING.md and issue template. For the few questions that still comes in the issues, i'm immediately converting them into discussions.
> As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.
Totally agree. They should have some AI solution categorize the issues and separate actual issues/tickets from support requests and other noise.
I built the last major update to GitHub Issues over a decade ago now, and I was... kind of hoping for more. Feels more like it's checkbox-driven development instead of sitting down and really planning long-term about what improvements could be made. Also it has React.
Zach your conference presentations back when you were at github were amazing to me, and were such a huge reason I applied for a job at github. I've been there for 7 years now and I just wanted to thank you for being you.
Made me super happy to read that!
I don't get the negativity. This is a great upgrade for enterprise user persona and is a catch up comparing to Gitlab Issue or Linear. I hope they put more effort into this.
Serving the “enterprise user” (the enterprise project manager and product owner, specifically) personas is why most other solutions are already so unproductive and unhelpful for the people doing the actual work. That’s where the negativity comes from. It’s like a mechanic’s ratchet having all kinds of bullshit attached to it to measure how many turns it makes and which socket’s getting used the most: that’s probably useful info for someone, but now the tool is terrible for the mechanic.
I think that's one way to look at productivity. I used to think like that when I was in a dysfunctional team as well. However, I do see value in issue tracking as I have seen how it helped drive top-down decisions on a large scale with high impact. An effective issue tracker can improve how resources are allocated, and create incentives, and promotions in smaller teams. The bigger the org, the harder it is to make this kind of decision correctly so there is value to be made here.
Tracking’s important. I think most of what matters could easily be achieved with simpler tools and less-intrusive processes, though, and in practice most of these attempts at hyper-legibility are misguided, largely because nobody’s even measuring the full cost of them.
Please god add a “closed - duplicate,” “closed - won’t fix,”and maybe “our bot closed this because no one commented on it for 6 weeks” status.
Nothing is more frustrating than finding an issue that exactly describes what your are experiencing marked “closed,” scrolling through months of comments only to find that the issue still exists and it’s been closed for one of these reasons.
Labels have been able to do this for years, why are they not a sufficient solution?
And even if they elevated these to first class items, nothing is stopping maintainers from still closing them or letting them be closed without the issue having been actually fixed.
Because a label does not contain a reference to the issue that was duplicated. You still have to scroll through the issue's timeline to find it.
Neither do the statuses as suggested.
Your suggestion is to add a field that will only be used in a single status, which goes against the simplicity of GH Issues (which this update already makes contentious enough, looking at the comments here).
Also, realistically, there will be a mention of the issue in the final ticket, so is scrolling down to the bottom of the issue that hard? You're making it seem like it'd be buried in the middle of the timeline and while that can happen, I don't see that being anything but an edge case. Most tickets won't be referenced after they're closed as dupes.
This tension is why issue systems become too complex. The ask is reasonable, but implementing it makes the issue system more complex until all the simple asks make the system collapse under the weight of it...
Absolutely. The sum total of reasonable requests can be an unreasonable system. It’s a paradox just like Gabriel’s horn: finite volume, infinite surface area.
Reading through this comment section makes me see exactly how something simple like a GitHub issue becomes a JIRA issue.
This is why I like simple, opinionated solutions. This kind of discussion becomes superfluous.
Stalebot is a scourge on society. Half joking. Mostly not though.
I'm shocked they haven't added this. Especially with so many projects using bots to close issues just because of inactivty (annoyingly when the inactivity is on the side of the develops, not the person raising the issue).
I'd also say the fixed issues should immediately tell you what PR fixed the issue if possible. It frustrates me to no end when someone says the issue is fixed and they are 5 to 6 referenced PRs in the issue and it's unclear which actually fixes the issue or just mentions the issue in a comment for some reason.
A recurring pattern I see is someone will add an issue comment like "This is great but we need to fix 1. this, and 2. that", and it's just a mess keeping track of discussion threads related to 1 and 2, who is assigned to fix them, and if they're done.
A hack is to add a [ ] checkbox in front of each task (by editing the comment yourself if needed), but then it's not clear if the person that thinks they've completed the task ticks it, or if the original commenter ticks it after they've reviewed the work, and the comment will eventually get folded/hidden.
Another hack is to add a review comment to a pull request anywhere in the code, which at least gives you threaded conversions and a resolved status, but you can't mark who it's assigned to.
Any more hacks here?
Maybe sub-issues will solve this, but if it's similar to creating new issues, that's quite heavy for small items.
Biggest issue with GitHub issues is that large open source projects can't easily signal to viewers which issues are a priority and which are dead or spam. Anytime I see a project with a bazillion issues (like Element), I worry about it's health when maybe I shouldn't because the project is actually fine and the maintainers just use some other ticketing system outside of GitHub.
Aggressive moderation to keep the # open is possible, but not ideal because it causes anxiety for issue-creators and prevents maintainers from finding out about bugs and feature reqs. Some first-class way to differentiate between backlog and todo on the repo would be my #1 request.
> Some first-class way to differentiate between backlog and todo
That sounds like projects and statuses/milestones. Then the issue list becomes the backlog.
Those work from a functional perspective, but don't solve the sticker shock of seeing "issues (852)".
Whats the point of issue types when we already had labels?
I'm unclear myself. For a start, unlike labels, an issue can only have exclusively one type.
From the docs this appears to be how they envision people using this:
Default issue types are included in every organization, but these can edited, disabled, or deleted. The default types are task, bug, and feature.
On the one hand there's already precedence for this, since PRs are sorta just issues that live in a different tab. If issue types actually let people create new top-level tabs in the UI, that might be interesting. Also it looks like there's a maximum of 10 user-defined types per repo, so it wouldn't even threaten to mess up the UI that much if they did so.
We use labels as module tags; e.g. this PR/issue applies to the "filter" module. Having types be its own thing helps separate the two logical categories and enforce "one type per ticket" at the same time.
Issue Types are cross repo (defined at the org level).
I believe they wanted to rework labels and milestones (repository specific) and ended up with Issue Types and Sub-Issues.
Our org/team was very heavy users of the never-broadly-released tasklists revamp from a while back, and I was a huge fan of them.
I really liked the organic approach to project management - soft-epics and soft-subtasks, without Github Issues just turning into Jira. It felt like really neat product design (even though it often did have a bunch of sync bugs them them trying to do too much in markdown)
So I was disapointed to see they weren't happy with that and rolled it into an explicit subtasks instead. I haven't used it seriously yet for a project yet though. We'll see how it goes.
Was expecting a link to an outage report . . . pleasantly surprised as I'm currently on-boarding my team to Jira and it's important that every innovation in this space is over-engineered :)
This would cause more distraction than good on most teams I've been on. I have watched coworkers make it their entire career to play around with the GH project management & issue stuff. The more features, the more distracted these people become. I have even caught myself getting distracted from time-to-time.
If we can't effectively communicate work priorities between titles, comments & labels, maybe we need to go back to email for a while.
sub-issues sound nice for grouping issues. But I think there could be an even better solution: Make it possible to declare issues to depend on other issues and milestones. That way you can filter issues out that can not be worked on because some more fundamental infrastructure has to be put in place first.
A PR can be linked to an issue. It should be possible to link issues to other issues and milestones.
> Make it possible to declare issues to depend on other issues and milestones.
But this is where the JIRA-fication happens, with the many issue link types coexisting alongside no one knowing which is the right one.
> It should be possible to link issues to other issues and milestones.
We already do this by mentioning the #, actually. Well, more to do with PRs mentioned by their backports, but the idea stands.
if GitHub really wants to fix issues, fix the god damn pagination. the current system is basically:
this is not better, at all. to get all comments, you have to constantly click "more" until all are loaded, IN A SINGLE page. then if you accidentally refresh or navigate away from the page, boom you have to redo the entire process.they have at least extended the number of items being loaded when you click more from 50 to 150 in the preview
I know the ziglang project has been doing « sub issues » ad hoc by writing issue lists in a main meta issue. These enhancements will be welcome.
Azure DevOps feels like nobody's maintaining it. I wonder how long until they announce GitHub is going to be the end-goal for ADO.
FYI: Contrary to Tasklists (which were in beta but will be phased out) this does not support adding Pull Requests as sub-"issues".
Any progress on improving slow performance?
Yeah that’s the key question. To actually be competitive with Linear, etc. we need client side rendering and local caching. A basic create-react-app + React Query stack feels much better than GitHub due to the constant SSR for all routing.
What about merging duplicates?
Out of curiosity, what would you expect any such UI to look like in that case? Merging the comments? Even right now one can comment "closing as it is a dupe of #666" and GH will cheerfully create bidirectional links, the link in the comment and the other issue will get a "mention" comment
I would expect it to create a tree of comments using the UI from discussions. The linear nature of comments on issues and PRs is cumbersome.
Evidently both you and https://news.ycombinator.com/item?id=41709123 can continue to hold your breath on threaded comments
These are some nice updates.
However, it made me think of how much time and money is spent just on organizing things, even when organizing something doesn’t make things go better.
In fact, the best teams I’ve worked on have a bias against organizing and a “just do it now” mentality. It depends on the specific case of course. But as a culture, software engineers have a bias towards organizing too much as opposed to not enough.
This is why a board with sticky notes "TODO - In Progress - Done", is still the way to go for most projects. Easy to manage and you don't need to "groom the backlog" or any of that nonsense. If it's important, it goes on the board. When a bunch of things get done, the notes just go in the trash and you move on to the next thing. If there's too many notes, toss some in the trash and forget about it (if it ends up being important, it's really easy to just write a new note).
The only downside to that is if you have remote team members they can't do anything to the board.
Yup, or even simpler- just a checklist in a file.
Amen to that. Over-organization is often a sign of high turnover in teams.
If you can retain engineers long-term, then the amount of repetitive paperwork/reports/status updates, etc reduce significantly.
You can have low frequency, low effort yet high bandwidth communications along with rapid execution.
The amount of productivity lost to make it quicker for some PM to add a bar graph to a PowerPoint emailed to an exec, that the exec will look at for five seconds and move on if they even bother to open the email, is astounding.
hoping to one day read "Evolving GitHub Projects". Issues are good, but it's really hard to work on them while projects are half baked
I wish I could turn off Issues without archiving a repo
Maybe I am misunderstanding you somehow, but you can turn off Issues without archiving a repository, I have several like that. If I attempt to navigate to `/issues`, it redirects me to `/pulls`. And the Issues tab is not visible whatsoever.
Have you tried `/settings` -> Features -> [ ] Issues ?
I wasn’t aware of that, thanks! Is it there for some time already or is that a new feature? I thought it’s not possible on a purpose
You can?! Just head to https://github.com/:org/:repo/settings and scroll down to the "Features" part. You should be able to uncheck it there.
History disappears, which is a bit annoying if ppl have invested energies there. I'd personally prefer it possible to lock them without archiving nor making them disappear from the internet :)
Is it an intended that a history disappears, though? I would assume most people wouldn’t expect it to happen when they disable new issues (for instance - temporarily because of taking a break from a project)
Thanks! Today I learned
C-f thread
0/0
We shouldn't hope for the impossible.
Aren't issues already threads?
> Earlier this year, we introduced the private beta of increased project item limits, expanding the capacity from 1,200 to 50,000 items in a project.
This reminds me why smaller companies can steal market share from larger companies. I can understand that at GitHub scale, it's probably difficult to support more that 1,200 items per project. The result? The entire ecosystem has these limits imposed on them. A smaller company could easily support 50,000 issues for a repository since they are hosting fewer repositories.
Those smaller companies are usually just burning money in an attempt to gain traction. Free services usually have all harsh limitations when the company has to earn their own food. The main reason for this is usually the abuse of those services, not so much that they can't afford it.
You misunderstand: the keyword in that quote is “project.”
GitHub projects are boards, not repositories. I don’t know if there’s a limit on the number of issues repositories can have (nomad is over 5k).
I’m not actually sure how valuable a board with over 1k items on it is in practice.
I thought this was where OP was going with this comment. My inner LLM predicted the next sentence after “This reminds me why smaller companies can steal market share from larger companies.” to be: Larger companies get bogged down with heavy backlogs where it’s hard to tell what’s actually important to work on anymore. Small companies can stay nimble and focused more easily.
50K tasks in a single project is a joke. People should be forced to konmari it. Put a capacity diagram in their face so they have to constantly confront the reality of their lack of organization.
In GitHub, if you want to put an issue from a repository on a Project board it creates a project item to reference it, thus using an issue. If you have a large project (which I have where we hit the capacity of project items) then you are forced to start deleting issues from the project. Which in my opinion isn't great, because that limit includes project issues that have been marked "done". Then you lose the history of maybe why things were done a certain way.