Govern Sub-department
The Govern sub-department teams are the engineering teams in the Govern Stage of the product.
Vision
To support GitLab’s product vision through alignment with the Govern stage product direction.
Groups
- Authentication
- Authorization and Anti-abuse
- Compliance
- Pipeline Security
- Security Policies
- Threat Insights
Priorities
Group priorities are reviewed collaboratively with product counterparts and published on the Govern direction pages
- Anti-abuse
- Authentication
- Authorization
- Compliance
- Pipeline Security
- Security Policies
- Threat Insights (16.x)
Product Documentation Links
- Security Dashboard
- Vulnerability Pages
- Security scanner integration
- Secure and Govern terminology
- Govern testing priorities
- Pipeline Security
Sub-department development people leaders
| Name | Role |
|---|
To contact Govern sub-department development people leaders, use the following aliases:
- GitLab:
@gitlab-org/govern/managers - Slack:
@s_govern_managers - Slack channel:
#govern-development-people-leaders
All Team Members
Authentication
| Name | Role |
|---|---|
 Adil Farrukh
|
Engineering Manager, Software Supply Chain Security:Authentication |
Authorization and Anti-abuse
| Name | Role |
|---|---|
 Jay Swain
|
Engineering Manager, Govern:Authorization and Anti-abuse |
 Ayush Billore
|
Backend Engineer, Govern:Authorization |
 Alex Buijs
|
Senior Fullstack Engineer, Govern:Authorization |
 Daniel Tian
|
Senior Frontend Engineer, Govern:Authorization |
 Eugie Limpin
|
Senior Fullstack Engineer, Govern:Anti-Abuse |
 Hinam Mehra
|
Fullstack Engineer, Govern:Authorization |
 Ian Anderson
|
Staff Backend Engineer, Govern:Anti-Abuse |
 Jarka Košanová
|
Staff Backend Engineer, Govern:Authorization |
 Mo Khan
|
Senior Backend Engineer, Govern:Authorization |
Compliance
| Name | Role |
|---|---|
 Nathan Rosandich
|
Engineering Manager, Govern:Compliance |
Pipeline Security
Scott Hampton
Dmytro Biryukov
Erick Bajao
Mireya Andres
Shabini RajadasSecurity Policies
| Name | Role |
|---|---|
 Alan (Maciej) Paruszewski
