Create:Code Review FE Team

The Create:Code Review FE team is responsible for all frontend aspects of the product categories that fall under the Code Review group of the Create stage.

Common Links

Category	Handle
GitLab Team Handle	@code-review-fe
Slack Channel	`#g_create_source-code-review-fe`
Slack Handle	`@code_review_fe`
Team Boards	`Current Milestone`
Issue Tracker	`group::code review` + `frontend` in `gitlab-org`

Team Vision

A central piece in GitLab users’ experience, innovating and keeping the experience delightful for all product categories that fall under the Code Review 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

Team Members

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

Name	Role
André Luís	Senior Engineering Manager, Create:Source Code, Create:Code Review
Phil Hughes	Staff Fullstack Engineer, Create:Code Review
Stanislav Lashmanov	Senior Frontend Engineer, Create:Code Review
Thomas Randolph	Senior Frontend Engineer, Create:Code Review

Stable Counterparts

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

Name	Role
Amy Qualls	Senior Technical Writer, Create (Editor Extensions, Code Review)
Sincheol (David) Kim	Senior Backend Engineer, Create:Code Review
Gary Holtz	Backend Engineer, Create:Code Review
Jay McCure	Senior Software Engineer in Test, Dev:Create
Kai Armstrong	Principal Product Manager, Create:Code Review
Kerri Miller	Staff Backend Engineer, Create:Code Review
Marc Shaw	Senior Backend Engineer, Create:Code Review
Michael Le	Senior Product Designer, Create:Code Review
Patrick Bajao	Staff Backend Engineer, Create:Code Review

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 Code Review Workflow 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
2019	Merge Requests Vue app	The frontend application that renders Merge Requests	—
2023-09	New Diffs (Epic)	A project to deliver a reusable and performant way of rendering diffs across GitLab	—

Engineering Onboarding

Work

See the work section of the main Code Review page.

Capacity planning

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.

Kickoff & Retrospective Review

On the first week of every milestone, we have a sync-call with every IC in which we review the comments shared in the async retrospective and after that each engineer takes turns at presenting their plan for their Deliverables for the new milestone.

This is scheduled ad-hoc within the first 5-10 days of the milestone.

Issues

2020 April: Frontend: Iteration Retrospective (Source Code)
2020 December: Merge Request Architecture Walkthrough

Last modified June 21, 2024: Add ReferenceLinks rule and fix errors (4ce6c9fb)

View page source - Edit this page - please contribute.