Live data from Hacker News

Evolving GitHub Issues

github.blog

71–80 of 92 posts

Re: Evolving GitHub Issues

#71
post #29
post #17

Earlier quoted context omitted.

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)

Re: Evolving GitHub Issues

#72
post #57

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.

Re: Evolving GitHub Issues

#73
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.

Re: Evolving GitHub Issues

#74
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.

Re: Evolving GitHub Issues

#77

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.

They kind of have them already in GitHub Projects.

Re: Evolving GitHub Issues

#78
post #31

Whats the point of issue types when we already had labels?

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.

Re: Evolving GitHub Issues

#79

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 # ope…

> Some first-class way to differentiate between backlog and todo

That sounds like projects and statuses/milestones. Then the issue list becomes the backlog.

Post reply on HN