The Frontend Plan team works on the frontend part of GitLab for the Plan stage. Among other things, this means working on GitLab's issue tracker, portfolio management features, and Markdown rendering.
For more details about the vision for this area of the product, see the Plan stage page.
|Donald Cook||Frontend Engineering Manager, Plan|
|Kushal Pandya||Senior Frontend Engineer, Plan:Product Planning|
|Simon Knox||Senior Frontend Engineer, Plan:Project Management|
|Natalia Tepluhina||Staff Frontend Engineer, Plan:Project Management|
|Rajat Jain||Frontend Engineer, Plan:Product Planning|
|Scott Stern||Frontend Engineer, Plan:Project Management|
|Coung Ngo||Senior Frontend Engineer, Plan:Project Management|
|Florie Guibert||Senior Frontend Engineer, Plan:Product Planning|
|Eulyeon K.||Frontend Engineer, Plan:Product Planning|
The following members of other functional teams are our stable counterparts:
|Gabe Weaver||Senior Product Manager, Plan:Project Management|
|Holly Reynolds||Senior Product Designer, Plan:Project Management|
|Marcin Sędłak-Jakubowski||Technical Writer, Plan, Manage (Optimize)|
|Brett Walker||Senior Backend Engineer, Plan:Project Management|
|Heinrich Lee Yu||Staff Backend Engineer, Plan:Project Management|
|Alexandru Croitor||Senior Backend Engineer, Plan:Project Management|
|Désirée Chevalier||Software Engineer in Test, Plan:Project Management|
|Costel Maxim||Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code|
|Jake Lear||Backend Engineering Manager, Plan:Project Management|
|Mario Celi||Backend Engineer, Plan:Project Management|
|Melissa Ushakov||Group Manager, Product Management, Plan|
The Plan stage is split into three groups: Project Management, Portfolio Management and Certify. For the sake of planning, frontend engineers have specialities within groups. However, due to shifting workloads per group, frontend engineers on the Plan stage are expected to be able to take on work outside of their speciality.
|Project Management||Portfolio Management||Certify|
|Simon Knox||Kushal Pandya||Kushal Pandya|
|Scott Stern||Rajat Jain||Rajat Jain|
|Coung Ngo||Florie Guibert||Florie Guibert|
You can see how we work as a stage at the Plan stage page.
Like the backend team, we use the standard GitLab engineering workflow. To get in touch with the Plan frontend team, it's best to create an issue in the relevant project (typically GitLab) and add the ~"devops::plan" and ~"frontend" labels, along with any other appropriate labels. Then, feel free to ping the relevant Product Manager and/or Frontend Engineering Manager as listed above.
For more urgent items, feel free to also share the issue in #s_plan on Slack.
We use a lightweight system of issue weighting to help with capacity planning, with the knowledge that things take longer than you think. These weights are used for capacity planning and the main focus is on making sure the overall sum of the weights is reasonable.
It's OK if an issue takes longer than the weight indicates. The weights are intended to be used in aggregate, and what takes one person a day might take another person a week, depending on their level of background knowledge about the issue. That's explicitly OK and expected.
These weights we use are:
|1||Trivial, does not need any testing|
|2||Small, needs some testing but nothing involved|
|3||Medium, will take some time and collaboration|
|4||Substantial, will take significant time and collaboration to finish|
|5||Large, will take a major portion of the milestone to finish|
Anything larger than 5 should be broken down if possible.
We look at recent releases and upcoming availability to determine the weight available for a release.
We're using a lightweight asynchronous planning model to determine weights of upcoming work. On the 4th of every month, the Frontend Engineering Manager (FEM) will create a planning issue for each group. There, a comment will be created with a short summary of the work needed for every issue that needs a weight (mostly ~frontend ~"Next up"). The ask is that every frontend engineer within the group adds an emoji reaction to what they think the weight should be. Discussion can occur over the next few days, but the idea is that consensus is reached by the 9th, at which point the FEM will add the weight to the actual issue. If there are differences in weights, the highest weight will be used.
Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug be accurately estimated. Additionally, velocity is used to measure the amount of new product output, and bug fixes are typically fixes on a feature that has been tracked and had a weight attached to it previously.
Because of this, we do not weigh bugs during ~"workflow::planning breakdown". If an engineer picks up a bug and determines that there will be a significant level of effort in fixing it (for example, a large migration is needed, or we need to switch state management to Vuex on the frontend), we then will want to prioritize it against feature deliverables. Ping the product manager with this information so they can determine when the work should be scheduled.
When deciding the next issue to take, frontend engineers should prioritize by the following:
Opencolumn. There should not be a point where there are not issues in the previous steps, but if it happens, feel free to look through the
Opencolumn and determine what is needed to move them to a more advanced step.
It's OK to not take the top item if you are not confident you can solve it, but please add a comment in the issue if that's the case, as this probably means the issue should be better specified.
When you pick something to work on, please assign the issue to yourself and add the ~"workflow::In dev" label.
When an issue comes through that is both ~"severity::1" and ~"priority::1", our SLO requires that it be looked at right away. Other items being worked on should be postponed in favor of any investigations or work for the high severity/priority issue. When postponing an issue, engineers should leave a comment on the issue with a link to the high severity item that is being prioritized instead. Leaving a comment will help with communication with the cross-functional team and for historical tracking. The exception to this is if another ~"severity::1"/~"priority::1" issue is currently being worked on by an engineer. If this is the case, the engineer should make others on the team aware of the new issue on Slack but then keep working on the initial issue.
By the time something is picked up, it should already have a weight associated with it. After closer investigation into what is actually involved in implementing the feature, it's possible to discover that the effort is much more complex. At this point, engineers are encouraged to update the weight, pinging the PM of the group so they are able to reprioritize if necessary.
Our Code Review Guidelines state that we default to assigning reviews to team members with domain expertise. A domain can be an area of the codebase that a team is responsible for, so frontend engineers within the Plan stage are considered domain experts for Issues, Epics, and all other areas of Plan.
When determining who to assign an MR to, this process should be followed:
As a team, we are working towards using week-long iterations. In agile terminology, this would equate to a week-long sprint. Our week ends during the Plan Stage weekly meeting (Wednesdays), where we will demo the goals that we accomplished during the week.