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

41–50 of 92 posts

Re: Evolving GitHub Issues

#41

Post by ogoffart »

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've observed it has become much better on my repository over the past few years. Discussions took a while to be adopted and I have to guide users to discussions through the CONTRIBUTING.md and issue template. For the few questions that still comes in the issues, i'm immediately converting them into discussions.

Re: Evolving GitHub Issues

#42

Post by smileybarry »

kayson wrote: post #31

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

We use labels as module tags; e.g. this PR/issue applies to the "filter" module. Having types be its own thing helps separate the two logical categories and enforce "one type per ticket" at the same time.

Re: Evolving GitHub Issues

#43

Post by smileybarry »

vaylian wrote: post #28

sub-issues sound nice for grouping issues. But I think there could be an even better solution: Make it possible to declare issues to depend on other issues and milestones. That way you can filter issues out that can not be worked on because some more fundamental infrastructure has to be put in place first. A PR can be linked to an issue. It should be possible to link issues to other issues and milestones.

> Make it possible to declare issues to depend on other issues and milestones.

But this is where the JIRA-fication happens, with the many issue link types coexisting alongside no one knowing which is the right one.

> It should be possible to link issues to other issues and milestones.

We already do this by mentioning the #, actually. Well, more to do with PRs mentioned by their backports, but the idea stands.

Re: Evolving GitHub Issues

#44

Post by okl »

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,…

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

Totally agree. They should have some AI solution categorize the issues and separate actual issues/tickets from support requests and other noise.

Re: Evolving GitHub Issues

#45

Post by voidfunc »

vundercind wrote: post #2

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

This was inevitable. Microsoft probably doesn't want to support both Azure DevOps and GitHub long term. GitHub needs to gain the most important features of ADO that ADO customers care about.

Re: Evolving GitHub Issues

#46

Post by hkdobrev »

38 wrote: post #21

if GitHub really wants to fix issues, fix the god damn pagination. the current system is basically: comment comment [bunch of hidden comments] comment comment this is not better, at all. to get all comments, you have to constantly click "more" until all are loaded, IN A SINGLE page. then if you accidentally refresh or navigate away from the page, boom you have to redo the entire process.

they have at least extended the number of items being loaded when you click more from 50 to 150 in the preview

Re: Evolving GitHub Issues

#47

Post by mckn1ght »

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.

Labels have been able to do this for years, why are they not a sufficient solution?

And even if they elevated these to first class items, nothing is stopping maintainers from still closing them or letting them be closed without the issue having been actually fixed.

Re: Evolving GitHub Issues

#48

Post by atomicnature »

cynicalpeace wrote: post #15

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…

Amen to that. Over-organization is often a sign of high turnover in teams.

If you can retain engineers long-term, then the amount of repetitive paperwork/reports/status updates, etc reduce significantly.

You can have low frequency, low effort yet high bandwidth communications along with rapid execution.

Re: Evolving GitHub Issues

#49

Post by mckn1ght »

schmichael wrote: post #13
poorman wrote: post #8

> Earlier this year, we introduced the private beta of increased project item limits, expanding the capacity from 1,200 to 50,000 items in a project. 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…

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. People should be forced to konmari it. Put a capacity diagram in their face so they have to constantly confront the reality of their lack of organization.

Re: Evolving GitHub Issues

#50

Post by vundercind »

cynicalpeace wrote: post #15

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…

The amount of productivity lost to make it quicker for some PM to add a bar graph to a PowerPoint emailed to an exec, that the exec will look at for five seconds and move on if they even bother to open the email, is astounding.
Post reply on HN