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

21–30 of 92 posts

Re: Evolving GitHub Issues

#21

Post by 38 »

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.

Re: Evolving GitHub Issues

#22

Post by lars_francke »

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

Re: Evolving GitHub Issues

#23

Post by [deleted] »

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

[deleted]

Re: Evolving GitHub Issues

#24

Post by lars_francke »

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

Just to add a different opinion: I have been using Jira my whole life and I am now using GitHub issues full-time and I like it a lot, I also like these new changes and I'm looking forward to even more to dependencies between issues.

https://github.com/github/roadmap/issues/956

I understand that this is your opinion but there are others out there with differing ones :)

Re: Evolving GitHub Issues

#26

Post by slightwinder »

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…

Those smaller companies are usually just burning money in an attempt to gain traction. Free services usually have all harsh limitations when the company has to earn their own food. The main reason for this is usually the abuse of those services, not so much that they can't afford it.

Re: Evolving GitHub Issues

#27

Post by medstrom »

tuespetre wrote: post #9
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”.

i have always admired GitHub's issues system for its simplicity. s/have/had/

If it turns out to be too complex, Codeberg and SourceHut are some actually nice alternatives that exist now. Not like GitLab which brought its own complexity.

Re: Evolving GitHub Issues

#28

Post by vaylian »

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.

Re: Evolving GitHub Issues

#29

Post by patcon »

tom1337 wrote: post #17
yu3zhou4 wrote: post #10

I wish I could turn off Issues without archiving a repo

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

Re: Evolving GitHub Issues

#30

Post by mjw1007 »

I 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 main underlying problem is fixed, because there's some small remaining part that's unsettled.

I'd much prefer it if the topmost part of the page was reserved for a space, maintained by whoever's responsible for dealing with the issue, describing the current understanding of the problem and the current status.

Then the orignal report and further discussion could be laid out under that as at present.

It's possible to get roughly this now, by repeatedly editing the initial message. But the UX isn't ideal, and more importantly it isn't culturally expected.

(Of course this isn't a github-specific problem. But github are in a better position than most to offer a fix.)

Post reply on HN