Personal Productivity Engineering Team

The Personal Productivity Engineering team is responsible for work relating to cross-stage features such as navigation, settings, and notifications.

About

We’re the Personal Productivity 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
Lukas EipertLukas Eipert Staff Frontend Engineer, Foundations:Personal Productivity
Paul Gascou-VaillancourtPaul Gascou-Vaillancourt Senior Frontend Engineer, Foundations:Personal Productivity
Sam BeckhamSam Beckham Engineering Manager, Foundations:Design System, Foundations:Personal Productivity
Thomas HuttererThomas Hutterer Senior Fullstack Engineer, Foundations:Personal Productivity

What do we work on?

Communication

To get in touch with the Personal Productivity team, it’s best to create an issue in the relevant project (typically GitLab) and add the ~"group::personal productivity" 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/personal-productivity or use #g_personal-productivity 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

Last modified August 13, 2024: Moves foundations pages up to a stage (19828853)
View page source - Edit this page - please contribute. Creative Commons License