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.
The following people are permanent members of the Create:Code Review FE Team:
| Person | Role |
|---|---|
| André Luís | Frontend Engineering Manager, Create:Source Code, Create:Code Review, Delivery & Scalability |
| Phil Hughes | Staff Fullstack Engineer, Create:Code Review |
| Stanislav Lashmanov | Senior Frontend Engineer, Create:Code Review |
| Thomas Randolph | Senior Frontend Engineer, Create:Code Review |
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Kai Armstrong | Senior Product Manager, Create:Code Review |
| Amy Qualls | Senior Technical Writer, Create (Source Code, Code Review), Enablement (Database) |
| Sincheol (David) Kim | Senior Backend Engineer, Create:Code Review |
| Darva Satcher | Director of Engineering, Create |
| Gary Holtz | Backend Engineer, Create:Code Review |
| Jay McCure | Senior Software Engineer in Test, Create:Code Review |
| Kerri Miller | Staff Backend Engineer, Create:Code Review |
| Marc Shaw | Senior Backend Engineer, Create:Code Review |
| Matt Nohr | Backend Engineering Manager, Create:Code Creation, Create:Code Review |
| Patrick Bajao | Senior Backend Engineer, Create:Code Review |
| Shekhar Patnaik | Principal Fullstack Engineer, Create |
| Derek Ferguson | Group Manager, Product Management, Create |
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
See the work section of the main Code Review page.
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.
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.
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.
