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

GitHub introduces sub-issues, issue types and advanced search

github.blog

Post reply on HN
Print view View original

61–70 of 213 posts

Re: GitHub introduces sub-issues, issue types and advanced search

#61

Post by bsmth »

shpx wrote: post #55

Instead of these features I want them to stop spam issues on my repos. All the issues I've gotten in the last year on my project are completely nonsensical. It's not even spam it's just like random URLs or complete nonsense from freshly created accounts that aren't trying to sell anything or just the issue template. And every time it costs me 2 clicks to click on "report" then I have to type "spam", click the spam ca…

It might be worth trying the moderation tools that prevent interactions from accounts less than 24 hours old. Docs here https://docs.github.com/en/communities/moderating-comments-a...

I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.

Re: GitHub introduces sub-issues, issue types and advanced search

#62

Post by rplnt »

IshKebab wrote: post #18
Calzifer wrote: post #9

Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.

> well administrated Jira Based on my experience that doesn't exist. Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah. A colleague joked that we need a "waiting for Jira" Jira task.

I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.

Re: GitHub introduces sub-issues, issue types and advanced search

#64

Post by matt_kantor »

mg74 wrote: post #53
joshSzep wrote: post #50

this happens after I've moved everything to height. downside is it was a lot of work. upside is height is amazing and I'm pleased with the choice. anyone else using it?

what is height?

Maybe this? https://height.app/

Re: GitHub introduces sub-issues, issue types and advanced search

#65

Post by hadrien01 »

IshKebab wrote: post #18
Calzifer wrote: post #9

Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.

> well administrated Jira Based on my experience that doesn't exist. Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah. A colleague joked that we need a "waiting for Jira" Jira task.

A well administered JIRA can be really fast. There's a reason Atlassian themselves don't use JIRA Cloud: https://jira.atlassian.com/browse

Re: GitHub introduces sub-issues, issue types and advanced search

#66

Post by hnlmorg »

hamandcheese wrote: post #48

A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.

Completely agree with this suggestion.

Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.

Re: GitHub introduces sub-issues, issue types and advanced search

#68

Post by dotancohen »

IshKebab wrote: post #18
Calzifer wrote: post #9

Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.

> well administrated Jira Based on my experience that doesn't exist. Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah. A colleague joked that we need a "waiting for Jira" Jira task.

Take a look at Redmine. It's a self-hosted Ruby project manager and I love it, especially for issue dependencies.

Re: GitHub introduces sub-issues, issue types and advanced search

#69

Post by yallpendantools »

shamiln wrote: post #28
tw12312831 wrote: post #6

GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?

What type of registry? GitHub packages?

I would hazard a guess, more in the vein of the much-maligned "Windows Registry".

https://en.wikipedia.org/wiki/Windows_Registry

Re: GitHub introduces sub-issues, issue types and advanced search

#70

Post by sethops1 »

hnlmorg wrote: post #66
hamandcheese wrote: post #48

A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.

Completely agree with this suggestion. Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.

Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
Post reply on HN