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!
New GitHub Issues Beta
141–150 of 223 posts
Re: New GitHub Issues Beta
#142Earlier 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 basically the CPanel of ticket systems.
Re: New GitHub Issues Beta
#143It 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.
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
#144Earlier 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.
Re: New GitHub Issues Beta
#145Earlier 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.
Re: New GitHub Issues Beta
#146Re: New GitHub Issues Beta
#147if 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?
Re: New GitHub Issues Beta
#148Re: New GitHub Issues Beta
#149It 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.
Re: New GitHub Issues Beta
#150I'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...