---
layout: handbook-page-toc
title: Front End Plan Team
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

## 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.

[Plan stage]: /stages-devops-lifecycle/plan/
[Markdown rendering]: https://docs.gitlab.com/ee/user/markdown.html
[portfolio management features]: /product/agile-portfolio-management/

## Team Members

<%= direct_team(role_regexp: /[,&] Plan/, manager_role: 'Frontend Engineering Manager, Plan') %>

## Stable Counterparts

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

<%= stable_counterparts(role_regexp: /[,&] (Plan(?!:)|Plan:Project Management|Plan:Portfolio Management & Plan:Certify)/, direct_manager_role: 'Frontend Engineering Manager, Plan') %>


### Hiring chart

This chart shows the progress we're making on hiring. Check out our
[jobs page](/jobs/) for current openings.

<%= hiring_chart(department: 'Plan FE Team') %>

## Groups

The Plan stage is split into three groups: Project Management, Portfolio
Management and Certify. Due to the current size of the frontend team, we have
not explicitly split the team yet. 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 |
|--------------------|----------------------|---------------|
| Fatih Acet | Kushal Pandya | Kushal Pandya |
| Simon Knox | Rajat Jain | Rajat Jain |
| Scott Stern | Florie Guibert | Florie Guibert |
| Coung Ngo | Axel García | Axel García |

## 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 CE]) 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 [#g_plan] on Slack.

[Plan stage page]: /handbook/product/categories/plan/
[backend team]: /handbook/engineering/development/dev/plan-team-planning-be/
[engineering workflow]: /handbook/engineering/workflow/
[GitLab CE]: https://gitlab.com/gitlab-org/gitlab-ce

### Capacity planning

In that we value [Velocity over Predictability], we prefer a lightweight system
of issue weighting to help with capacity planning. These weights are used for
capacity planning and the main focus is on making sure the overall sum of the
weights is within 10 of the average of the past three releases.

We encourage anyone to add a weight to an issue if it does not have one. We use
a similar [scale] to the Plan backend engineering team.

[Velocity over Predictability]: /handbook/engineering/#velocity-over-predictability
[scale]: /handbook/engineering/development/dev/plan-team-planning-be/#capacity-planning

### Picking something to work on

Groups in the Plan stage each have their own board which they work off of. Since
we are still a [single team on the frontend](#groups), we work off a higher
level [Plan stage board](https://gitlab.com/groups/gitlab-org/-/boards/1328658).
The left column of this board is a prioritized list of items scheduled for the
current release.

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

1. First filter by ~"frontend" and the group label of the speciality of the
engineer. Here, items in the ~"workflow::ready for development" column are ready
to be picked up. The priority is set top down in the list.
1. Remove the filter for group speciality label. Again, items in
~"workflow::ready for development" can be picked up.
1. 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.
1. 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.

## Useful links

* [Plan frontend board] - this shows work in the current release
* [#g_plan] in Slack
* [Recorded meetings][youtube]
* [Retrospectives][retros]

[Plan frontend board]: https://gitlab.com/groups/gitlab-org/-/boards/654688

[#g_plan]: https://gitlab.slack.com/archives/g_plan
[youtube]: https://www.youtube.com/playlist?list=PLFGfElNsQthaREiE1QwWQtqUv1LYPEuuj
[retros]: https://gitlab.com/gl-retrospectives/plan/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=retrospective