Triage category in GitLab workflow: necessary or confusing?

Project Discussion
1

I am not sure if we had that discussion before, but something to think about to maybe make a decision in some of the future meetings:

I added most related topics to the triage category some days ago, but I have seen that the triage category is not really used consistently: in some tickets it is used, in some not. Even when other categories are assigned, the triage seems to be often omitted.

However, it could be argued that omitting makes sense, because it is not necessary to mark something as triage because the information is there anyway: IF a ticket is OPEN (without a progress/support/approval category assigned) AND IF the ticket has a type category assigned (minor change, major change, internal task), then it is obvious that the ticket is in triage. Or alternatively said: the existence of a type category (minor change, major change, internal task) and the absence of a stage category (progress/support/approval category) automatically implies triage.

With this in mind, I just opened this topic to create space to discuss if we shall get rid of the triage as dedicated category.

It is not a big thing and not worth much efforts, but the simple advantages would be to have some more consistency in the dashboard, and maybe avoid something that could confuse other users if they find some labelled topics in open, and other labelled topics in triage.

I would be +1 to make a ticket to stop using the category, but make it low priority so that it can be assigned and done next time someone has time or intends to do a revision of the workflow documentation anyway (and then remove the category once the workflow documentation is adjusted). Theoretically, this could be a good first issue itself.

Be aware: this is not to get rid of the triage stage, but only of the triage category, because the first is already indicated by other information so that the latter is not necessary.

Just some thoughts I had when labeling :wink:

2

Triage is a viable category where it is not labelled straight away and we need to discuss where it belongs to before getting assigned properly (by severity and so on).

So it is transient in nature. I wasn’t involved with workflow, but that’s how it is used in other ticketing systems in real life.

3

The idea was that once something is labelled, it gets into triage so that anyone can pick it up. So based upon the original idea, if something is labelled but not yet assigned, it is in triage, which implies that labelled and in OPEN already contains the triage information. This is what seems to have been the average determination of the “triage stage” before I labelled the tickets a few days ago, while the “triage category” was used by only two tickets I think.

However, giving it a new sense is of course another alternative.

This is what seems to currently take place all in the OPEN category, including the subsequent triage stage. Once a ticket comes up, it has no label and is in OPEN. If someone labels it, you can see it immediately within the OPEN category through the shown labels below the ticket: the OPEN category had some tickets that were labelled, some were not. Without a dedicated triage category, this would imply that the labelled tickets are in the triage stage, while the non-labelled are not yet in triage.

So as I said, this is not to get rid of the triage stage, but only the triage category, because it is not widely used. I agree that a triage stage makes sense. But the category seems to be rarely used - my guess is because the information is already contained in OPEN + labeled. I think this issue was from the beginning, but back then we thought to keep it to see if people start to use the category consistently at some point.

4

Open is supposed to be untouched status, not really category. I don’t think it is comparable to triage.

Definition of triage made in labels in repo is unmistakable.

Issue is labelled & classified, but no one has been assigned yet. Do you want to take over? Feel free to assign yourself and shift the issue to “In progress”!

5

I know the texts, I wrote them :wink: I wrote them unmistakable for good reasons.

But since the very beginning, this definition has not been implemented. It was already a topic in the meetings, but until today, it is simply not done that way :wink:

supposed is the major term here :slight_smile: Practically, OPEN was also used for the triage stage from the beginning, despite the workflow and label documentation. It has been always a vague blur between the seemingly-clearly separated categories. Discussions and consents to finally implement it have not changed that. This is why I suggest to tailor to the reality after a year or two, in order to have a clear dashboard at some point.

6

I don’t know what you are trying to fix. In any repo, there are open and closed status.
Without too much effort, people expect the number of open ticket to be near zero.
When open ticket is zero, we celebrate.

I don’t really follow a purpose of this thread.

7

We have a common dashboard to have the organization consolidated:

→ this is where the Docs organization is intended to be centralized

So this is the place where all tickets come together, and vice versa, where all tasks should be put into a ticket, in order to have an overview of the Docs, what is going on, what should be done, who currently does what and who needs what - not limited to GitLab tasks. The idea was also to make this enabling an asynchronous workflow. The latter depends on this central place to be maintained carefully (I do not know if this currently works out since I was absent some time?).

The page you mentioned above, with the definitions of the labels, is intended for that Dashboard. On the dashboard, you can also see the difference of the labels: labels that form a column, and labels that are only shown next to the assigned tickets (the workflow organization used to differentiate correspondingly between the two types of tickets).

This is also intended to be the first point for newcomers to arrive, to see, e.g., all “Good First Issues”, and to see what is open, but also to have something they can compare against the workflow organization, to see how it manifests (which it currently doesn’t do in a compliant manner).

However, I was absent some time, was there a major change I have overseen?

8

During weekly meeting, attendees and the board run through open ticket and anything that is flagged up as ‘meeting’. We also go through Quick Docs based on open issue and PR request.

No one has come up asking to clarify labels.

Whether a issue or PR/MR is flagged up not as intended is secondary. We go through those to label them, but raw number of open or closed matters rather than accuracy of labelling.

9

Ah, I see. So it has informally centralized again in a synchronous workflow, with a focus on the meetings. Yeah, in that case this topic might be less relevant. However, then the workflow could be maybe simplified, also formally, to reflect the less complex/explicit reality. The workflow pages seem to still reflect more the original intention to achieve independent, explicitly aligned and documented asynchronous flows. Ticket #21 seems to be less focused on that so far. However, with this in mind, the topic should be considered closed.

10

No, labelling ticket and ticket review are not centralized on the Docs meetings. It all depends on the number of topics and workload on each week. Labelling ticket is sometimes done on the meetings, but not always. A focus is more gravitated toward PR/MR review and progress check (in progress or not).

At some point, we go through QuickDocs as a priority and have a quick open floor.

The workflow applies whatever communication channel we use.

Meeting is an opportunity for collaborative session to discuss priorities, assignment, change labels, progress, getting the job done, or delays. Also it avoids any arbitrary decisions.