Live data from Hacker News

New GitHub Issues Beta

github.com

141–150 of 223 posts

Re: New GitHub Issues Beta

#141
post #45

Earlier quoted context omitted.

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!

Wow, we haven't used Github for years because it was missing this feature. I saw the new beta and looked if they supported cross-repo issues, and was disappointed. Turns out, they do? They just make it very hard to discover? Odd. Seems like low hanging fruit to fix.

Re: New GitHub Issues Beta

#142

Earlier quoted context omitted.

For day-to-day, Jira is completely fine. I get frustrated with it when I need to dive into basic admin tasks - like spinning up a new project or board. Their admin and setting panels are completely incomprehensible. Also, Jira doesn't have a story for archiving tickets. Only a straight, permanent, hard delete with no recovery. I got reminded of this the hard way. ----- We're currently switching to Clubhouse (though a…

It's way too heavy, even for the day-to-day. A tool of that sort, for which I have to close tabs when not actively in use to save resources, even on powerful machines, or where clicking a link to a ticket might take more than very-low-hundreds of milliseconds to load, is bad. GH issues? I click a link without thinking twice, and it's open fast. Almost every interaction is quick. I can leave a dozen tabs with GH issue…

> It's way too heavy

It's basically the CPanel of ticket systems.

Re: New GitHub Issues Beta

#143
post #45

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.

Those are text-only and don't support comments, labels, statuses, markdown or basically any of the other things that might make issues useable.

There are issues that apply to a whole org. There are "non business people" that know how to add context to an issue but not exactly in which repo it might fit best.

"Notes on a board" is not a replacement for org-level issues.

Re: New GitHub Issues Beta

#144
post #138

Earlier quoted context omitted.

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.

The monorepo question is not a question with a one-fits-all answer.

Re: New GitHub Issues Beta

#145
post #95

Earlier quoted context omitted.

This is super common, and it's one reason why I have always volunteered (even though it sucks) to be the Jira Person. I'm experienced with it and have a good handle on how not to make it a big giant workflow mess, and I can then make sure that, by not being shy about who's running it and managing it, that feedback goes somewhere actionable.

JIRA workflow is managed by another department. Our IT department is like 50k+ employees. I think there are 100k in IT and Ops.

Abandon all hope, ye who enter here.

Re: New GitHub Issues Beta

#147

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?

For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.

Re: New GitHub Issues Beta

#148
Wow, there's a lot of Airtable in here. My team used GitHub Issues/Projects for a while, but ultimately moved to a custom Airtable solution for project management, release management, etc which gave us the tables, views, filters, groups, you name it. Seems like someone at GitHub got the notice about users wanting that more flexible UI/UX. Good on them!

Re: New GitHub Issues Beta

#149

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.

Just make a repository named "jira" or "support tickets" and move forward, no?

Re: New GitHub Issues Beta

#150
post #5

I'm more interested in GitHub's Issue Forms (as an evolution of Issue Templates): https://twitter.com/frenck/status/1355620350176976901 Does anyone know what the status of these is?

It's announced here as also being in beta for public repos: https://github.blog/changelog/2021-06-23-issues-forms-beta-f...

I cannot comprehend why GitHub chose to let people define the form elements in YAML (!) instead of simply allowing , and in Markdown. One of the most beautiful aspects of Markdown is that it supports HTML. It's trivial to allow only a minimal set of attributes, like `required`.
Post reply on HN