Evolving GitHub Issues
github.blog
github.blog
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.)
I usually let the original content after a
### Original message
...
IMO the way to fix this is to gestate all issues in Discussions. Then, when a clear and agreed resolution is hammered out there, a maintainer creates an Issue (or just does a PR) referencing that Discussion. This would have the side effect of encouraging people to contribute to projects more when they can clearly see what needs picking up.
s/have/had/
https://github.com/github/roadmap/issues/956
I understand that this is your opinion but there are others out there with differing ones :)
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.
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.
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.
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.
https://docs.github.com/en/communities/using-templates-to-en...
- 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)..
Totally agree. They should have some AI solution categorize the issues and separate actual issues/tickets from support requests and other noise.
comment
comment
[bunch of hidden comments]
comment
comment
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.
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.
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'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.
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.
I believe they wanted to rework labels and milestones (repository specific) and ended up with Issue Types and Sub-Issues.
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.
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.
That sounds like projects and statuses/milestones. Then the issue list becomes the backlog.
Discussions looked like a good solution for that, but the adoption seems slow...
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.
If we can't effectively communicate work priorities between titles, comments & labels, maybe we need to go back to email for a while.
A PR can be linked to an issue. It should be possible to link issues to 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.
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.
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.
Have you tried `/settings` -> Features -> [ ] Issues ?
0/0
We shouldn't hope for the impossible.
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.
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.
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.