Design System Engineering Team

About

We’re the Design System team and we are part of the Foundations Stage.

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

Team Members

Name	Role
James Rushford	Frontend Engineer, Foundations:Design System
Staff Frontend Engineer	Staff Frontend Engineer, Foundations:Design System
Sam Beckham	Engineering Manager, Foundations:Design System, Foundations:Personal Productivity
Scott de Jonge	Senior Frontend Engineer, Foundations:Design System
Vanessa Otto	Senior Frontend Engineer, Foundations:Design System

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 Design System team does the preparation work necessary so that other Engineers at GitLab and members from the wider community can help out with these efforts.

Communication

To get in touch with the Design System team, it’s best to create an issue in the relevant project (typically GitLab, Pajamas or GitLab UI) and add the ~"group::design system" label, along with any other appropriate labels. Then, ping the relevant Product Manager and/or Engineering Manager (see team members).

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

How do we work?

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

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 - Little to no effort is required Something that would be quicker to do than it was to create the issue.
• 1 - Extra small. The engineers feel they understand most requirements and consider it relatively easy, probably the smallest item in the milestone and mostly likely completed in one day.
• 2 - Small. A little bit of thought, effort, or problem-solving is required, but the engineers have confidence in the requirements.
• 3 - Average. Engineers have done this a lot; they know what needs to be done. There may be a few extra steps, but that’s it.
• 5 - Large. This is complex work, or the engineers don’t do this very often. Most engineers will need assistance from someone else on the team. This is probably one of the largest items that can be completed within a milestone.
• 8 - Extra Large. This is going to take some time and research and probably more than one engineer to complete within the milestone. At this size, we should be looking at how we can split this into smaller issues/tasks.
• 13+ - Ludicrous! This issue is far too complex, large, or under-defined. Anything with a weight of this size should go back to ~workflow::refinement to be refined and split into more manageable chunks.

Fifth week of focus

With our release schedule our milestones are either four or five weeks long. To make planning more predictable and encourage experimentation, we treat the fifth week of any longer milestone as a week of focus. During this week, our engineers are encouraged to work on a project of their own choosing. It could be starting a proof-of-concept, learning a new skill, burning down neglected issues, writing a blog post, or something else. The only requirement is that it contributes to the team, or their personal development.

We trialled this as an OKR in December 2023 and it was a great success.

The upcoming five week milestones are:

• Aug 09, 2024 - Sep 13, 2024
• Oct 11, 2024 - Nov 14, 2024
• Jan 10, 2025 - Feb 13, 2025
• Apr 11, 2025 - May 15, 2025

Metrics

View page source - Edit this page - please contribute.