GitLab

In the JIRA to Gitlab migration ticket (ops#817 (moved)), 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.

Source: https://lab.civicrm.org/infrastructure/ops/wikis/gitlab-roadmap#splitting-issues-across-projects-might-be-confusing-triage

Proposed structure

(todo) :-)

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.