Feature Flag usage Working Group

Attributes

Charter

This working group will co-ordinate the organization of the effort to improve the usage of feature flags in the development of GitLab. There are many asynchronous and currently ongoing discussions in the organization about internal feature flag usage. We aim to collect and co-ordinate these conversations in order to create uniform policies and processes for the usage of feature flags within GitLab. The uniformity of these policies is key in order for internal stakeholders, community members, and customers have more consistent insight into the availiabilty of GitLab features.

Scope and Definitions

This group will create processes and policies that are as lean as possible in order to ensure that the way feature flags are used by engineers meets the needs of all stakeholders. Stakeholders for feature flags generally are individuals who care about the current state of features on GitLab.com and self-managed GitLab instances of a particular version.

Definitions

• Feature Flag - this isn’t necessarily the feature flag feature but rather the way we use feature flags in the development of GitLab

Exit Criteria

1. ✅ Fulfillment of the feature flag architectural blueprint
2. ✅ Completion of all issues labelled with the working group scoped label on GitLab.org and GitLab.com
3. ✅ Refinement and assignment of Feature Flag Training, and Feature Flag Monitoring training for GitLab engineers
4. ✅ Audit, refine, and communicate the Feature flags in development of GitLab documentation
5. ✅ Each functional lead is satisfied of the state of the feature flag processes in place in the development of GitLab
6. ✅ Provide data to support long-term feature flag management so we can monitor the lifecycle of feature flags and take action on them as appropriate.

Work in Progress

• Capturing the current feature flag lifecycle

Roles and Responsibilities

The functional leads will be responsible for:

• Representing the needs of individual stakeholders in their department/sub-dept
• Gathering and consolidating feedback on specific proposals from their department/sub-dept
• Communicating the output from the working group (if any) and answering questions from their dept/sub-dept

Ideally the functional lead is someone who is an IC that might be affected by the policy put in place. but anyone capable of representing a department or sub-department in the fashion mentioned above is welcome.

The stakeholder departments in the table are the ones identified in the architectural blueprint, and listed here for reference: Engineer, Engineering Manager, Engineering Director, Product Manager, Technical Writer, Delivery Engineer, SRE.

View page source - Edit this page - please contribute.