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. For information on our product direction, visit the Category Direction - Source Code Management page.

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	Senior Frontend Engineer, Create:Source Code

Stable Counterparts

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

Name	Role
Brendan Lynch	Technical Writer, 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
Hunter Stewart	Senior Backend Engineer,Create:Source Code Backend
Jerry Seto	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
Kerri Miller	Staff Backend Engineer, Create:Source Code Backend
Marie-Christine Babin	Senior Product Manager, Create:Source Code
Pranav Jain	Associate Backend Engineer, 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.

Issue refinement

1. Once we have validated the problem, product, UX, and engineering will collaborate to propose a solution and decide on what’s technically feasible. The proposed solution may be shared with users to validate it solves the problem.
   1. Issues that require design work are marked with UX and workflow::ready for design.
   2. Issues in the design process are marked with workflow::design.
   3. Once designs are ready and the proposed solution is viable then the label workflow::planning breakdown will be applied.
2. Once we have confirmed the proposed solution is viable, we will move to break it down as much as possible. When issues are ready for this stage, PM will mark issues with workflow::refinement label to signal next step.
3. We have 1 regularly scheduled “Per Milestone” backlong refinement session. During then, we review the issues in the backlog together. Each engineer also proposes issues they believe are valuable for the team to work on as deliverables candidates.
   1. If an issue needs further refinement, we’ll distribute tasks labeled workflow::refinement among engineers.
   2. If an issue does not need further refinement, the label workflow::ready for development will be applied.
   3. If the team believes the issue should be worked on in the next milestone, the milestone will be set. Otherwise, the label scm-backlog will be applied and the issue will be placed in %backlog milestone.
4. EM will create a refinement issue (example) and distribute tasks labeled workflow::refinement among engineers.
5. Engineers or EM will follow the checklist for assigned issues, work with PM, UX, and other engineering counterparts where necessary to address questions and concerns.
6. If the planned implementation of the issue can be further broken down, the engineer/EM will work with the PM to reduce scope and create new issues until this is the case (either PM or engineer/EM can create new work items).
7. Once an issue is fully refined, engineers or EM will add an appropriate weight and label it as workflow::ready for development. These issues can then be added to the milestone.

Diagram

flowchart TD
    A[Problem Validation] --> B[Solution Collaboration]
    B --> C{Design Required?}
    C -->|Yes| D[Mark with UX and workflow::ready for design]
    D --> E[Issue in design process with workflow::design]
    E --> F[Designs ready]
    C -->|No| F
    F --> G[Mark with workflow::planning breakdown]
    G --> H[Solution Viable?]
    H -->|Yes| I[Mark with workflow::refinement]
    I --> J[Per Milestone Backlog Refinement Session]
    J --> K{Needs Further Refinement?}
    K -->|Yes| L[EM creates refinement issue]
    L --> M[Engineers assigned to refinement tasks]
    M --> N[Engineers follow checklist]
    N --> O{Can be broken down further?}
    O -->|Yes| P[Reduce scope and create new issues]
    P --> N
    O -->|No| Q[Add weight and mark workflow::ready for development]
    K -->|No| Q
    Q --> R{Work in next milestone?}
    R -->|Yes| S[Set milestone]
    R -->|No| T[Apply scm-backlog label and place in %backlog milestone]

    %% Adding colors to different stages
    style A fill:#d4f1f9,stroke:#05a,stroke-width:2px
    style B fill:#d4f1f9,stroke:#05a,stroke-width:2px
    style C fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style D fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style E fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style F fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style G fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style H fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style I fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style J fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style K fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style L fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style M fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style N fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style O fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style P fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style Q fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style R fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style S fill:#f8cecc,stroke:#b85450,stroke-width:2px
    style T fill:#f8cecc,stroke:#b85450,stroke-width:2px

Issue Refinement Checklist

For issues that need refinement, the Engineer/EM should add a comment using this template and complete all checklist items.

If you cannot finish any of these steps, ping EM/PM.

# Issue Refinement Checklist

## Problem verification
- [ ] Issue label is ~"workflow::refinement"
- [ ] Issue title clearly describes the feature or change
- [ ] Issue description defines requirements and expectations
- [ ] Required permissions and access levels defined
- [ ] Desktop design is defined (if needed)
- [ ] Mobile design is defined (if needed)

## Implementation plan

- [ ] A comment with an implementation plan is created
- [ ] Implementation plan includes accessibility specification (if needed)
- [ ] Implementation plan includes proposal for ~"analytics instrumentation" (if needed)
- [ ] A separate issue is opened for adding ~"analytics instrumentation" and linked to this issue (if needed)
- [ ] Implementation plan includes ~documentation changes (if needed)
- [ ] Implementation plan includes proposal for adding feature tests (if needed)
- [ ] Implementation plan includes feature tests (if needed)
- [ ] Issue is small and doesn't need to be broken down

## Final steps
- [ ] This issue has a weight
- [ ] There are no blockers
- [ ] Issue has ~"workflow::ready for development" label

Bug Refinement Checklist

For bug reports that need refinement, the Engineer/EM should add a comment using this template and complete all checklist items.

# Bug Refinement Checklist

## Bug verification
- [ ] Issue label is ~"workflow::refinement"
- [ ] Issue label is ~"type::bug"
- [ ] Issue title clearly describes the bug
- [ ] Steps to reproduce are documented
- [ ] Issue is still reproducible
- [ ] Severity labels are defined
- [ ] Related logs or error messages are attached

## Technical analysis
- [ ] Root cause has been identified or hypothesized
- [ ] Affected components/services are identified
- [ ] Potential side effects of the fix are considered

## Implementation plan
- [ ] A comment with an implementation plan is created
- [ ] Fix scope is contained and doesn't require larger refactoring
- [ ] Test cases to verify the fix are defined

## Final steps
- [ ] This issue has a weight
- [ ] There are no blockers
- [ ] Issue has ~"workflow::ready for development" label

Implementation plan

Add a comment to the issue under refinement using the provided template.

### Implementation Plan

**1. Approach**

<!-- Provide a high-level description of the implementation idea -->

**2. Dependencies**

- [ ] Requires ~backend
- [ ] Requires ~frontend
- [ ] Requires ~database
- [ ] Requires ~documentation
- [ ] Requires ~UX work
- [ ] External service dependencies identified
- [ ] Requires ~API changes

**3. Implementation Steps**

<!-- Provide step by step description of what needs to be done -->

- Task 1
- Task 2
- Task 3

**4. Edge Cases**

<!-- Does the implementation cover all scenarios (success, failure) -->

- Success scenarios:
  - Case 1
  - Case 2

- Error scenarios:
  - Case 1
  - Case 2

- Edge conditions:
  - Case 1
  - Case 2


@engineer_username please review this implementation plan.
<!--
Pick a peer engineer following this criteria:
1. is a subject matter expert.
2. might have some familiarity with the topic. or
3. ask on slack who'd be available to review this plan before the due date of the issue
-->

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 Source Code group conduct asynchronous standups in the #g_create_source_code_standup channel every Monday.

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:

• What did you do outside of work since we last spoke?
• What are you planning to do today?
• 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.

If any additional information is needed from design, a list of requests will be issued to the designer after the meeting.

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.