3 ms·
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.
by 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 agoIf 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 agoI'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.