61–70 of 92 posts
Any progress on improving slow performance?
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”.
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.
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”.
As long as they don't add workflows, we're safe.
Earlier quoted context omitted.
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 b…
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 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…
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.
Earlier quoted context omitted.
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 b…
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...
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 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 ?