Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Front End Plan Team

On this page

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

Person Role
Donald Cook Frontend Engineering Manager, Plan
Fatih Acet Senior Frontend Engineer, Plan
Kushal Pandya Senior Frontend Engineer, Plan & Geo
Winnie Hellmann Senior Frontend Engineer, Plan and Intern Backend Engineer, Plan
Rajat Jain Frontend Engineer, Plan
Scott Stern Frontend Engineer, Plan
Coung Ngo Frontend Engineer, Plan

Stable Counterparts

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

Person Role
Felipe Artur Backend Engineer, Plan:Portfolio Management & Plan:Certify
Annabel Dunstone Gray Product Designer, Plan
Sean McGivern Engineering Manager, Plan:Project Management
Jarka Košanová Senior Backend Engineer, Plan:Portfolio Management & Plan:Certify
Brett Walker Senior Backend Engineer, Plan:Project Management
Jan Provaznik Senior Backend Engineer, Plan:Portfolio Management & Plan:Certify
Mario de la Ossa Backend Engineer, Plan:Project Management
Amarbayar Amarsanaa Senior Site Reliability Engineer, Create, Plan, Monitor
Patrick Derichs Backend Engineer, Plan:Project Management
Walmyr Lima e Silva Filho Senior Test Automation Engineer, Plan
Heinrich Lee Yu Backend Engineer, Plan:Project Management
Alexandru Croitor Backend Engineer, Plan:Project Management
Michal Wasilewski Site Reliability Engineer, Create & Plan
Charlie Ablett Senior Backend Engineer, Plan:Portfolio Management & Plan:Certify
Eugenia Grieff Backend Engineer, Plan:Project Management
Holly Reynolds Senior Product Designer, Plan
Alexis Ginsberg Senior Product Designer, Plan
Gabe Weaver Senior Product Manager, Plan:Project Management
John Hope Engineering Manager, Plan:Portfolio Management & Plan:Certify
Russell Dickenson Senior Technical Writer, Plan

Hiring chart

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


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.

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.

Picking something to work on

The Plan frontend board always shows work in the current release. The left column is a prioritized list of items scheduled for the current release that do not have a frontend engineer already assigned to.

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

  1. Items in the Open column that have one of the following labels: ~"workflow::In dev", ~"workflow::In review" or ~"workflow::verification". This means that backend has already started work and we want to have frontend work done as much in parallel as possible.
  2. Items in the ~"workflow::ready for development" column. This is a prioritized list of items that are deemed ready for the frontend work to start. All items in this list should be UX ready.
  3. Items in the Open column that do not have a ~"workflow::" or ~"validation::" label.

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.