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

New GitHub Issues Beta

github.com

Post reply on HN
Print view View original

131–140 of 223 posts

Re: New GitHub Issues Beta

#131

Post by seph-reed »

DaiPlusPlus wrote: post #129
telaandrews wrote: post #26

It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.

GitHub issues should not be used by non-technical contributors though (imo)

I dunno. From a UXR perspective, issue tracking is frigging amazing.

You can learn so much about what the user experience is from just having them tell you what's wrong. It's a real bummer though: most of the people responding are about as far removed from UX researchers as you get: almost no ability to put themselves in the shoes of others.

Re: New GitHub Issues Beta

#132

Post by johnchristopher »

DaiPlusPlus wrote: post #129
telaandrews wrote: post #26

It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.

GitHub issues should not be used by non-technical contributors though (imo)

I agree. But many projects redirect users to Github for issues and SO for documentation :/.

Re: New GitHub Issues Beta

#133

Post by alkonaut »

fancy_pantser wrote: post #121

The UI, down to the content and styling of menus, looks a lot like Linear. I'm chuffed to see the best parts being borrowed, but it looks like they've made sub-tasks/issues too simple, as they aren't first-class issues, but mere checkboxes with short descriptions. https://linear.app

On the other hand the “tasks are as heavyweight as the bugs or backlog items that spawned them” (often with just one task ie 1:1) creates a ton of overhead in e.g Azure Devops. Especially as efforts get spread out while rollup barely works. It’s also unclear whether PRs should be linked to tasks or the parent issue.

I want more than a checkbox but less than an issue. A completion % and owner would be enough.

Re: New GitHub Issues Beta

#134

Post by tomjakubowski »

cyral wrote: post #45
telaandrews wrote: post #26

It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.

You can use projects for this (it is what we do). Create a project for the org where non business people can add issues/todo's to and then developers can click "Create Issue" on them and create a more detailed issue for the appropriate repo.

Yes, that's exactly it. Project boards, spanning multiple repositories, have been on Github for years; seems by the comments in this thread that Github isn't advertising them well enough!

Re: New GitHub Issues Beta

#135

Post by [deleted] »

Groxx wrote: post #30

"it's just a spreadsheet, and [view X] is a filter on that sheet" is a nice mental model. I've had lots of managers organize stuff in google sheets and then copy to [task manager X] simply because it's easier to think about - they'd probably love this. I certainly would, vs Jira's massive "everything is custom UI / a unique concept" mess.

[deleted]

Re: New GitHub Issues Beta

#136

Post by swozey »

sandGorgon wrote: post #87

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all…

Wild, I just went through the pain of automating all my org labels today and it was a huge bummer to not have scoping. I'm doing "Type: $var" etc but I know it'll look terrible compared to scoping.

Going from Gitlab to gh has been interesting.

For anyone unfamiliar, example; https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issu...

Re: New GitHub Issues Beta

#137

Post by greatgib »

Omg, they did a copy of Asana. And not a copy of the good part, but a copy of the useless unergonomic eye candy parts ...

And I hate so much Asana... It is so inefficient and frustrating to use.

So, please, fire the designer that proposed this change before it can become mainstream.

I don't understand the hype about the "board" thing. I guess that people think that they look cool and doing agile by using a board.

But compare that to a normal table that you can reorder by columns based on your wishes...

Re: New GitHub Issues Beta

#138

Post by duped »

telaandrews wrote: post #44
dragosmocrii wrote: post #37

Earlier quoted context omitted.

Maybe Github Issues is not supposed to work as a support ticketing system? You are allowed to move issues between repos, so in theory you could create a dummy repo where users can add issues, and then those issues can be moved to their appropriate repo.

What if I want to define a new feature that has both backend and frontend tasks, and have separate repos for the FE and BE? Which repo do we create the issue in?

Kind of an XY problem to me. The backend and frontend should be in the same repo unless you have an excellent reason for one to be in a separate source repository. The rifts are more numerous than just ticketing on GitHub issues, imo.

Re: New GitHub Issues Beta

#139

Post by dbingham »

martinwoodward wrote: post #48
telaandrews wrote: post #26

It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.

The new project experience allows you to track issues that are in different projects, prioritise them alongside each other etc. I work at GitHub where we've been trying this out for a while and it's working pretty well so far for a bunch of the projects I work on when you need that cross-project visibility and co-ordination.

I think a lot of these problems would be solved by just adding an "Issues" tab alongside the "Projects" tab at the organization level - with all the features that go along with that (Milestones, labels). Then you could have issues at the organizational level, separate from repositories, and that would allow you to better deal with stories spanning multiple repositories. Especially since these updates (which are fantastic by the way) seem to be adding support epics and the like, it wouldn't be unreasonable at all for epics to span multiple repositories (Frontend, backend, infrastructure or multiple microservices in a multi-repo setup). Conceptually, putting those issues on one of those repositories feels wrong. Putting them on the organization is much clearer.

Re: New GitHub Issues Beta

#140

Post by bostonsre »

sandGorgon wrote: post #87

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all…

Why not just tag it with separate labels? For that example, tag it with ui, app, and android. Then search with ui and app labels?
Post reply on HN