JIRA to Gitlab migration: project structure
In the JIRA to Gitlab migration ticket (#817 (closed)), one of the issues that seem to raise more than a few questions is how we should structure issues:
- A single project for anything "core"
- Create several projects, for example, by component, or by team.
What do we gain from splitting the projects?
- It helps more clearly identify who are the primary leads for a specific area. We have been talking about having a google-doc with "people to ping for PR-review".
- Example: translation, civicase, grant, taxes, accounting/financial, etc.
- We might not want to be very aggressive about splitting either. Only where it makes sense.
- They may want to have their own wiki space (draft docs, roadmap/planning)
- While we can do part of this with labels, having subprojects makes it possible to have more granular labels. Ex: taxes have different challenges for Canada (HST/GST per province) than for VAT in Europe. Having a single "taxes" label would be limiting.
- It's easier to subscribe to issue notifications for a specific sub-project.
It should probably be along the lines of
dev/membership (not development-team/membership), so that the issue references are short (they should be included in the commit titles, ex:
dev/membership#123: fixes Peace on Earth.
Developers don't need to memorize the keyword structure. Gitlab has a "copy issue reference" icon, in the lower-right side of the issue screen.