Development Tracking

GitLab issues are used to track the development work that needs to be done. Please respect the following guidelines when creating issues:

• Check if an issue already exists before creating one.
• Use one of the provided issue templates if possible.
• The title should describe the desired change, not the initial problem.
• Ensure all relevant information is present in the issue.
• Be clear and concise.
• Issues should have a clearly defined scope. When the issue starts to derail or require other changes, create a separate issue.
• Typically we have one issue associated per commit. If a single commit is too broad for the issue, then split the issue into multiple more specific issues.

There are two important issue boards that we use to plan which tasks will be worked on:

• Development: provides an overview of the workflow states.
• Priority Management: provides an overview of the priority states.

Assigning Labels

Labels play a crucial role in keeping a hygienic and organised issue environment. Below we discuss the various type of labels that we have. When creating an issue, follow these steps:

• Assign a type:: label.
• Assign a ~"priority::<>" label (if relevant)
• Assign any relevant labels with the prefix cta:
• Assign any relevant labels with the prefix external:
• Optionally assign an assignee if you know who will take care of the issue.
• A ~"workflow::<>" label should only be assigned after discussion with the team. Once assigned, this label can be updated as required.

Type

Issues should be categorized in one of these five types:

• ~"type::bug"
  • Issues that report undesirable or incorrect behaviour.
• ~"type::feature"
  • Issues that contain work to support the implementation of a feature and/or enhancement.
• ~"type::maintenance"
  • Issues that are not a feature or a bug that involve updates, clean-up, and minor corrections to keep the repository healthy and up-to-date.
• ~"type::documentation"
  • Issues that report required changes to the documentation.
• ~"type::ignore"
  • Issues that do not directly affect the changelog, i.e. meta, discussions or planning.
• ~"type::release"
  • Used for new code releases.

Types are used to categorise what kind of change is being doing to the project. Most of the issues will fall under either ~"type::bug", ~"type::feature" or ~"type::maintenance".

Are you unsure of whether an issue counts as a feature or a bug? Have a look at the guidelines that GitLab uses.

Priority

To classify the priority of an issue, there are four different options:

• ~"priority::critical"
• ~"priority::high"
• ~"priority::medium"
• ~"priority::low"

Each of these labels are part of the priority:: scope. Priority labels are assigned based on Urgency and Impact. For concrete definitions of these terms, you can have a look here.

	Urgency	Impact
High 🔺	Can no longer perform primary functions.	System-wide impact.
Medium 🔶	Functions impaired. Work around possible.	Multiple users affected. Experiment affected.
Low 🟡	Inconvenient.	Single user affected. Single event. Operation affected.

Using these two concepts, we assign priorities based on the following urgency-priority matrix:

Urgency \ Impact	High 🔺	Medium 🔶	Low 🟡
High 🔺	critical	high	medium
Medium 🔶	high	medium	low
Low 🟡	medium	low	low

Workflow

To complement our Git workflow, we have the following workflow labels:

• ~"workflow::backlog"
  • Task to be worked on during the next sprint
• ~"workflow::in progress"
  • Task is assigned and is actively being worked on
• ~"workflow::blocked"
  • Issue is unable to progress, awaiting another issue to be resolved or pending action by someone outside the CTA team
• ~"workflow::testing"
  • Development work has been completed, awaiting testing
• ~"workflow::in review"
  • Development work has been completed and testes, awaiting review before the ticket can be closed

Issues should start out without a workflow label. Workflow labels are assigned only after discussion with the dev team.

Components

The CTA consists of many different components. As such, it is useful to know which component is being worked on. To do this, we have two categories of labels: cta: <> and external: <>. Issues can concern multiple components. As such, these labels are not scoped, but prefixed instead.

• The cta: prefix is used for components that concern the components within CTA itself. Concretely that means that any work on components in the CTA repository will have have this prefix.
• The CTA works together with other external components, such as FTS or EOS. When these external systems are relevant to the issue, the external: prefix is used.

Additional labels

Apart from the labels discussed above, there are a few other notable labels:

• Building and Packaging
  • Changes to the build and packaging system
• Code Quality
  • Improvements to the code quality
• Continuous Integration
  • Updates or changes to the continuous integration
• Development Infrastructure
  • Anything related to the development environment
• Needs Discussion
  • Issue needs to be discussed in the next dev meeting
• SonarCloud
  • Changes to or because of SonarCloud.

This list is not exhaustive. Please have a look at the full label list if you want to familiarize yourself with all of them.