Front End Plan Team

1. You are here:
2. Engineering
3. Development Department
4. Dev Sub-department
5. Front End Plan Team

Maintained by:

On this page

• Frontend Plan Team
• Team Members
• Stable Counterparts
• Groups
• Work
  • Capacity Planning
  • Frontend weighting
    • Weighing bugs
  • Picking something to work on
    • High Severity Issues
  • Unknown complexities
  • Code Reviews
  • Iterations
• Useful links

Frontend Plan Team

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.

Team Members

Stable Counterparts

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

Groups

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.

Work

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.

Capacity Planning

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:

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.

Frontend weighting

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.

Weighing bugs

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.

Picking something to work on

The Plan FE stage works off of two boards, depending on the group: Project Management and Product Planning

When deciding the next issue to take, frontend engineers should prioritize by the following:

1. First filter by ~"frontend". Here, items in the ~"workflow::ready for development" column are ready to be picked up. The priority is set top down in the list.
2. Items in the ~"workflow::planning breakdown" column. This is a prioritized list of items that may not be fully ready to start development on, but should be close.
3. Items in the Open column. 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 Open column 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.

High Severity Issues

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.

Unknown complexities

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.

Code Reviews

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:

1. Initial review should be done by a frontend engineer from the Plan stage.
2. Maintainer review should be assigned to a maintainer that has domain expertise, not limited to the Plan stage. This is because we only have one maintainer within the team.
3. If a maintainer with domain expertise is not available, assign to the recommended maintainer from reviewer roulette.

Exceptions

• If an MR is not for a Plan feature or backstage item (global frontend work, assisting another team) review can and should go to an engineer on another team
• If an MR touches code that Plan uses, but that is also used by another team, one review (either reviewer or maintainer) should be done by the other team. An example is with changes to notes, where responsibility is shared between Create:Source Code and Plan.

Iterations

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.

Useful links

• Plan frontend board - this shows work in the current release
• #s_plan in Slack
• Recorded meetings
• Retrospectives