by joeig on 10/1/24, 1:32 PM with 86 comments
by mjw1007 on 10/1/24, 3:16 PM
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.)
by vundercind on 10/1/24, 2:16 PM
by ProxCoques on 10/1/24, 2:36 PM
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.
by holman on 10/1/24, 4:58 PM
by 38 on 10/1/24, 2:49 PM
comment
comment
[bunch of hidden comments]
comment
comment
by sluongng on 10/1/24, 2:44 PM
by mikeocool on 10/1/24, 3:20 PM
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.
by kayson on 10/1/24, 3:20 PM
by seanwilson on 10/1/24, 3:23 PM
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.
by skeptrune on 10/1/24, 5:38 PM
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.
by madeofpalk on 10/1/24, 4:16 PM
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.
by 6LLvveMx2koXfwn on 10/1/24, 2:23 PM
by bob1029 on 10/1/24, 5:34 PM
If we can't effectively communicate work priorities between titles, comments & labels, maybe we need to go back to email for a while.
by vaylian on 10/1/24, 3:08 PM
A PR can be linked to an issue. It should be possible to link issues to other issues and milestones.
by jackhalford on 10/1/24, 5:40 PM
by lars_francke on 10/1/24, 2:46 PM
by giancarlostoro on 10/1/24, 5:47 PM
by jerrygoyal on 10/1/24, 4:09 PM
by RicoElectrico on 10/1/24, 2:16 PM
by cynicalpeace on 10/1/24, 2:44 PM
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.
by agos on 10/1/24, 2:57 PM
by yu3zhou4 on 10/1/24, 2:38 PM
by mahkoh on 10/1/24, 2:45 PM
0/0
We shouldn't hope for the impossible.
by poorman on 10/1/24, 2:36 PM
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.