The Create:Source Code FE team is responsible for all frontend aspects of the product categories that fall under the Source Code group of the Create stage of the DevOps lifecycle.
The following people are permanent members of the Create:Source Code FE Team:
| Person | Role |
|---|---|
| André Luís | Frontend Engineering Manager, Create:Source Code, Create:Code Review, Delivery & Scalability |
| Jacques Erasmus | Senior Frontend Engineer, Create:Source Code |
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Torsten Linz | Senior Product Manager, Create:Source Code |
| Amy Qualls | Senior Technical Writer, Create (Source Code, Code Review, Editor), Enablement (Database) |
| Evan Read | Senior Technical Writer, Create (Gitaly), Manage (Authentication and Authorization, Compliance, Import) |
| Costel Maxim | Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code |
| Darva Satcher | Director of Engineering, Create |
| Igor Drozdov | Senior Backend Engineer, Create:Source Code |
| Joe Woodward | Senior Backend Engineer, Create:Source Code |
| Mark Lapierre | Senior Software Engineer in Test, Create:Source Code |
| Robert May | Senior Backend Engineer, Create:Source Code |
| Sean Carroll | Backend Engineering Manager, Create:Source Code |
| Vasilii Iakliushin | Senior Backend Engineer, Create:Source Code |
| Sarah Waldner | 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
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.
To ensure we are living our iteration value consistenly, we should be intentional in asking ourselves: "is this in the smallest possible form it could be?". To that end engineers, designer, EMs, and PM should work together to find the smallest feature set that delivers value to users and can be used to elicit feedback for future iterations. Once a feasible issue plan comes together. Let's consider the following steps for best results:
workflow::refinement label to signal next step.workflow::needs issue review.Note: if an issue receives a weight > 3 after this process, it may indicate the IC may not have a full idea of what is needed and further research is needed.
As stated in our direction, we must place special emphasis on our convention over configuration principle. As the feature set within Create:Source Code grows, it may feel natural to solve problems with configuration. To ensure this is not the case, we must intentionally challenge MVC and new feature issues to check for this. Let's consider the following steps for best results:
Once issues have been labeled as workflow::needs issue review PM will share the proposal with either a peer or their manager as well as engineering (EM or IC) and product designer.
Peers in product and engineering who review the issue should look for opportunities to eliminate configuration where possible. If opportunities are identified, the issue is moved back to workflow::refinement.
If PM and peers are satisfied with the proposal and it follows our convention over configuration principle as much as possible, those who reviewed the issue indicate their agreement with the proposal (with either 👍 or a comment in the issue). Finally, PM or EM will label issue workflow:: ready for development.
Expanding on the concept of Middle of milestone check-in:
The way we try to grasp how well we are doing according to the scheduled and committed set of Deliverables is simply trying to calculate the level of completeness of all of them.
We do this by tallying up:
We then compile a small report like this:
Done + Verification: 1 w1 2.27% In review: 6 w15 34.09% In dev: 6 w20 45.45% Unstarted: 3 w8 18.18% Progress: 47.73% Conclusion: ...
Progress is calculated with:
(100% * 2.27) + (80% * 34.09) + (40% * 45.45) + (0% * 18.18)
In the conclusion we write an interpretation of what this means and what we'll be doing to correct course, if needed.
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. |
| 5: Medium - unschedulable | Features that are poorly understood and not very straightforward to implement. Involves a good deal of work with a wide scope. Bugs that are poorly understood and don't have a suggested solution, yet. Includes some hard-to-test code or require deep refactoring work. Must be turned into multiple issues for scheduling; consider first doing a timeboxed spike to investigate further, remove uncertainty and aid the splitting into smaller issues. |
| 8: Large - unschedulable | Extremely large features. Must be turned into an epic with several iterative steps becoming issues |
| 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. |
| 4: Medium | Features that are well understood and relatively straightforward but still need a good deal of work. Bugs that are relatively poorly understood and may not yet have a suggested solution. Includes some tasks that might be hard to test. |
| 5: Large | Features that are well understood, but known to be hard. Bugs that are very poorly understood, and will not have a suggested solution. |
| 8: Very large | Very large features that usually require the dedication of a FE for the full length of the milestone. — Very rare, usually split into smaller issues |
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.
The groups in the Create stage conduct asynchronous standups in the #g_create_standup channel 3 times a week, on Monday, Wednesday, and Friday.
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:
For more background, see the Async standup feedback issue on the Create stage issue tracker.
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.
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.
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, on the 18th.
During this call, we also do a quick Retrospective review going through the highlights of the discussions in the asynchronous issue mentioned above.