4 ms·

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

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.
telaandrews 5y ago
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).
tshaddox 5y ago
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.
tomjakubowski 5y ago
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-project-boards/managing-project-boards/about-project-boards https://docs.github.com/en/issues/organizing-your-work-with-...
duped 5y ago
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.
- SahAssar 5y ago
  The monorepo question is not a question with a one-fits-all answer.
  - duped 5y ago
    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.
edflsafoiewq 5y ago
Either one. You'll eventually open an issue on the other repo too and link them.
SilverRed 5y ago
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.

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.

telaandrews 5y ago

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

tshaddox 5y ago

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.

tomjakubowski 5y ago

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-project-boards/managing-project-boards/about-project-boards https://docs.github.com/en/issues/organizing-your-work-with-...

duped 5y ago

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.

SahAssar 5y ago
The monorepo question is not a question with a one-fits-all answer.
- duped 5y ago
  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.

edflsafoiewq 5y ago

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

SilverRed 5y ago

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.