Manage Foundations Team

Maintained by:

About

We're the Foundations team and we are part of the Manage Stage.

This page is the shared team page for our Engineers, Product Designers, and Product Manager!

We hope it's a good entry point to learn more about who we are and what we do.

Team Members

Person	Role
Christen Dybenko	Senior Product Manager, Manage:Foundations
Sam Beckham	Engineering Manager, Manage:Foundations
Lukas Eipert	Senior Frontend Engineer, Manage:Foundations
Mark Florian	Staff Frontend Engineer, Manage:Foundations
Olena HK.	Senior Frontend Engineer, Manage:Foundations
Paul Gascou-Vaillancourt	Senior Frontend Engineer, Manage:Foundations
Scott de Jonge	Senior Frontend Engineer, Manage:Foundations
Thomas Hutterer	Senior Backend Engineer, Manage:Foundations

What do we work on?

Design System (Direction Page)

We are currently focused on integrating our design system, Pajamas, into the GitLab product.

We perform an accessibility audit on each component and make sure that our implementations in GitLab UI and GitLab match the desired user experience, guidelines, and visual design.

The Foundations team does the preparation work necessary so that other Engineers at GitLab and members from the wider community can help out with these efforts.

Do you want to contribute? Please see this issue for a good entry point.
Navigation & Settings (Direction Page)
GitLab Docs (Direction Page)

How do we work?

Communication

To get in touch with the Foundations team, it's best to create an issue in the relevant project (typically GitLab, Pajamas or GitLab UI) and add the ~"group::foundations" label, along with any other appropriate labels. Then, feel free to ping the relevant Product Manager and/or Engineering Manager.

For more urgent items or if you are unsure who to ask, ping @gitlab-org/manage/foundations or use #g_manage_foundations on Slack (internal only).

Capacity Planning

In general, we use the standard GitLab Product Development Flow. Here are some specific workflows we use:

Planning Breakdown workflow

Any issues that need an engineer to give them a weight are given the label Next Up by the PM
1. Criteria:
  - PM needs a weight and collaboration with engineering to size the effort
  - Often these will be labelled workflow::planning breakdown but could appear in other workflows if weighting is a topic of conversation
  - Issue has been checked by Design and has a proposal for moving forward
  - Ideally one or more releases ahead of development
On a defined interval (twice a release), engineers review unweighted Next Up issues:
Engineering: Write comments and collaborate with Design and Product to understand and get a sense of the complexity of the effort
Engineering: Set the weight in the issue based on the agreed-upon weighting
Engineering: Notify the PM that it has been weighted in a comment
PM: Label the issue workflow::scheduling or workflow::ready for development, and set its milestone to a specific release, or Backlog

How we weight issues

We use a Fibonacci scale and in terms of complexity, we use this table from Practical Fibonacci.

Foundations weighting scale:

0 - No effort is required, or there is some effort required, but there is no business value delivered, so no Points are accumulated for doing the work. An example is a desired behavioral change deriving from the Scrum Retrospective.
1 - Extra small. Developers feel they understand most requirements and consider it relatively easy, probably the smallest item in the Sprint and mostly likely completed in one day.
2 - Small. A little bit of thought, effort, or problem-solving is required, but the Developers have done this a lot, so they have confidence in the requirements. Or, it sounds extra small, but they want to hedge their bet just a bit.
3 - Average. Developers have done this a lot; they know what needs to be done. There may be a few extra steps, but that's it. It's doubtful that they will need to research anything.
5 - Large. This is complex work, or the Developers don't do this very often. Most Developers will need assistance from someone else on the team. This is probably one of the largest items that can be completed within a Sprint.
8 - Extra Large. This is going to take some time and research and probably more than one developer to complete within two weeks. In addition, Developers need to make several assumptions that increase the risk and could affect getting it Done.
13 - Warning! This is a complex piece of work with a lot of unknowns and requires multiple assumptions to size. It is too much to complete in one Sprint. Instead, split this into multiple items that can be completed independently.
21 - Hazard! A "21" or "34" reflects too much complexity to be done within one Sprint. It will need to be refined more. The large size also indicates more risk, assumptions, and dependencies involved to complete this item.
? - Danger! As a Developer, we don't want to do this work the way it is currently written. It is very complex and cannot be completed in the timeframe of an iteration or Sprint. Perhaps the requirements are so fuzzy that it's rife with danger.

Employee Development

Here are some resources team members can use for employee development:

Metrics

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Team onboarding

UX Onboarding Checklist