Skip to content

Gitlab Triaging

To aid in ensuring that we not only can action, but provide feedback. We triage issues and merge requests within gitlab.

Our triaging is automatic and occurs on schedule. This removes the posibility of a human forgetting to conduct triaging. This also ensures that the triage policies that we use, are always run in accordance with the rules that we set.


Our policies can be found on gitlab. we have two policies, one covers the whole of No Fuss Computing group, and the other for projects.

No Fuss Computing Policy

This policies purpose is carry out generic tasks, that generally will not require any input from either author or assignee.

:red_circle: STOP
This policy is designed to run multiple times a day. This enables actions to be taken quickly that will be picked up by the project triaging policies.

No Activity on Assigned MR in 10 days

Purpose: To ensure that development work continues

This policy detects any merge request to have a reminder placed upon it for the developer/contributor to take action to complete work, or close the Merge Request. Label ~"workflow::stalled" is applied to the Merge Request.

issue workflow stalled

Purpose: Label to denote that activity on the issue has ceased. enables adding issue to summary issue for manual intervention

This policy checks issues that have label ~"workflow::underway" which denotes it is being worked on, and if no action has been taken in 10 days, marks the issue as ~"workflow::stalled".

Set Issue Weight

Purpose: To enable us to prioritize effort

This tasks sets the issue weight based off the values of the impact and priority labels. The value of the weight is determined by our scoring table. The weight plays a significant role for us to determine the priority of effort accross the No Fuss Computing group.

No Activity on Issue in 30 Days

Purpose: To have each issue checked to see what further action could be done on the issue, if any including, closing if no longer applicable.

This policy creates a summary issue for action that lists all issues that have had no action within the last 30 days so that developers of a project can take action to progress the issue at hand.

Project Policy

This policies purpose is to carry out more specific tasks that may require author or assignee input. this policy is designated to individual projects and/or repositories.

Summary Missing Labels

Purpose: Mandatory labels provide ability to filter issues and are also used to calculate weight. A label is also useful in providing feedback when combined with definitions

This policy Creates a summary issue with issues found that do not have labels: Type, Impact and Priority, and lists them as requiring ALL of these labels

Issue Failed to provide feedback

Purpose: It is assumed that if no feedback is provided, that the issue is no longer relevent and should be closed. This enables minimising the effort placed in to issue that are not-relevent.

This policy Creates a summary issue with issues found that have had no action in 10 days or longer, that has label ~stage::feedback required, and closes the issue after posting a comment to the issue author, stating they failed to provide feedback.


This page forms part of our Operations Manual.

Page Metadata
Version: ToDo: place files short git commit here
Date Created: 2022-08-25
Date Edited: 2023-05-23


Would You like to contribute to our Operations Manual? You can assist in the following ways:


ToDo: Add the page list of contributors

Back to top