Whats the point of issue types when we already had labels?
Evolving GitHub Issues
31–40 of 92 posts
Re: Evolving GitHub Issues
#32Please 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.
Re: Evolving GitHub Issues
#33A 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.
Re: Evolving GitHub Issues
#34These 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 no…
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).
Re: Evolving GitHub Issues
#35Noooooo! 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”.
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.
Re: Evolving GitHub Issues
#36I 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…
I often edit the title and description of issues.
I usually let the original content after a
### Original message
...
Re: Evolving GitHub Issues
#37These 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 no…
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 bein…
Yup, or even simpler- just a checklist in a file.
Re: Evolving GitHub Issues
#38I 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…
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.
Re: Evolving GitHub Issues
#39Whats 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.
Re: Evolving GitHub Issues
#40Noooooo! 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”.
As long as they don't add workflows, we're safe.