Offer enterprise-grade operational experience of GitLab products from streamlined deployment and maintenance, disaster recovery, secure search and discoverability, to high availability, scalability, and performance.
Enablement focuses on improving our capabilities and metrics in the following areas:
For more details, refer to the Enablement Sub-department Direction.
The following people are permanent members of teams that belong to the Enablement Sub-department:
|Alex Ives||Engineering Manager, Database (Interim)|
|Andreas Brandl||Staff Backend Engineer, Database|
|Diogo Frazão||Backend Engineer, Database|
|Krasimir Angelov||Senior Backend Engineer, Database|
|Simon Tomlinson||Senior Backend Engineer, Database|
|David 'DJ' Mountney||Backend Engineering Manager (interim), Distribution:Build|
|Balasankar "Balu" C||Senior Distribution Engineer, Distribution:Build|
|Dmitry Makovey||Senior Distribution Engineer, Distribution:Build|
|Dustin Collins||Distribution Engineer, Distribution:Build|
|Robert Marshall||Distribution Engineer, Distribution:Build|
|Steven Wilson||Backend Engineering Manager, Distribution:Deploy|
|Gerard Hickey||Senior Distribution Engineer, Distribution:Deploy|
|Hossein Pursultani||Distribution Engineer, Distribution:Deploy|
|Jason Plum||Staff Distribution Engineer, Distribution:Deploy|
|Mitch Nielsen||Distribution Engineer, Distribution:Deploy|
|Nick Nguyen||Fullstack Engineering Manager, Geo, Acting Product Manager, Geo|
|Aakriti Gupta||Senior Backend Engineer, Geo|
|Catalin Irimie||Senior Backend Engineer, Geo|
|Douglas Barbosa Alexandre||Staff Backend Engineer, Geo|
|Gabriel Mazetto||Senior Backend Engineer, Geo|
|Ian Baum||Senior Backend Engineer, Geo|
|Michael Kozono||Staff Backend Engineer, Geo|
|Valery Sizov||Senior Backend Engineer, Geo|
|Zack Cuddy||Senior Frontend Engineer, Geo|
|Changzheng Liu||Backend Engineering Manager, Global Search and Memory|
|Dmitry Gruzd||Senior Backend Engineer, Global Search|
|John Mason||Senior Backend Engineer, Global Search|
|Terri Chu||Senior Backend Engineer, Global Search|
|Changzheng Liu||Backend Engineering Manager, Global Search and Memory|
|Aleksei Lipniagov||Senior Backend Engineer, Memory|
|Matthias Käppler||Senior Backend Engineer, Memory|
|Nikola Milojevic||Senior Backend Engineer, Memory|
|Roy Zwambag||Backend Engineer, Memory|
|Craig Gomes||Senior Engineering Manager, Datastore|
|Dylan Griffith||Staff Backend Engineer, Sharding|
|Patrick Bair||Senior Backend Engineer, Sharding|
|Thong Kuah||Staff Backend Engineer, Sharding|
The following table shows who will provide cover if one or more of the Enablement Engineering management team are unable to work for any reason.
|Team Member||Issues/MRs Backup||People Management Backup||Escalation|
|Chun Du||Christopher Lefelhocz||Christopher Lefelhocz||Eric Johnson|
|Craig Gomes||Kamil Trzcinski (Sharding), Andreas Brandl (DB)||Changzheng Liu||Chun Du|
|Changzheng Liu||Dmitry Gruzd (Global Search), Matthias Käppler (Memory)||Craig Gomes||Craig Gomes|
|Steven Wilson||DJ Mountney||Nick Nguyen||Chun Du|
|Nick Nguyen||Douglas Alexandre||Steven Wilson||Chun Du|
If an Engineer is unavailable the person providing
Issues/MRs coverage will reassign open issues and merge requests to another engineer, preferably in the same group.
Some people management functions may require escalation or delegation, such as BambooHR and Expensify.
This can be used as the basis for a BCP Communication Plan and Role Assignments, as well as a general guide to Enablement Engineering continuity in the event of one or more team members being unavailable for any reason.
The following members of other functional teams are our stable counterparts:
|Nick Brandt||Product Designer, Enablement:Global Search|
|Sunjung Park||Senior Product Designer Enablement:Geo/Distribution|
|Achilleas Pipinellis||Senior Technical Writer, Enablement|
|Andrew Kelly||Senior Security Engineer, Application Security, Growth (Activation, Conversion, Expansion, Adoption), Fulfillment (Purchase, License, Utilization), Enablement (Distribution, Geo, Memory, Global Search, Database)|
|Erick Banks||Senior Software Engineer in Test Enablement:Search|
|Grant Young||Staff Software Engineer in Test, Enablement:Distribution|
|Nailia Iskhakova||Senior Software Engineer in Test, Enablement:Distribution|
|Nick Westbury||Senior Software Engineer in Test, Enablement:Geo|
|Vincy Wilson||Quality Engineering Manager, Enablement, Fulfillment, Growth, ModelOps, and Sec|
|Joshua Lambert||Director of Product Management, Enablement|
|Fabian Zimmer||Group Manager, Product, Enablement|
Based on the scale of frontend engineering in Enablement sub-department, the Combined Team model is being experimented where both Frontend and Backend Engineers report to a single Engineering Manager. It's believed that the combined team model enables higher efficiency for the situation of Enablement and the experiment is subject to continuous review. The team will return to functional model by establishing a dedicated frontend engineering team when the frontend engineering team reaches the manager to individual contributor ratio guideline.
To enhance the overview of team direction, all Enablement development teams use Epics to organize projects and dogfood the Roadmap feature to communicate short- and mid-term product development roadmap, although each team customizes their usage such as applying specific labels. Examples:
WIP. These MRs exempt from the above review.
|WIP in Subject?||> 30 days?||Action Required?|
Documenting development decisions is another way to increase efficiency. These decisions can be either in an issue explicitly stating that we will not work on this issue, the product category page for your group or a more formal decision log in your group's section of the handbook. Whatever your chosen desitination, each group should try to maintain a single source of truth for the decisions. A recent example (without mentioning specific product name) had a development team researching an open source product to accelerate development time only to find out later that this research had been previously completed and the product was eliminated from consideration. If this decision had been discoverable via documentation or issue it would have saved precious development time.
We have started creating decision logs to benefit our internal development team as well as our greater GitLab community. It is up to each group to determine the best location for decision logs to be discoverable. For example, the Database team has a decision log for Sharding GitLab with CitusDB in the Enablement/Database section of the handbook and a decision log for the Sharding Working Group in the working group section of the handbook.
For issues, a clear decision is when an issue is successfully closed. However, if an issue is closed because we "won't do it" it may not be immediately clear. We are adopting the
~won't do label for those issues. Often the pattern is to just stash these issues in the
~backlog. This can be misleading to those watching the issue and frustrating to the original author, especially if they are a community contributor. When we apply a
won't do label to an issue, we are making a clear decision. If there is no pushback on the
won't do label then we made the right decision. If there is pushback and we need to reprioritize the issue, then that is a good outcome as well.
The Enablement teams leverage the following software or SaaS services to deliver our products. For general information of procurement, checkout the procurement team page. For procurement questions, bring to #procurement. To make new Purchase Order (PO), create a new procurement issue.
|Software||Vendor Link||Term||Renewal Date||Team Impacted||Comments|
|packagecloud.io||https://packagecloud.io/||Annual||March 30th||Distribution||Existing vendor, last renewal issue|
|dependencies.io||https://www.dropseed.io/||Annual||November 1st||Distribution||Existing vendor, last renewal issue|
|postgres.ai||https://postgres.ai/||Trial||TBD||Database||Existing vendor, request issue|