Skip to content

Reorganize CTA dev labels and issue boards

Labels

Priority

Every accepted issue should be given a priority.

This has already been put in place by using the following labels:

The guidelines for choosing between each priority can be found here:

These labels be tracked and modified using a dedicated board:

Workflow

The workflow scoped labels are used to track the progress of dev issues. They are a very important tool for developers and management to keep track of ongoing work.

However, some of these labels are redundant or unclear. We are also missing some stages of development.

Therefore, I propose the following changes:

  • ~"workflow::Accepted" : Remove
    • This is redundant. Any issue with a priority (low/medium/high/critical) has already been implicitly accepted.
  • workflowAssigned : Remove
    • This is redundant. An issue is assigned if it contains an Assignee in the lateral bar.
  • workflowIn Progress : OK
  • workflowBlocked : Move out of scope EDIT: We will keep it in the scope workflow
    • This label is orthogonal to all other workflow labels.
    • It should be turned into an non-scoped label.
    • Note: Issues already have a Linked items option, where we can define blocking relationships to other issues. Unfortunately, we cannot search by this field.
  • workflowDone : Replace by new labels
    • Done is ambiguous, despite the description " Development work has been completed, awaiting review and testing before the ticket can be closed". It gets confused with the Closed status of an issue.
    • We can replace it by 1 or 2 new labels:
      • ~"workflow::Testing"
      • ~"workflow::In Review"
  • New label for workflowBacklog:
    • For any issues that should be handled in the current development cycle/sprint.
    • Should be reviewed and updated at the start of each cycle.
    • If used correctly, it aims to make the planning and organisation of CTA development much easier.

This means having the following workflow labels (open for discussion):

These labels be tracked and modified using a dedicated board:

This board will only select the issues that have been "accepted" (aka priority assigned). EDIT: I have come to realise that this it's better not to enforce this. In theory, all issues should have a priority but developers may not want to assign one in specific cases.
At the beginning of each development cycle we can assign some of these issues to _workflowBacklog. They may already be assigned or not. Developers should be selecting their next development work from them.

Type

Our issues can be classified in different types. We should have clear and distinct labels for each one of them.

These have been added by @nbugel and cover several important use-cases. I'm putting them here for further discussion:

The last 2 options (*) were object of discussion in the dev channel. They seem to overlap with others, so we should discuss them in more details.

Suggestion: Assign these labels to all open issues. If we are unclear about some of them, that may mean that we need to refine the different values.

Planning / organisation

Some labels are helpful for organising CTA development, but they should stay out of a scope:

  • workflowBlocked -> Blocked
    • Remove out of the scope workflow::. These concepts are orthogonal, meaning any workflow stage can be blocked for various reasons.
  • Needs Discussion

Components

As suggested by @nbugel in #764 (closed), we could add a prefix to labels that are part of the same grouping. This is not the same as a scope, just syntax, but allows us to more easily identify and assign the labels.

For items related to CTA-EOS building blocks, it was suggested that we add the prefix component:. I propose just cta:, so that we keep it short.

CTA components:

EOS components: EDIT: We will not use this. Only external: EOS

Operator tool components:

  • Operator Tools
    • It's only one, but if we want a subset of labels we could use tools: <operator_tool_name>

External projects (issues that impact and/or are impacted by changes on these projects):

To discuss

Project related labels

Some labels are only used for specific projects. We should discuss if we should keep following this approach.

I propose one of the following options:

  1. It's ok to create labels at will for projects.
  2. It's ok to create labels for projects, but they should follow a syntax <project_prefix>: <label_name>.
  3. It's not ok to create labels for projects.

1. Postgres SchedulerDB

Should we use PGSCHED: <label_name> prefix?

  • ~PGSCHED
  • ~Archival
  • Retrieve
  • ~Reporting
  • ~scheduler_db_garbage_collection (Modify the name to remove _)

2. Object Store

It's a separate project, same as PGSCHED.

Unnecessary labels ?

Some labels are probably not necessary, just polluting the namespace. I suggest removing or modifying them:

Syntax rules

I propose that we follow this convention:

  • <scope>::<label>: For scoped labels.
  • <group>: <label>: For non-scoped labels that are part of a category.
  • <label>: For non-scoped labels, out of a category.

With the following upper/lower case rules:

  • <scope> and <group> (before ::/:) should be lowercase.
  • <label> should be Capitalised With Whitespaces.
Edited by Joao Afonso