The Organization 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:
Security issues
As properly showing hierarchy to users - which projects/groups they have access to - is our responsibility, we need to solve any security issue connected to that. We closely watch new security 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.
Scale
Because the hierarchy in GitLab, specifically on GitLab.com, can get complicated - and querying memberships can be an expensive operation, we should always thinking about the scalability of our solutions to make sure we are offering our users optimal experience when using our product.
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:
When working with our Support counterparts on customer issues, you are enouraged to provide as much detail as possible, both on the root cause of the problem and on the proposed technical solution. This is in accordance with our values, and this would benefit everyone in the long term because the next time a similar problem happens, our Support counterparts would be able to pattern match and figure out the root cause of the problem on their own. Here are some examples where the Engineer working with customer issues has provides good context on the root cause and the proposed solution:
#eng-week-in-review weekly#team-member-updates, #sd_dev_engineering, #vp-development, #ceo, #ctoPrior to release kickoff, the Engineering Manager needs to provide the total teams capacity in weight to the Product Manager. Each engineer on the team starts at a baseline weight of capability and is further reduced in capacity based on planned time off including holidays, company events such as Family and Friends day or a team day, on-call shifts, and so on. The end result is a weight estimate that each engineer is reasonably capable of accomplishing, added up amongst all ~"frontend" engineers and ~"backend" engineers separately, and added to the planning issue.
In order to more accurately understand what work can be planned for a release without exhausting our team members, we provide weight estimations after a preliminary, surface-level investigation. We recognize that estimations may not be precise! However this is key in ensuring that the capacity planning estimate above is not overwhelming to the team.
There are two important factors to consider for an issue weight: volume of work, and complexity.
The volume of work refers to the expected size of the change to the code base. A small change may involve a single change to a single file, while a large change could involve many changes across many files and areas of our code base.
Complexity in practice can be split into two considerations: how well the problem is understood, and the level of problem solving difficulty we expect to encounter.
A well understood and thus low complexity issue is to rename a method that is only called in one location. A poorly understood and thus high complexity issue is to rename a method that exists several layers deep and is called directly and indirectly in many different locations.
A low level of problem solving and thus low complexity issue is to order a membership query by access level. A high level of problem solving and thus high complexity issue is to integrate shared groups into a membership query.
The factors to consider can be summarized like so:
When estimating development work, please assign an issue the appropriate weight:
| Weight | Description (Engineering) |
|---|---|
| 1 | The simplest possible change. We are confident there will be no side effects. Negligible complexity. |
| 2 | A simple change (minimal code changes), where we understand all of the requirements. Some small uncertainties exist but we are confident of a solution. |
| 3 | A simple change, but the code footprint is bigger (e.g. lots of different files, or tests affected). There are uncertainties that we will need to work through. |
| 5 or higher | A more complex change that will impact multiple areas of the codebase. There may also be some refactoring involved. Requirements are poorly understood and you feel there are multiple important gaps in understanding. We will need to break this issue into smaller pieces before we can begin a merge request. |
We do not provide estimates greater than 5 without encouraging iteration, splitting the issue, collaborating on what a lower effort MVC might be, or working with our counterparts to understand the unknowns.
We plan in monthly cycles in accordance with our Product Development Timeline. While meeting this timeline is flexible, a typical planning cycle is suggested to look like:
direction.workflow:ready for development).
Between when the planning issue is created and when it gets finalized, everyone can contribute. All group members can propose issues to be considered for the upcoming release here. Examples of some things to consider when proposing items would be:
In general, engineering will follow this workflow label cycle for any ~Deliverable issues in the release:
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 and is complete, issues should be closed at this stageIssues that were labeles with ~milestone::p1 are the priorities for this milestone. They should be worked immediately during the milestone to ensure they are finished and deployed on time.
With 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.
Organization works on components of the application that have a far-reaching impact and many groups will be involved in migratig features over, the following process is needed:
Different pieces of training are often part of OKRs. To facilitate tracking those training and in the spirit of dogfooding our product, following participation in the training is tracked through the issue in Manage:Organization project.
At the beginning of the quarter, when OKR is due, the Engineering Manager is responsible for starting the issue. The issue should consist of a link to the training, an explanation of why the OKR was set and checkboxes for all the team members. Also, the due date needs to be set. Then all of the team members are mentioned in the issue for awareness.
Based on the checkboxes, the Engineering Manager updates the OKR in GitLab.
Career development for each engineering team member is described here.
Topic of career development is discussed between team member and engineering manager during their 1:1 meetings. Current goals, pace of development, a method of tracking goals, and frequency of check-ins are agreed between team members and their EM.
If a team member is working towards promotion within the next 12 months, it is recommended they track progress against their desired job description.
Team members are encouraged to track their achievements using Value Based Tracker.
Although we have a bias for asynchronous communication, synchronous meetings are necessary and should adhere to our communication guidelines. We are focusing on 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.
Meetings that are not 1:1s or covering confidential topics should be added to the Manage Shared calendar.
All meetings should have an agenda prepared at least 12 hours in advance. If this is not the case, you are not obligated to attend the meeting. Consider meetings canceled if they do not have an agenda by the start time of the meeting.
The following people are permanent members of the group:
| Person | Role |
|---|---|
| Fiona Neill | Senior Technical Writer, Fulfilment, Manage:Organization, Growth:Product Intelligence |
| Rohit Shambhuni | Senior Security Engineer, Application Security, Manage (Authentication and Authorization, Organization), SaaS Platforms (Scalability) |
For the cross-functional prioritization framework, in the short term, we are aiming to spend at least 50% of our capacity on feature work. The Organization group needs to be especially cautious with scheduling maintenance work and bug fixes. Since we oversee 214 endpoints, the chance that any user is impacted by a performance issue covered by our group is particularly high.
(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.
gitlab-org/manage