Skip to content

Rollout Iteration 2(GA) Custom Statuses

Rollout Plan

Internal Testing

We'll follow the process outlined here to test internally and dogfood.

Alpha Testing

The work_item_status_feature_flag feature flag is enabled for the internal top-level Plan Stage groups: gl-demo-premium-plan-stage and gl-demo-ultimate-plan-stage.

  • System-defined lifecycle and statuses are enabled on gl-demo-premium-plan-stage.
  • Custom lifecycle and statuses will be enabled on gl-demo-ultimate-plan-stage. The transition from system-defined to custom statuses will be performed by the engineers. Ideally, engineers set up custom statuses on a call, and share a recording with the wider team. After that, @donaldcook, @gweaver, and @nickleonard can continue testing custom statuses here.
  • If @donaldcook, @gweaver, and @nickleonard would prefer to walk through the transition process themselves, they can enable the feature flag on issue-reproduce and use it as a backup to test the full transition flow.

We're using separate top-level groups because once custom statuses are enabled for a namespace, reverting to system-defined statuses is not possible. This allows us to test both workflows in parallel.

We'll set up custom statuses on the demo-ultimate-plan-stage group that mirror the product development flow.

Triage

  • New [Open default]

To do

  • Start — renamed from Todo
  • Planning breakdown
  • Ready for development
  • Validation backlog

In progress

  • Problem validation — Pajamas-y purple #7759C2
  • Design — Pajamas-y purple #7759C2
  • Solution validation — Pajamas-y purple #7759C2
  • In dev
  • Blocked — let's make this bright red
  • In review
  • Verification — maybe some other color? green or orange (yellow has bad contrast)?
  • Awaiting security release — green?

Done

  • Complete [Closed default] — renamed from Done

Canceled

  • Won't do
  • Duplicate [Duplicate default]

End-of-line testing

The work_item_status_feature_flag feature flag will be enabled for gitlab-com and gitlab-org groups.

We'll set up custom statuses on the gitlab-com and gitlab-org groups with help from the GitLab admin that mirror the product development flow.

Triage

  • New [Open default]

To do

  • Start — renamed from Todo
  • Planning breakdown
  • Ready for development
  • Validation backlog

In progress

  • Problem validation — Pajamas-y purple #7759C2
  • Design — Pajamas-y purple #7759C2
  • Solution validation — Pajamas-y purple #7759C2
  • In dev
  • Blocked — let's make this bright red
  • In review
  • Verification — maybe some other color? green or orange (yellow has bad contrast)?
  • Awaiting security release — green?

Done

  • Complete [Closed default] — renamed from Done

Canceled

  • Won't do
  • Duplicate [Duplicate default]

Dogfooding

TBA

Release

By the the end of Thursday, 10th of July (before the 18.2 cut-off), the work_item_status_feature_flag will be enabled globally via ChatOps, followed by the merge of this MR: Enable `work_item_status_feature_flag` by default (!194974 - merged).

Prior to enabling the feature flag globally, we'll update the documentation by merging this MR: Add documentation for work item statuses (!196068 - merged).

References

Discussion about internal testing, dogfooding and the rollout of Iterations 1 and 2 of work item statuses can be found here.

Edited by Agnes Slota