Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Feature Flag usage Working Group

On this page

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-hosted GitLab instances of a particular version.

Definitions

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

Roles and Responsibilities

The functional leads will be repsonsible for:

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:Testing
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
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license