Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evolving GitHub Issues

github.blog

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Evolving GitHub Issues

#81

Post by ProxCoques »

lars_francke wrote: post #22
jeremy_k wrote: post #12

Earlier quoted context omitted.

I agree. The issue with Issues and Discussions is no one knows where to put content. Most falls into Issues because Discussions aren't always enabled and Issues were the original dumping ground. 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 on…

I'm sure you know but just to make sure. You can use Issue Templates to steer people towards Discussions. It's not perfect but it can help a bit at least. https://docs.github.com/en/communities/using-templates-to-en...

Yes, we've got that and it does help a bit. But we're often forced to be heavy-handed and just close junk issues with a comment asking the poster to open a Discussions thread. I feel bad about doing that though as it's hard not to come across as unfriendly.

Re: Evolving GitHub Issues

#82

Post by poorman »

mckn1ght wrote: post #49
schmichael wrote: post #13

Earlier quoted context omitted.

You misunderstand: the keyword in that quote is “project.” 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.

I thought this was where OP was going with this comment. My inner LLM predicted the next sentence after “This reminds me why smaller companies can steal market share from larger companies.” to be: Larger companies get bogged down with heavy backlogs where it’s hard to tell what’s actually important to work on anymore. Small companies can stay nimble and focused more easily. 50K tasks in a single project is a joke. Pe…

In GitHub, if you want to put an issue from a repository on a Project board it creates a project item to reference it, thus using an issue. If you have a large project (which I have where we hit the capacity of project items) then you are forced to start deleting issues from the project. Which in my opinion isn't great, because that limit includes project issues that have been marked "done". Then you lose the history of maybe why things were done a certain way.

Re: Evolving GitHub Issues

#83

Post by TheBruceHimself »

mikeocool wrote: post #32

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.

I'm shocked they haven't added this. Especially with so many projects using bots to close issues just because of inactivty (annoyingly when the inactivity is on the side of the develops, not the person raising the issue).

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.

Re: Evolving GitHub Issues

#84

Post by mdaniel »

mckn1ght wrote: post #72
mdaniel wrote: post #57

Earlier quoted context omitted.

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.

Evidently both you and https://news.ycombinator.com/item?id=41709123 can continue to hold your breath on threaded comments

Re: Evolving GitHub Issues

#85

Post by simonmic »

jeremy_k wrote: post #12
ProxCoques wrote: post #7

If Issues could be restricted to repo maintainers (with everyone else using Discussions), it would make contributing to F/LOSS projects far easier because you could easily see what the team was "thinking" (PR lists aren't like that). 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,…

I agree. The issue with Issues and Discussions is no one knows where to put content. Most falls into Issues because Discussions aren't always enabled and Issues were the original dumping ground. 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 on…

I do some things to try to separate and subtly prioritise bug reports and discourage excessively cluttering the tracker with ideas (some are useful to discuss there, but not all).

- 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)..

Re: Evolving GitHub Issues

#86

Post by Fuzzwah »

holman wrote: post #62

I built the last major update to GitHub Issues over a decade ago now, and I was... kind of hoping for more. Feels more like it's checkbox-driven development instead of sitting down and really planning long-term about what improvements could be made. Also it has React.

Zach your conference presentations back when you were at github were amazing to me, and were such a huge reason I applied for a job at github. I've been there for 7 years now and I just wanted to thank you for being you.

Re: Evolving GitHub Issues

#87

Post by skeptrune »

mckn1ght wrote: post #79
skeptrune wrote: post #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 # 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.

Those work from a functional perspective, but don't solve the sticker shock of seeing "issues (852)".

Re: Evolving GitHub Issues

#88

Post by holman »

Fuzzwah wrote: post #86
holman wrote: post #62

I built the last major update to GitHub Issues over a decade ago now, and I was... kind of hoping for more. Feels more like it's checkbox-driven development instead of sitting down and really planning long-term about what improvements could be made. Also it has React.

Zach your conference presentations back when you were at github were amazing to me, and were such a huge reason I applied for a job at github. I've been there for 7 years now and I just wanted to thank you for being you.

Made me super happy to read that!

Re: Evolving GitHub Issues

#89

Post by ProxCoques »

skeptrune wrote: post #87
mckn1ght wrote: post #79

Earlier quoted context omitted.

> Some first-class way to differentiate between backlog and todo That sounds like projects and statuses/milestones. Then the issue list becomes the backlog.

Those work from a functional perspective, but don't solve the sticker shock of seeing "issues (852)".

Element is a great example with well over 3,000 open issues, most of which would be far better worked out in Discussions from which the maintainers could raise issues or PRs from whatever the outcome of the conversation was (if any). But they don't have Discussions because...

Re: Evolving GitHub Issues

#90

Post by franga2000 »

skeptrune wrote: post #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 # ope…

I guess a big part of the problem is the name "issues". A lot of large projects have dozens or even close to a hundred feature requests and other non-issue "issues" that they keep around until they are implemented and use to discuss the details of the new feature. Seeing a big number next to the issues tab looks scary, even if most of those are non-issue tickets.

Discussions looked like a good solution for that, but the adoption seems slow...

Post reply on HN