The following teams comprise the sub-department:
It is important to delineate who the EM and PM DRIs are for every functionality, especially where this may not be obvious. This is documented on a dedicated delineation page.
Product direction can be found on the Sec Section Product Direction handbook page.
Keeping our projects organized is very important for productivity and maintainability.
In general, we want to keep as few projects in security-products as necessary.
security-products should only contain :
secure and govern should have projects for:
There may be projects that should belong in secure or govern but for technical reasons are much easier to have in security-products. In those cases, we can locate the project in security-products if reasonable efforts were made to get the project in secure or govern but were unsuccessful.
Due to https://gitlab.com/gitlab-org/gitlab/-/issues/220535, we may choose to leave the Issue tracker enabled in the new project. In these cases, please consider these to avoid abandoned issues:
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
We have two stage level calendars, Secure Stage Calendar and Govern Stage Calendar, where we host cross-group events such as:
Each group also has a calendar for team-based discussions, such as the our weekly group syncs.
We encourage utilizing our available Google Groups instead of including individuals as attendees when possible. Along with ensuring the event is represented on individual's calendars for visibility, new team members are automatically added to events (as well as removed when someone departs from a team).
Google groups were setup and are structured as:
The members of each google group consists of stable counterparts and the correct eng-dev-[sub-department]-[team] group of engineers. When stable counterparts change, or team members onboard/offboard the appropriate group should be updated.
In the vast majority of cases, work is scoped to individual groups within the section. However, there are times when the section needs to design and execute solutions as a coordinated Section or risk creating poor and non-cohesive user experiences.
These initiatives will be orchestrated through epics and issues. Initiatives with the following labels are deemed to fall in this category of work.
At least once per milestone, Senior Engineering Managers in the section will do the following:
Generated issues will be worked through normal prioritization processes as they are distributed to individual groups.
In order to help the Sec section come to resolution on defining approaches to section-wide issues, we have formed an Architectural Council. This group comprises tech leads (and SMEs to provide context) in order to keep the team small and nimble. The group is a non-authoritative, supportive group whose members provide representative insights from their respective teams.
Common scenarios/architectural concepts will likely be resolved/discovered. These should be captured generically in an architectural guidelines page of the handbook and, if possible, codified into our processes/templates.
The table below captures characteristics (requirements?) of work that is in-scope, opt-in, or out-of-scope. All requirements must be met for each category.
| Reason/Condition | In-Scope | Opt-in | Out-of-Scope |
|---|---|---|---|
| Does not involve architectural decisions | x | ||
| Is after-the-fact | x | ||
| Is not already covered by architecture guidelines/handbook | x | x | |
| Has broad impact within #secure1 | x | ||
| Is a new unit of work | x | x | |
| Is strictly #secure or #govern | x | x | |
| Could not come to an agreement (escalation) | ? | ||
| Involves architecture decisions | x | x |
GitLab’s Stance for Architectural issues: https://about.gitlab.com/handbook/engineering/architecture/
The Sec Section Frontend Chapter at GitLab is a federation of all Frontend Engineers and team members interested in frontend-related topics within the Sec Section.
The main purpose of the Frontend chapter is to connect Frontend Engineers within the Secure Group, share knowledge, exchange about common challenges and leverage their collaboration.
The chapter was founded when Secure transitioned to Fullstack Teams which resulted in some Engineers being the isolated experts within their team.
The members of the chapter exchange through the slack-channel, there is also a sync meeting twice a month on the Secure Group Calendar.
There is no strict rulebook of how chapter-members collaborate with each other. The chapter is about visibility of challenges that might be similar amongst the different teams within the secure-group and how we can benefit from this.
The frontend chapter has identified components that cross team boundaries within the Secure group.
@gitlab-org/secure/secure-frontend-chapter.Our team monitors LCP (Largest Contentful Paint) to ensure performance is below our target (currently 2500ms).
LCP Dashboard for Secure owned pages
The Sec engineering teams do not provide support directly to customers. Instead engineers collaborate with our Customer Support Engineers via the process on the Sec Sub-department support project.
Look to see if issue you are working on has existing test coverage. These are the tests likely to fail
If you are working around code that contains a selector like data-qa-selector="<name>", then there is likely to be an existing E2E test. Tests can be found by searching our E2E tests in Secure.
Ping the DRI for quality assigned to Secure. You can find the person on the team page. If they are unavailable, then #quality on slack or the triage DRI dependent on severity.
In addition to our group retrospectives, we hold a Sec Section level retrospective each month. The goal of the section wide retrospective is to review topics that bubbled-up from our group/team retrospectives. Additionally, we identify themes that could be discussed synchronously. We use this doc to facilitate the section retrospective.
The DRI for Section-wide retrospectives will be the Senior Engineering Manager. The SEM will find a volunteer if it is needed on specific milestones. The following tasks are executed each milestone:
Meaning that the proposed work requires knowledge or impacts multiple groups ↩