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	Frontend Engineering Manager, Create:Source Code, Create:Code Review, Delivery & Scalability
Ash McKenzie	Staff Backend Engineer, Create:Source Code
Gavin Hinfey	Backend Engineer, Create:Source Code
Senior Backend Engineer	Senior Backend Engineer, Create:Source Code
Javiera Tapia	Backend Engineer, Create:Source Code
Jacques Erasmus	Senior Frontend Engineer, Create:Source Code
Joe Woodward	Senior Backend Engineer, Create:Source Code
Nataliia Radina	Frontend Engineer, Create:Source Code
Paulina Sedlak-Jakubowska	Frontend Engineer, Create:Source Code
Robert May	Senior Backend Engineer, Create:Source Code
Vasilii Iakliushin	Staff Backend Engineer, Create:Source Code, Systems:Gitaly API

Stable Counterparts

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

Name	Role
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
Derek Ferguson	Group Manager, Product Management, Create
Darva Satcher	Director of Engineering, Create
Igor Drozdov	Staff Backend Engineer, Create:Source Code, Systems:Gitaly API
Patrick Cyiza	Backend Engineer, Create:Source Code
Kai Armstrong	Principal Product Manager, Create:Code Review
Marcin Sędłak-Jakubowski	Senior Technical Writer, Plan (Project Management, Product Planning), Create (Source Code)
Marie-Christine Babin	Senior Product Manager, Create:Source Code
Shekhar Patnaik	Principal Fullstack Engineer, Create

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.

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.

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.

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.