Feature Flag usage Working Group

Attributes

Property	Value
Date Created	Dec 3, 2020
End Date	July 28, 2021
Slack	#wg_feature-flag-usage (only accessible from within the company)
Google Doc	Working Group Agenda (only accessible from within the company)

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

✅ Fulfillment of the feature flag architectural blueprint
✅ Completion of all issues labelled with the working group scoped label on GitLab.org and GitLab.com
✅ Refinement and assignment of Feature Flag Training, and Feature Flag Monitoring training for GitLab engineers
✅ Audit, refine, and communicate the Feature flags in development of GitLab documentation
✅ Each functional lead is satisfied of the state of the feature flag processes in place in the development of GitLab
✅ 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 repsonsible 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.

Working Group Role	Person	Stakeholder Department	Title
Executive Sponsor	Christopher Lefelhocz		VP of Development
Facilitator	Ricky Wiens	Engineering Manager	Backend Engineering Manager, Verify:Testing
Functional Lead	Kamil Trzciński	Engineer	Distinguished Engineer, Ops and Enablement
Functional Lead	Kenny Johnston	Product Manager	Senior Director of Product Management, Ops
Functional Lead	James Heimbuck	Product Manager	Senior Product Manager, Verify:Pipeline Execution
Member	Grzegorz Bizon	Engineer	Staff Backend Engineer, Verify
Member	Craig Gomes	Engineering Manager	Backend Engineering Manager, Memory and Database
Member	Michelle Gill	Engineering Manager	Engineering Manager, Create:Source Code
Member	Doug Stull	Engineer	Senior Fullstack Engineer, Growth:Expansion
Member	Andrew Fontaine	Engineer	Senior Frontend Engineer, Release
Member	Rémy Coutable	Engineer	Staff Backend Engineer, Engineering Productivity
Member	Marin Jankovski	Delivery Engineer	Senior Engineering Manager, Infrastructure, Delivery & Scalability
Member	Marcia Ramos	Technical Writing	Senior Technical Writer, Create, Development Guidelines