The Authentication and Authorization group is a central piece to the GitLab product! While many groups focus on single area - like the repository view, or the merge request view, this group has a much broader impact on many areas. Because of this, there are some key topics that we keep on our mind more than other groups might:
Bypassing permissions and authentication mechanisms are, by nature, common security targets. We closely watch new security vulnerability issues and schedule them as quickly as possible based on their due date. For planning security issues we use the (filtered) milestone planning issue board. We expect all team members to be able to resolve security issues following the security release process.
Because this group works on components of the application that have a far-reaching impact, we take these extra steps in order to reduce our risk of a production incident:
CODEOWNERS feature of GitLab.You are encouraged to work as closely as needed with stable counterparts. We include quality engineering and application security counterparts prior to a release kickoff and as-needed during code reviews or issue concerns.
Quality engineering is included in our workflow via the Quad Planning Process and is responsible for bug prioritization during release planning. They are also the DRI when it comes to adding new end-to-end tests, though anyone can contribute. Here are some examples of when to engage with your counterpart:
Application Security will be involved in our security issue workflow and should participate in other feature, bug, or maintenance issues before they are scheduled if we need to notate any concerns or potential risks that we should be aware of. Here are some examples of engaging with your counterpart:
#eng-week-in-review weekly#team-member-updates, #sd_dev_engineering, #vp-development, #ceo, #ctoWe plan in monthly cycles in accordance with our Product Development Timeline. Our typical planning cycle includes:
workflow:ready for development.
Items that did not make the ~Deliverable list for a milestone should be moved to the backlog or reconsidered for a future release. The Product Manager facilitates this process.
Before work can begin on an issue, we should estimate it first after a preliminary investigation. If the scope of work of a given issue touches several disciplines (docs, design, frontend, backend, etc.) and involves significant complexity across them, consider creating separate issues for each discipline (see an example).
After the PM creates a planning issue for the next release, the quad will gather a prioritized list of issues that should be considered. The EM will then create a "breakdown" issue with a checklist of issues that need to be estimated (example). All Engineers from the group should be assigned to that issue and participate in weighting or breaking down the list.
When estimating development work, please add the appropriate weight to the issue:
| Weight | Description (Engineering) |
|---|---|
| 1 | The simplest possible change. We are confident there will be no side effects. |
| 2 | A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | A simple change, but the code footprint is bigger (e.g. lots of different files, or tests affected). The requirements are clear. |
| 5 | A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way. We should challenge ourselves to break this issue into smaller pieces. |
| 8 | A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. These issues will often need further investigation or discovery before being ~workflow::ready for development and we will likely benefit from multiple, smaller issues. |
We do not provide estimates greater than 8. If an issue is bigger, we will split the issue or reduce its scope.
If the issue has weight 5 or less, the Engineer adding an estimate should also put the ~"workflow::ready for development" label on it.
If the issue has weight more than 5 (or 5 but it seems it might be split into multiple issues) the Engineer will suggest how to split it. If the Engineer is clear about the splitting they should proactively split the issue themself, put estimations on the child issues and leave a comment on the parent one. If it results to multiple issues, creating an epic should be considered.
When an Engineer is done with their estimates they should ask another team member to review their weight. This makes it harder to miss a significant aspect of an issue. If the first Engineer is confident (eg. has deep expertise in the problem or the issue is trivial) they can skip this step.
Our purpose of estimation is to confirm that we
We do not expect that during estimation, implementation details are scrutinized, all blockers are caught, or prove that the proposed solution is the right one. This all happens during development. In development, we, sometimes, reshape the issue, change its solution, or even postpone it. We are proud of doing it.
With keeping the above in mind, some areas to consider when estimating are:
Engineers should assign issues to themselves based on the current release and ~Deliverable label. We use the following workflow label cycle on our issues:
workflow::ready for development - work is ready to begin, but has not yet startedworkflow::in dev - we are looking at the issue, and are either actively investigating, have begun development, or have a draft merge request openworkflow::in review - a merge request has been submitted and reviews have been requestedworkflow::verification - the work has merged, and needs to be verified by the assigneeworkflow::complete - the work has been verified by the assignee, assignee will close the issue and apply labelworkflow::awaiting security release - (security MRs only) the work is complete, just pending backports.Development should not begin on an issue before it's been estimated and given a weight.
Issues with the workflow::verification or workflow::awaiting security release labels are, for the purposes of release planning, the same as closed issues, because the dev work is complete.
We have many labels that can be applied to an issue or merge request. Besides the issue workflow labels above, here are the minimum basic labels to apply to issues and merge requests:
type::feature, type::bug, or type::maintenance)devops::manage)group::authentication and authorization)frontend, backend, database, documentation)security if the issue is related to application security, and breaking change if this work is considered a breaking changeWith the combination of our capacity planning (EM) and estimation (IC) processes above, engineers should have free time to work on ~"Stuff that should just work" or other topics that interest them. If an unscheduled issue should really be prioritized, bring it up in a planning issue or ask your manager to reduce your capacity further.
We have cross-functional prioritization aligned with our prioritization framework. The engineering manager will prioritize type::maintenance issues, the product manager will prioritize type::feature issues, and the software engineer in test will prioritize type::bug issues. From there, we are able to select a ratio of the top issues to be planned for the release by using our cross-functional issue board. Our target ratio is to plan 60% features, 30% bugs, and 10% maintenance per release. Security issues do not count towards these ratios, but instead take away from the total capacity. The data below helps us understand our overall cross-functional status.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (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 create a monthly issue that is assigned to all counterparts. The issue has to be created manually by an Engineering Manager, but we have an issue template in the Authentication and Authorization discussion repo.
You can read more about this process on the handbook page.
Although we try to plan as described above, we understand that there is always a risk to the ideal ratios due to unexpected high priority security, infradev, and escalation issues.
Although we have a bias for asynchronous communication, synchronous meetings are necessary and should adhere to our communication guidelines. Some regular meetings that take place in Manage are:
| Frequency | Meeting | DRI | Attendees | Topics |
|---|---|---|---|---|
| Weekly | Group-level meeting (internal only) | Product Manager | PM/EM/UX/SET, optionally engineers | Discuss current or upcoming roadmap topics, bring epics/issues up for attention, provide a current status of priority initiatives |
For one-off, topic specific meetings, please always consider recording these calls and sharing them (or taking notes in a publicly available document).
Agenda documents and recordings can be placed in the shared Google drive (internal only) as a single source of truth.
All meetings and 1-1's should have an agenda prepared in advance. If this is not the case, you are not obligated to attend the meeting. Confirm if the meeting should be canceled if there is not an agenda by the start time of the meeting.
Auth group members who are part of the Authentication and Authorization group can be @ mentioned on GitLab with @gitlab-org/manage/authentication-and-authorization.
The following people are permanent members of the group:
| Person | Role |
|---|---|
| Hannah Sutor | Senior Product Manager, Manage:Authentication and Authorization |
| Daniel Mora | Senior Product Designer, Manage:Authentication and Authorization |
| Adil Farrukh | Manager, Fullstack Engineering, Manage:Authentication and Authorization |
| Bogdan Denkovych | Backend Engineer, Manage:Authentication and Authorization |
| Drew Blessing | Backend Engineer, Manage:Authentication and Authorization |
| Eduardo Sanz-Garcia | Senior Frontend Engineer, Manage:Authentication and Authorization |
| Imre Farkas | Staff Backend Engineer, Manage:Authentication and Authorization |
| Jessie Young | Staff Backend Engineer, Manage:Authentication and Authorization |
| Sanad Liaquat | Staff Software Engineer in Test, Manage:Authentication and Authorization |
| Smriti Garg | Senior Backend Engineer, Manage:Authentication and Authorization |
| Aboobacker MK | Senior Backend Engineer, Manage:Authentication and Authorization |
gitlab-org/manage