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-...

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.

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.

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

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.

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.