Create:Source Code FE Team

Common Links

Team Vision

A central piece in GitLab users’ experience, innovating and keeping the experience delightful for all product categories that fall under the Source Code group of the Create stage of the DevOps lifecycle.

Team Mission

Support all our counterparts with frontend engineering expertise, including implementation, tech debt management, and timely frontend insights in discovery phases.

Commonly Monitored Issue Lists

• Source Code + Frontend issues
• Milestone Planning Issues
• Triage reports
• Feature flag reports
• OKRs (confidential)

Team Members

The following people are permanent members of the Create:Source Code FE Team:

Name	Role
André Luís	Senior Engineering Manager, Create:Source Code, Create:Code Review
Jacques Erasmus	Senior Frontend Engineer, Create:Source Code
Chaoyue Zhao	Frontend Engineer, Create:Source Code
Paulina Sedlak-Jakubowska	Frontend Engineer, Create:Source Code

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Name	Role
Ash McKenzie	Staff Backend Engineer, Create:Source Code
Costel Maxim	Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Emma Park	Backend Engineer, Create:Source Code Backend
Fred Reinink	Backend Engineer, Create:Source Code Backend
Gavin Hinfey	Backend Engineer, Create:Source Code
Senior Backend Engineer	Senior Backend Engineer,Create:Source Code Backend
Senior Backend Engineer	Senior Backend Engineer, Create:Source Code
Javiera Tapia	Backend Engineer, Create:Source Code
Jay McCure	Senior Software Engineer in Test, Dev:Create
Patrick Cyiza	Backend Engineer, Create:Source Code
Joe Woodward	Senior Backend Engineer, Create:Source Code
Marcin Sędłak-Jakubowski	Senior Technical Writer, Plan (Project Management, Product Planning, Knowledge), Create (Source Code)
Marie-Christine Babin	Senior Product Manager, Create:Source Code
Olaoluwa Oluro	Senior Backend Engineer, Create:Source Code
Vasilii Iakliushin	Staff Backend Engineer, Create:Source Code, Systems:Gitaly API

Core Responsibilities

• Collaborate with Product and UX on ideation, refinement and scheduling of relevant work
• Provide Frontend support for feature development, bug fixes, under the Source Code Management Product Category
• Address bug reports and regressions
• Identify and prepare maintenance work to improve developer experience
• Collaborate on efforts across the Frontend department

Projects

Active Project Table

Archived Project Table

Engineering Onboarding

Work

In general, we use the standard GitLab engineering workflow. To get in touch with the Create:Source Code FE team, it’s best to create an issue in the relevant project (typically GitLab) and add the ~"group::source code" and ~frontend labels, along with any other appropriate labels (~devops::create, ~section::dev). Then, feel free to ping the relevant Product Manager and/or Engineering Manager as listed above.

For more urgent items, feel free to use #g_create_source_code or #g_create_source_code_fe on Slack.

Take a look at the features we support per category here.

Code Reviewing

To prevent the creation of knowledge silos and also receiving input from people outside of the team, we follow these principles:

• Not all Merge Requests need to go through the team
• However, Merge Requests that seem important for the team to be aware, let’s ensure one of the reviews go through a team member

MRs important to the team: these are changes to logic in our apps or meaningful component changes. Sequential work in a larger epic is also beneficial to have oversight from peers within the team. But bottom line, use your best judgement.

Conventional Comments

When giving Merge Request review feedback, we aim to provide additional context by utilizing the conventional: comments standard.

Capacity planning

We use weights to forecast the complexity of each given issue aimed at being scheduled into a given milestone. These weights help us ensure that the amount of scheduled work in a cycle is reasonable, both for the team as a whole and for each individual. The “weight budget” for a given cycle is determined based on the team’s recent output, as well as the upcoming availability of each engineer.

Before each milestone, the Engineering Manager takes a pass and sets weights on all issues currently aimed at the next milestone by Product and triaging processes. On occasion, specific ICs can be brought to review the assigned weight. This is aimed at helping the ICs stay focused on Deliverables while working in the last week of the active milestone.

We understand weights are mere forecasts and we accept the uncertainty that comes with this.

Weights

These are the broad definition for each of the weights values. We don’t use a Fibonacci-based progression but we do try to split up large issues as we understand they are by definition less accurate predictions.

When issues are Frontend only, we use the Weight feature of Issues.

When issues are both Frontend and Backend we use specific labels to support both weights in the same issue: ~frontend-weight::1 through ~frontend-weight::13. Only weights between 1-3 can be scheduled into a milestone. Higher ones need to be broken down.

