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.
(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.
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 #protect | 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.
Our team monitors LCP (Largest Contentful Paint) to ensure performance is below our target (currently 2500ms).
LCP Dashboard for Secure owned pages
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 ↩