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 of the DevOps lifecycle.
Team Members
The following people are permanent members of the Create:Code Review 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 |
 Phil Hughes
|
Staff Fullstack Engineer, Create:Code Review |
 Paulina Sedlak-Jakubowska
|
Frontend Engineer, Create:Source Code |
 Robert May
|
Senior Backend Engineer, Create:Source Code |
 Stanislav Lashmanov
|
Senior Frontend Engineer, Create:Code Review |
 Thomas Randolph
|
Senior Frontend Engineer, Create:Code Review |
 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 |
|---|---|
 Amy Qualls
|
Senior Technical Writer, Create (Editor Extensions, Code Review) |
 Sincheol (David) Kim
|
Senior Backend Engineer, Create:Code Review |
 Derek Ferguson
|
Group Manager, Product Management, Create |
 Darva Satcher
|
Director of Engineering, Create |
 Gary Holtz
|
Backend Engineer, Create:Code Review |
 Kai Armstrong
|
Principal Product Manager, Create:Code Review |
 Kerri Miller
|
Staff Backend Engineer, Create:Code Review |
 Marc Shaw
|
Senior Backend Engineer, Create:Code Review |
 Patrick Bajao
|
Senior Backend Engineer, Create:Code Review |
 Shekhar Patnaik
|
Principal Fullstack Engineer, Create |
Iteration
We held an Iteration Retrospective in April 2020 in order to review past work and discuss how we could improve iteration for upcoming efforts.
Some overal conclusions/improvements
- Despite having improved the splitting of Merge Requests, we still tend to keep one issue spawning multiple Merge Requests.
- We’ll be more strict about splitting the issues in foreseeable iteration steps upon scheduling/assignment
- We must keep in mind the overhead in review times when splitting up related backstage work. (more info)
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.
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.
Kickoff
On the first week of every milestone, we have a sync-call with every IC in which they take turns at presenting their plan for their Deliverables for the new milestone.
This usually happens at the first Thursday of the milestone (at least 5 days into it) at 3PM UTC.
Relevant issues
- Merge Request Architecture Walkthrough (as of December 2020) — an outline of the current status of the entire Merge Request page Frontend components, including the answers to:
- Component Name
- Technology
- State Management (Technology + shared with others?)
- Responsible Team
- Shared with other Team?
- Other comments
c8544f4a)
