Support Toolbox Project Lifecycle
Overview
The Support Toolbox GitLab group holds the tools, automations and AI workflows built by and for the Support team. Projects fall into four categories so the team can tell which are approved, which are usable but unapproved, and which are no longer maintained. Three of them are groups:
- Experimental
- Staging
- Toolbox (the root of the group)
Archive is a state a project can be in, not a group.
The README on the Support Toolbox group page lists the Support Toolbox projects, with details such as purpose, owner and dependencies. Start there to find out what exists.
Before starting a new project, check the Toolbox and Staging for an existing tool that already does the job.
Lifecycle
flowchart LR
New([New project]) --> experimental
experimental -->|Works and is usable| staging
staging -->|Needs more work| experimental
experimental -->|Abandoned| archive
staging -->|Widely adopted and<br/>approved by SIG| toolbox
staging -->|No longer used<br/>after review| archive
toolbox -->|No longer maintained<br/>or replaced| staging
toolbox -->|No longer used,<br/>approved by SIG| archive
click experimental "https://gitlab.com/gitlab-com/support/toolbox/experimental"
click staging "https://gitlab.com/gitlab-com/support/toolbox/staging"
click toolbox "https://gitlab.com/gitlab-com/support/toolbox"
classDef exp fill:#fdf1dd,stroke:#c17d10,color:#000
classDef stage fill:#e1effe,stroke:#1f75cb,color:#000
classDef tool fill:#dff5e3,stroke:#108548,color:#000
classDef arch fill:#ececef,stroke:#737278,color:#000
class experimental exp
class staging stage
class toolbox tool
class archive arch
Categories
Experimental
Group: gitlab-com/support/toolbox/experimental
New projects, prototypes and proofs of concept, kept in the experimental subgroup. These may change, break or be abandoned.
Staging
Group: gitlab-com/support/toolbox/staging
The standard home for a working project once it leaves Experimental. A Staging project is usable and available to the team, but is not approved by the Support Innovation Group (SIG).
Some Staging projects may be put forward for SIG approval as adoption grows. Others, such as niche tools for specific team members or projects that overlap with a more widely adopted tool, stay in Staging.
Toolbox
Group: gitlab-com/support/toolbox (the root of the group, not a subgroup)
This group contains SIG-approved projects that are popular and widely used by Support, the wider organization or customers. This includes:
- Projects with active integrations or CI automations that Support workflows depend on, such as scheduled or triggered pipelines, bots, reports and Chrome extensions.
- AI workflows that Support relies on, such as agent runtimes, agent skills, MCP integrations and AI-assisted automations.
A project that does not meet these criteria is not added to the Toolbox.
Any change to a Toolbox project requires SIG approval. This covers adding a project to the Toolbox, removing one, and archiving one. See Requesting SIG approval for a Toolbox project.
Archive
Archive is a state of a project, not a group. There is no archive group. An archived project is read-only in GitLab and stays in whichever group it was in, whether that is Experimental, Staging or the Toolbox root.
Archive a project that is no longer maintained or used. Signs include:
- No meaningful activity
- No running automations
- A superseded tool
- An owner who has left
Archived projects are not moved or deleted. See the GitLab documentation on how to archive a project and how to unarchive a project. Archiving also stops scheduled pipelines and pull mirroring, and removes deployed Pages.
Moving projects between categories
| Move | Who decides |
|---|---|
| Experimental to Staging, or Staging to Experimental | The project owner. No approval is needed. |
| Staging to Toolbox, or Toolbox to Staging | SIG approves. See Requesting SIG approval for a Toolbox project. |
| Experimental or Staging to Archive | The project owner, or a Support Leader if the owner has left, based on evidence that the project is not used or maintained, followed by an announcement and an objection period. |
| Toolbox to Archive | SIG approves, then the project follows Archiving a project. |
Requesting SIG approval for a Toolbox project
Do not add, remove or archive a Toolbox project before SIG has approved the request.
- Create a request using the SIG Intake Request Form. State the project, what you want to do (add it, remove it or archive it), and how it meets the Toolbox criteria or why it no longer does.
- Wait for SIG to review the request and for approval through the SIG workflow and approval process.
- Once approved, make the change and comment on the request when it is done:
- Add to the Toolbox: a Support Leader transfers the project from Staging to the root of the Toolbox group. Only Support Leaders can add projects to the Toolbox group, and having that permission does not replace SIG approval.
- Remove from the Toolbox: the project owner or a Support Leader transfers the project to the Staging group.
- Archive: follow Archiving a project.
- After a transfer, check CI/CD pipelines, integrations and links that relied on the old project path.
Archiving a project
- If the project is in the Toolbox, get SIG approval first.
- Review the project’s recent activity, running automations and owner status.
- Announce the archive list with a date, and give the team time to raise objections.
- Disable any running automations, such as scheduled pipelines.
- Archive the project on the announced date.
- Ask the team to report anything that broke, such as CI/CD pipelines, integrations or links that relied on the old project path.
182b20b5)
