Support Toolbox Project Lifecycle

How projects in the Support Toolbox group are categorized as Experimental, Staging, Toolbox or Archive, what qualifies for the Toolbox, and who approves each move.

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:

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.

  1. 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.
  2. Wait for SIG to review the request and for approval through the SIG workflow and approval process.
  3. 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.
  4. After a transfer, check CI/CD pipelines, integrations and links that relied on the old project path.

Archiving a project

  1. If the project is in the Toolbox, get SIG approval first.
  2. Review the project’s recent activity, running automations and owner status.
  3. Announce the archive list with a date, and give the team time to raise objections.
  4. Disable any running automations, such as scheduled pipelines.
  5. Archive the project on the announced date.
  6. Ask the team to report anything that broke, such as CI/CD pipelines, integrations or links that relied on the old project path.