Create:Source Code FE Team
Common Links
Category | Handle |
---|---|
GitLab Team Handle | Not available |
Slack Channel | #g_create_source-code-review-fe |
Slack Handle | Not available |
Team Boards | Current Milestone |
Issue Tracker | group::source code + frontend in gitlab-org/gitlab |
Sentry dashboard | Errors in the last 7 days |
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 |
---|---|
![]() |
Senior Engineering Manager, Create:Source Code, Create:Code Review |
![]() |
Senior Frontend Engineer, Create:Source Code |
![]() |
Frontend Engineer, Create:Source Code |
![]() |
Senior Frontend Engineer, Create:Source Code |
Stable Counterparts
The following members of other functional teams are our stable counterparts:
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
Start Date | Project | Description | Tech Lead |
---|---|---|---|
2023-09 | New Diffs (Epic) | A project to deliver a reusable and performant way of rendering diffs across GitLab | — |
2024-10 | Directory and File Page Improvements | A project to improve user experience of header area for directory and file pages | — |
Archived Project Table
Start Date | End Date | Project | Description | Tech Lead |
---|---|---|---|---|
2023 | put on hold | Blame info in Blob page | Improve usability of repository by rendering blame information in blob page | — |
2023 | 2024 | Branch Rules - Edit | Allow editing the branch rule details in one place | — |
2022-09 | 2023-04 | Branch Rules - Overview | Place all settings pertaining to branch rules in one place - overview only | — |
2021 | 2022 | Refactor Repository browser into 1 vue app | Render the blob page within the Repository frontend app for smoother experience | — |
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
- 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.
- Issues that require design work are marked with
UX
andworkflow::ready for design
. - Issues in the design process are marked with
workflow::design
. - Once designs are ready and the proposed solution is viable then the label
workflow::planning breakdown
will be applied.
- Issues that require design work are marked with
- 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. - 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.
- If an issue needs further refinement, we’ll distribute tasks labeled
workflow::refinement
among engineers. - If an issue does not need further refinement, the label
workflow::ready for development
will be applied. - 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.
- If an issue needs further refinement, we’ll distribute tasks labeled
- EM will create a refinement issue (example) and distribute tasks labeled
workflow::refinement
among engineers. - 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.
- 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).
- 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.
Weight | Description | |
---|---|---|
1: Trivial | The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required. | |
2: Small | The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. | |
3: Medium | Features that are well understood and relatively straightforward. Bugs that are relatively poorly understood and may not yet have a suggested solution. |
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)
8a4a60ac
)