6 ms·

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 (

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.

cyral 5y ago
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.
- tomjakubowski 5y ago
  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!
  - mchusma 5y ago
    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.
- SahAssar 5y ago
  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.
  - fbcpck 5y ago
    We encountered the same issue, but it seems to be only for projects at user/organization level. What we do to work around this is to create a new repository used solely for projects. By doing so, you can create and put the issues in the project board, and apply labels to the issue (which does show up in the project board). The long details can be put in the issue description, and it can be linked to other repositories nicely as well. The trick really seems to be to not use user/organization project, but (dedicated) repository project. I wish they documented this better or improve it somehow, but hey! I guess they were working on the beta issues board/table which is also pretty sweet!
AdamN 5y ago
Where did you end up?
- telaandrews 5y ago
  We ended up using Linear and are very happy with it. Their approach is also low-level enough to be useful. Best Github integration I've seen, too.
  - chrisvalleybay 5y ago
    I use Linear too and it's great. Awesome keyboard shortcuts, easy to use UX, super minimal and quite fast.
nathanaldensr 5y ago
It feels like this is intentional on GitHub's part. To their credit, they do call it "Project planning for developers." That said, I agree that they are missing a huge opportunity to move Issues outside of the current 1:1 with a repository.
jmcphers 5y ago
Very much agree, most projects I work on these days have components in multiple repositories and trying to coordinate work among them is challenging. We use Github Issues as a source of truth but have resorted to using third-party software on top of them to help get a bigger-picture view. Currently we're using Codetree: https://codetree.com/ https://codetree.com/
dragosmocrii 5y ago
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.
- nathanaldensr 5y ago
  I think Microsoft does this with their .NET ecosystem of repositories, issues, and projects.
- telaandrews 5y ago
  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?
  - adrianpike 5y ago
    Neither, you should have a third conceptual tool to encapsulate the overall product, then once you have a feature spec, you cut tickets for the subcomponents. Depending on the API complexity, I personally would either define the spec as a PR to our API doc repo, or define it as part of the backend task.
    - nemothekid 5y ago
      If I have a third tool, I might as well use that tool for all my issues anyways then? Especially when a tool like Linear can integrate with GH anyways.
      - zomgwat 5y ago
        I've actually been experimenting with something similar to what adrianpike describes. Basecamp is home to all higher level product/business stuff. In part, that's because everyone in the business has access to Basecamp and uses it on a daily basis. Concrete development work gets put into GitHub Issues. Most people on the business side don't have access to GitHub and wouldn't be comfortable with it. Smaller stuff may not get a GitHub Issue. It may just live in Basecamp. Technical stuff that the business will never care to see may only live in GitHub. It's a new process I'm experimenting with. We'll see if it ends up being too disjointed.
martinwoodward 5y ago
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.
- buro9 5y ago
  What I need: 1. Issues that can be linked to other issues (regardless of repo), i.e. local issue blocked by remote issue 2. Projects that can contain issues from multiple repos, even a mix of public and private repos Please say this is now possible, otherwise we too are looking at Linear, Jira, etc when we'd like to be looking at Github.
  - martinwoodward 5y ago
    It is indeed now possible. Give it a try and let us know what you think.
    - mook 5y ago
      Can projects now contain issues from multiple _orgs_? I've had worked on things that spanned orgs before, and as far as I know projects couldn't handle that. I'm really glad subtasks is now a thing!
  - munk-a 5y ago
    For #1 hasn't this been possible for a long time via including the issue linking text: OrgName/project#12345 in either an issue body or comment text - or else including it in a commit message? Due to #1 our org created a no-code repository for hosting all of our issues and it's worked out pretty well - PRs reference the ticket using the issue linking text above and it all works pretty seamlessly - the only slight hiccup is that we only write issues in the no-code repository since splitting issues across repo would cause milestoning issues for releases.
- dbingham 5y ago
eisa01 5y ago
We seem to be using Taiga for this reason, but as a non-technical user doing some coding in our repos from time to time, I'd love to use Github. The UX is better, and having everything in one place feels best
bob1029 5y ago
We addressed this by moving to a monorepository for the organization. Obviously, this doesn't work for everyone, but in my experience it is really amazing when you can pull it off.
adambatkin 5y ago
This X 1000. Even as a developer, I don't always know which repo to file something against. And most "issues" span multiple repositories. Sure, I need to add feature X to repository A and feature Y to repository B (in order to implement some bigger project) but that's not how we plan or assign work. More importantly, at our daily standup, we need a single view across all of our tasks/work, not the work within a single repository.
DaiPlusPlus 5y ago
GitHub issues should not be used by non-technical contributors though (imo)
- seph-reed 5y ago
  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.
- johnchristopher 5y ago
  I agree. But many projects redirect users to Github for issues and SO for documentation :/.
- petepete 5y ago
  I love having our less-technical team members on GitHub. We post loads of screengrabs in issues and PRs, discuss changes and wording and it keeps everyone in the loop. I really wouldn't want to go back to using a separate to like Jira or Trello.
- munk-a 5y ago
  Non-technical users are often burdened with the responsibility of project planning and timelining - in this case seeing how many tickets are closed and where your team falls relative to expectation can be invaluable.
- sudcha 5y ago
  I disagree. Everyone should use Github. It's free, and paid versions are less than half the price of any other paid app there is.
nixpulvis 5y ago
Just make a repository named "jira" or "support tickets" and move forward, no?
User23 5y ago
Product team shouldn’t understand the product sounds like a recipe for failure to me. The product team actually should have a good idea of which component does what and be able to identify where the defects and opportunities lie. If they don’t then that’s a communications failure.
WhyNotHugo 5y ago
This is the biggest complaint I've heard from company, and the reason why most reject using GitLab or GitHub for issues. It works great for FLOSS, but not so good when the people opening issues don't access repositories.

cyral 5y ago

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.

tomjakubowski 5y ago
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!
- mchusma 5y ago
  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.
SahAssar 5y ago
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.
- fbcpck 5y ago
  We encountered the same issue, but it seems to be only for projects at user/organization level. What we do to work around this is to create a new repository used solely for projects. By doing so, you can create and put the issues in the project board, and apply labels to the issue (which does show up in the project board). The long details can be put in the issue description, and it can be linked to other repositories nicely as well. The trick really seems to be to not use user/organization project, but (dedicated) repository project. I wish they documented this better or improve it somehow, but hey! I guess they were working on the beta issues board/table which is also pretty sweet!

AdamN 5y ago

Where did you end up?

telaandrews 5y ago
We ended up using Linear and are very happy with it. Their approach is also low-level enough to be useful. Best Github integration I've seen, too.
- chrisvalleybay 5y ago
  I use Linear too and it's great. Awesome keyboard shortcuts, easy to use UX, super minimal and quite fast.

nathanaldensr 5y ago

It feels like this is intentional on GitHub's part. To their credit, they do call it "Project planning for developers." That said, I agree that they are missing a huge opportunity to move Issues outside of the current 1:1 with a repository.

jmcphers 5y ago

Very much agree, most projects I work on these days have components in multiple repositories and trying to coordinate work among them is challenging. We use Github Issues as a source of truth but have resorted to using third-party software on top of them to help get a bigger-picture view. Currently we're using Codetree: https://codetree.com/ https://codetree.com/

dragosmocrii 5y ago

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.

nathanaldensr 5y ago
I think Microsoft does this with their .NET ecosystem of repositories, issues, and projects.
telaandrews 5y ago
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?
- adrianpike 5y ago
  Neither, you should have a third conceptual tool to encapsulate the overall product, then once you have a feature spec, you cut tickets for the subcomponents. Depending on the API complexity, I personally would either define the spec as a PR to our API doc repo, or define it as part of the backend task.
  - nemothekid 5y ago
    If I have a third tool, I might as well use that tool for all my issues anyways then? Especially when a tool like Linear can integrate with GH anyways.
    - zomgwat 5y ago
      I've actually been experimenting with something similar to what adrianpike describes. Basecamp is home to all higher level product/business stuff. In part, that's because everyone in the business has access to Basecamp and uses it on a daily basis. Concrete development work gets put into GitHub Issues. Most people on the business side don't have access to GitHub and wouldn't be comfortable with it. Smaller stuff may not get a GitHub Issue. It may just live in Basecamp. Technical stuff that the business will never care to see may only live in GitHub. It's a new process I'm experimenting with. We'll see if it ends up being too disjointed.

martinwoodward 5y ago

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.

buro9 5y ago
What I need: 1. Issues that can be linked to other issues (regardless of repo), i.e. local issue blocked by remote issue 2. Projects that can contain issues from multiple repos, even a mix of public and private repos Please say this is now possible, otherwise we too are looking at Linear, Jira, etc when we'd like to be looking at Github.
- martinwoodward 5y ago
  It is indeed now possible. Give it a try and let us know what you think.
  - mook 5y ago
    Can projects now contain issues from multiple _orgs_? I've had worked on things that spanned orgs before, and as far as I know projects couldn't handle that. I'm really glad subtasks is now a thing!
- munk-a 5y ago
  For #1 hasn't this been possible for a long time via including the issue linking text: OrgName/project#12345 in either an issue body or comment text - or else including it in a commit message? Due to #1 our org created a no-code repository for hosting all of our issues and it's worked out pretty well - PRs reference the ticket using the issue linking text above and it all works pretty seamlessly - the only slight hiccup is that we only write issues in the no-code repository since splitting issues across repo would cause milestoning issues for releases.
dbingham 5y ago

eisa01 5y ago

We seem to be using Taiga for this reason, but as a non-technical user doing some coding in our repos from time to time, I'd love to use Github. The UX is better, and having everything in one place feels best

bob1029 5y ago

We addressed this by moving to a monorepository for the organization. Obviously, this doesn't work for everyone, but in my experience it is really amazing when you can pull it off.

adambatkin 5y ago

This X 1000. Even as a developer, I don't always know which repo to file something against. And most "issues" span multiple repositories. Sure, I need to add feature X to repository A and feature Y to repository B (in order to implement some bigger project) but that's not how we plan or assign work. More importantly, at our daily standup, we need a single view across all of our tasks/work, not the work within a single repository.

DaiPlusPlus 5y ago

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

seph-reed 5y ago
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.
johnchristopher 5y ago
I agree. But many projects redirect users to Github for issues and SO for documentation :/.
petepete 5y ago
I love having our less-technical team members on GitHub. We post loads of screengrabs in issues and PRs, discuss changes and wording and it keeps everyone in the loop. I really wouldn't want to go back to using a separate to like Jira or Trello.
munk-a 5y ago
Non-technical users are often burdened with the responsibility of project planning and timelining - in this case seeing how many tickets are closed and where your team falls relative to expectation can be invaluable.
sudcha 5y ago
I disagree. Everyone should use Github. It's free, and paid versions are less than half the price of any other paid app there is.

nixpulvis 5y ago

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

User23 5y ago

Product team shouldn’t understand the product sounds like a recipe for failure to me. The product team actually should have a good idea of which component does what and be able to identify where the defects and opportunities lie. If they don’t then that’s a communications failure.

WhyNotHugo 5y ago

This is the biggest complaint I've heard from company, and the reason why most reject using GitLab or GitHub for issues. It works great for FLOSS, but not so good when the people opening issues don't access repositories.