|
Engineering Manager, Security Risk Management:Security Policies |
Threat Insights
Neil McCorrison
Brian Williams
Dave Pisek
Lorenz van Herwaarden
Samantha Ming
Savas Vedova
Subashis Chakraborty
Ryan Wells
Bala Kumar Subramani
Gregory Havenga
Mehmet Emin Inac
Michał Zając
Rushik SubbaStable Counterparts
The following members of other functional teams are our stable counterparts:
Asmaa Hassan Ahmed Ali
Becka Lippert
Harsha Muralidhar
Joseph Longo
Jocelyn Eillis
Joe Randazzo
Lucas Charles
Miranda Fluharty
Sam WhiteGovern staff meeting
The Govern stage engineering department leaders meet weekly to discuss stage and group topics in the Govern staff meeting. This meeting is open to all team members and is published on the Govern stage calendar.
Meetings have an agenda and are async-first, where the aim is to resolve discussions async and leave time in the meeting to deep dive into topics that require more discussion.
We use the Govern Sub-department Board to better organize our discussions.
Weekly updates
The Govern development teams provide weekly status updates using an issue template and CI scheduled job. As priorities change, engineering managers update the template to include areas of interest such as priorities, opportunities, risks, and security and availability concerns. The updates are GitLab internal.
Quarterly review updates
Every quarter, an engineering manager for each group in the Govern Sub-department prepares the quarterly review update using the issue template and records approximately 5 minutes to summarize the last quarter from the engineering perspective and present a high-level plan for the group for the next one to respond to quarterly Product strategy and explain our goals for next quarter.
We aim to foster collaboration and communication between engineering managers in the Govern Sub-department, align groups on product priorities for the next quarter, and celebrate our successes together.
Quarterly review update template can be found here).
OKR planning
Our OKRs are a mixture of top down, aligned with Company-wide, Product, or Engineering Division OKRs, and bottom up engineering-led initiatives driven by our team members in Govern. Any team member can propose an OKR for Govern by creating a proposal issue in our internal OKR project. The issue can be used to collaborate and discuss the proposal. When we are ready to commit, we can create or align to an existing Objective, and add specific key results to track through the quarter.
Labels:
Sub-Department::Govern- for top-level sub-department Objectives.devops::govern- for Objectives and key results for the stage, and stage groupsgroup::- for Objectives and key results for a specific group
Each Objective and Key Result should have an assignee who is DRI for providing status updates throughout the quarter. Regular updates are preferred. At a minimum these should be updated
- By end of day, the second Friday of every month
- Ay the end of the quarter
OKRs can be changed or closed during the quarter if they are completed, or as our goals change. This ensures we are focusing on areas that are revelant to our current and future priorities.
PTO
To support our teams, and commitments made to internal and external customers, team members in Govern are encouraged to create a PTO issue before going on leave lasting a week or longer.
The issue provides a place to discuss and document coverage for any work in progress, or projects where the team member is the directly responsible individual (DRI), and support the Paid Time Off at GitLab policy.
We use an internal issue tracker as team member PTO is not public information, and a PTO template
When a team-member takes some time off, it is important that their work is still being followed up on if needed. We want to make sure that any MR that lands in staging and production environments while we are out gets proper attention and is verified by a counterpart. Therefore, when getting close to our time-off period, we should do the following:
- Any MR that can be put on hold until we’re back from PTO should be put in the
Draftstatus. This ensures that the MR won’t be merged accidentally without a clear DRI to follow up on it. - Other non-draft MRs and freshly merged MRs, which need to be verified on staging, should be assigned to another engineer. The additional DRI will be responsible to verify the changes if they land in staging while we’re out. When doing this, we must ensure that enough context has been provided in the MR’s description and/or the related issue (setup, testing, potential impact, design decisions, etc.).
Keep in mind that, while we strongly recommend following this process when taking some time off, it might not be relevant all the time. For example, if our time-off period is going to be short and/or our active MRs are minor enough, it might make sense to ignore these recommendations and follow up when we’re back.
Engineering Leadership - PTO or unavailable
Team members should contact any Govern Engineering Manager by mentioning in #sd_govern_engineering or #govern-development-people-leaders if they need management support for a problem that arises, such as a production incident or feature change lock, when their direct manager is not available. The Govern manager can provide guidance and coordination to ensure that the team member receives the appropriate help.
Some people management tasks, including Workday and Navan Expense, may require for escalation or delegation.
Skills
Because we have a wide range of domains to cover, it requires a lot of different expertise and skills:
| Technology skills | Areas of interest |
|---|---|
| Ruby on Rails | Backend development |
| Go | Backend development |
| Vue, Vuex | Frontend development |
| GraphQL | Various |
| SQL (PostgreSQL) | Various |
| Docker/Kubernetes | Threat Detection |
Everyone can contribute
At GitLab our goal is that everyone can contribute. This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of quick wins that may be more suitable for first time contributors, and contributors new to the domains in Govern.
If the contributor needs an EE license, we can point towards the Contributing to the GitLab Enterprise Edition (EE) section on the Community contributors workflows page.
Testing
During the planning phase of a milestone, the EM for each group will create a new issue using the template in epic, for any major new features and tag Software Engineer in Test from Govern. SETs from Test Engineering and EMs can periodically review/discuss the list of open issues, and add appropriate priority labels.
The intent of shifting left and testing at the right level is that teams are responsible for testing and to have engineers doing the feature coverage reviews and adding specs or E2E test as needed. The reason for including the SET is to give oversight across the groups and provide guidance/support. If the SET has capacity then they can contribute as needed, using the priority labels, but this is not the expectation.
Metrics
Links and resources
- Stage links
- Discussions and issues are located at
gitlab-org/govern - General Slack #s_govern
- Social channel #sec-section-social
- Engineering Slack #sd_govern_engineering
- Govern Shared Calendar ID
gitlab.com_ed6207uel78de0j1849vjjnb3k@group.calendar.google.com
- Discussions and issues are located at
- Group #g_govern_security_policies
- Group #g_govern_threat_insights
- Group #g_govern_compliance
- Software Supply Chain Security working group
Technical Documentation Links
24070bf5)
