Hacker News Reader

Comment by telaandrews | Hacker News Reader

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.

View on HN

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.

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.

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!

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.

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.

It is indeed now possible. Give it a try and let us know what you think.

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!

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.

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.

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.

I think Microsoft does this with their .NET ecosystem of repositories, issues, and projects.

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?

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.

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.

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.

indeed, that's where we ended-up, by using Linear which provides the layer of abstraction. it's just disappointing because it's a long-standing issue, and relatively easy to solve (based on the fact many 3rd parties have).

Presumably you would want a professional engineer or project manager to triage and curate issues long before they end up on a developer's actual task list, in which case it really wouldn't matter.

You'd group the repos together in an organizational project and open the issue there.

https://docs.github.com/en/issues/organizing-your-work-with-...

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.

This isn't a mono repo, it's a set of associated code. If you have a front end and backend that are tightly coupled they should be in the same repository.

Either one. You'll eventually open an issue on the other repo too and link them.

For me in Gitlab, you would create an epic (if its a large feature) and then put all of the tasks as their own issues in the respective repos.

I think it's honestly pretty far to do this but never end up moving the issues - we have some repo-of-relevance labels we use to indicate ticket applicability but otherwise our issues just continuously pile up in the same repo.

Commenting only on the "support ticketing system".

Just in case it did, it would radically deprecate a bunch of tools and simplify life of small dev teams.

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.

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

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.

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.

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/

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.

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.

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

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.

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

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.

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.

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.

Where did you end up?

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.

I use Linear too and it's great. Awesome keyboard shortcuts, easy to use UX, super minimal and quite fast.

Reply on news.ycombinator.com