Note: Since milestone 13.10, we switched to using a fibonacci based scale. The reason behind this is how hard it’s been to distinguish between issues of weight 3 and 4 or weight 4 and 5. Fibonacci allows for a clearer distinction as weights increase.

Anything above weight 3 is unschedulable.

Those are either large amounts of work or have too many unknowns. In that case, opt to break it down into multiple issues right away or open an epic to start a discussion in order to create the multiple steps.

Also consider adding the label: ~"workflow::planning breakdown".

Why?

This hard limit helps the team embody the Iteration value.

Example of Weights

w1: Blame view - “authored” line leaking into next row

w2: CSV rendering hangs viewer for large files

w3: Edit Branch Rules: Update selector to support searching Deploy Keys

Source code context

When weighing issues that have to do with Blob view, make sure to take into account the duality of Blob. We use both HAML and Vue to render the Blob view. There is a high chance that you will implement your changes for both. Majority of file types uses Vue architecture. Though there are some file types that need backend syntax highlighter and therefore are rendered with HAML. The same will happen, when an error occurs.

This duality will be resolved with the Link to package managers when viewing dependency files with highlight.js.

Spike issues

The primary purpose of a spike issue is to understand the feasibility of the request and perform a study, research, analysis, or PoC rather than producing a shippable product. The outcome of the spike is to finalize the design of a solution and further plan and break down the work into multiple issues that are weighted depending on their complexity.

To recognize and improve the readability of these issues when they become deliverables, we should:

• Use the label ~"spike" and the [SPIKE] identifier at the beginning of the spike issue title.
• Link the created issues (outcome of the spike) to the spike issue. The labels are copied from the original issue.
• Close the spike issue with a summary of the next steps we will perform to achieve the goal of the spike.

When dealing with a feature request that needs further investigation, we can open a spike issue that assesses the research and is linked to the original issue.

Exceptions

There are some exceptions to the rule. For example, when the spike issue is highly discussed and visible to customers, closing the original issue if scheduled (using the ~"Deliverable" label) as a spike will send the wrong signals to customers. That is when we keep the issue open and remove the ~"spike" label and the [SPIKE] identifier from the spike issue title. For more details see this example.

Workflow labels

The easiest way for engineering managers, product managers, and other stakeholders to get a high-level overview of the status of all issues in the current milestone, or all issues assigned to specific person, is through the Development issue board, which has columns for each of the workflow labels described on Engineering Workflow handbook page under Updating Issues Throughout Development.

As owners of the issues assigned to them, engineers are expected to keep the workflow labels on their issues up to date, either by manually assigning the new label, or by dragging the issue from one column on the board to the next.

Async standup

The groups in the Create stage conduct asynchronous standups in the #g_create_standup channel 3 times a week, on Monday, Wednesday, and Friday.

The goal is to support the members of these groups in connecting at a personal level, not to check in on people’s progress or replace any existing processes to communicate status or ask for help, and the questions are written with that in mind:

1. What did you do outside of work since we last spoke?
2. What are you planning to do today?
3. Is anything blocking your progress or productivity?

For more background, see the Async standup feedback issue on the Create stage issue tracker.

Retrospectives

We have 1 regularly scheduled “Per Milestone” retrospective, and can have ad-hoc “Per Feature” retrospectives more focused at analyzing a specific case, usually looking into the Iteration approach.

Per Milestone

The Create: Source Code group conducts monthly retrospectives in GitLab issues. These include

the backend team, plus any people from frontend, UX, and PM who have worked with that team during the release being retrospected.

These are confidential during the initial discussion, then made public in time for each month’s GitLab retrospective. For more information, see team retrospectives.

Retrospective Coordinator

For each retrospective we assign a retrospective coordinator whose responsibilities include:

• Invite team members to provide asynchronous feedback
• Provide updates on action points from previous retrospective
• Capture action points for the current retrospective
• Ensure a retrospective coordinator is assigned for the next retrospective

Milestone Kickoff & Retrospective review

At the start of each milestone we have a synchronous Kickoff session where every IC take turns at presenting their plan for their Deliverables for the new milestone.

This happens at least 2 working days after all Deliverables are assigned, which happens on the first day of the milestone.

During this call, we also do a quick Retrospective review going through the highlights of the discussions in the asynchronous issue mentioned above.

Other related pages

Issues

• April 2020: Frontend: Iteration Retrospective (Source Code)

View page source - Edit this page - please contribute.