Plan:Knowledge Engineering Team

Plan:Knowledge team

The Plan:Knowledge team develops Knowledge Management categories:

• Wiki
• GitLab Pages
• Text Editors
• Markdown

Learn more on our direction page.

Team members

Name	Role
Vladimir Shushlin	Engineering Manager, Plan:Knowledge
Alisa Frunza	Backend Engineer
Brett Walker	Senior Backend Engineer, Plan:Knowledge
Himanshu Kapoor	Senior Frontend Engineer, Plan:Knowledge
Janis Altherr	Senior Fullstack Engineer, Plan:Knowledge
Naman Jagdish Gala	Senior Backend Engineer, Plan:Knowledge
Piotr Skorupa	Backend Engineer, Plan:Knowledge

Stable counterparts

Name	Role
Alex Fracazo	Senior Product Designer, Plan:Knowledge
Costel Maxim	Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Melissa Ushakov	Group Manager, Product Management, Plan
John Hope	Senior Manager, Engineering, Plan
Natalia Tepluhina	Principal Engineer, Plan
Ottilia Westerlund	Security Engineer, Fulfillment (Fulfillment Platform, Subscription Management), Security Risk Management (Security Policies, Threat Insights), Monitor (Observability), Plan (Product Planning), AI-powered (Duo Chat, Duo Workflow, AI Framework, AI model validation, Custom models)
Matthew Macfarlane	Product Manager, Plan Stage, Knowledge Group

Hiring chart

Check out our jobs page for current openings.

How we work

Picking something to work on

The build board shows upcoming release work. The ~“workflow::ready for development” column is ordered by priority.

Engineering Manager adds the following labels at the start of the milestone:

It’s OK not to take the top item if you are not confident you can solve it, but please post in #g_knowledge.

Capacity

Estimating effort

When estimating the effort involved in upcoming work, we use the same approach and numerical scale as other groups in the Plan stage.

When weighting an issue for a milestone, we use a lightweight, relative estimation approach, recognizing that tasks often take longer than you think. These weights are primarily used for capacity planning, ensuring that the total estimated effort aligns with each group’s capacity for a milestone.

Key Principles

• Relative Estimation: We focus on the relative complexity and effort required for each issue rather than precise time estimates.
• Aggregate Focus: The sum of all issue weights should be reasonable for the milestone, even if individual issues vary in actual time taken.
• Flexibility: It’s acceptable for an issue to take more or less time than its weight suggests. Variations are expected due to differences in individual expertise and familiarity with the work.

Weight Definitions

Initial Planning: During milestone planning, tasks can be estimated up to a weight of 5 if necessary. However, as the milestone approaches and the team moves closer to starting implementation, any task with a weight larger than 3 should be decomposed into smaller, more manageable issues or tasks with lower weights.

Why This Approach: Allowing larger weights early on provides flexibility in high-level planning. Breaking down tasks closer to implementation ensures better clarity, reduces risk, and facilitates more accurate tracking and execution.

We assess the available capacity for a milestone by reviewing recent milestones and upcoming team availability. This ensures that our milestone planning remains realistic and achievable based on the collective effort estimated through these weights.

Typically, 3-month rolling average is a good indicator of the team’s capacity. Knowledge is a new team and determining capacity will be difficult at the beginning without clear historical data.

The PM and EM will work to fit ~Deliverable issues into no more than 75% of the team’s capacity and allocate the rest to ~Stretch issues.

Refinement

Engineering manager reviews ~"workflow::refinement" issues on every team meeting. Issues with the highest priority are assigned to individual engineers, who are responsible for moving issue to ~workflow::ready for development.

Engineers can put the following template into the issue description:

### Implementation plan

<!--
Ready for development means replying yes to the following questions:

- Is this issue sufficiently small enough? If not, break it into smaller issues
- Is it assigned to the correct domain (e.g. frontend, backend)? If not, break it into two issues for the respective domains
– Is the issue clear and easy to understand? If not, try asking further clarification questions and update the description once they are received

If more than 2 MRs are needed, consider adding a table like the following to the description (e.g. under `Implementation plan`).
-->

| Description | MR |
|-|-|
| MR 1 | |
| MR 2 | |
| Documentation | |

**Reasoning:**

<!--
Add some initial thoughts on how you might break down this issue. A bulleted list is fine.

This will likely require the code changes similar to the following:

- replace the hex driver with a sonic screwdriver
- rewrite backups to magnetic tape
- send up semaphore flags to warn others

Links to previous examples. Discussions on prior art. Notice examples of the simplicity/complexity in the proposed designs.
-->

/label ~"workflow::ready for development"

/label ~"frontend-weight::X"

/label ~"backend-weight::X"

/weight X

Weighing bugs

Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug can be accurately estimated. Additionally, velocity is used to measure the amount of new product output, and bug fixes are typically fixes on a feature that has been tracked and had a weight attached to it previously.

Because of this, we do not weigh bugs during ~“workflow::planning breakdown”. If an engineer picks up a bug and determines that there will be a significant level of effort in fixing it (for example, a large migration is needed), we then will want to prioritize it against feature deliverables. Ping the product manager with this information so they can determine when the work should be scheduled.

Refinement

Board-Walk (weekly)

Team-members meet to walk the Build Board once a week. 25 minutes are allocated for this sync call but it may be completed much more quickly than that. The EM is DRI and attendance is optional except for PM. It is recorded and shared in the #g_knowledge Slack channel. The recording will be made public only if no security or other confidential issues are discussed. The agenda is available internally and all team-members are encouraged to contribute updates and questions.

The purpose of this meeting is to:

• Update on the status of work in progress
• Identify blockers and risk
• Reprioritize
• Ask for help

DRIs should keep issues up to date with workflow labels and health status on an ongoing basis rather than waiting for this meeting.

Planning Meeting (monthly)

A planning meeting is held once per month, prior to the start of the milestone. The Product Manager is the DRI for scheduling it.

Attendance is optional for engineers but participation is not. The meeting will have an agenda and will be recorded. It may involve any or all of the following:

• Setting priorities and expectations.
• Estimating tasks.
• Breaking down and collaborating on scope.
• Clarifying requirements.
• Estimating capacity and carry-over.

As much as possible these tasks should be completed asynchronously, reducing the work required in the meeting. The purpose of the meeting is to start the upcoming milestone in the best possible shape for success.

Refinement sessions (ad-hoc)

Team-members are encouraged to propose refinement sync meetings for large issues and/or new features. The goal is to explore concerns and unknowns while sharing knowledge and gathering different perspectives on the problem.

A refinement meeting might have an agenda with topics like:

• Product requirements
• Technical challenges
• Technical alternatives
• How to iterate on the solution proposed

As an outcome, the meeting could produce a list of issues, with an estimated milestone, to iterate over.

Asynchronous-first

Most planning is done asynchronously. Some tools and processes are observed to make this more efficient.

Since issues can only have one milestone attached, the ~"Next Up" label is used to mark items for the upcoming milestone, regardless of whether they already have a milestone or not. PM and EM should remove this label from any issues prior to the start of planning, then add it to prospective issues and any expected to slip the current milestone during the planning process.

Using this label, it’s possible to easily analyze the upcoming milestone. The Planning Board mimics the Build Board but is scoped to this label instead of the current milestone. Use it to:

• View the current workflow state of all proposed issues.
• Plan capacity by totalling weight values for each list.
• Understand blocking relationships that may be resolvable before the milestone starts.

When the new milestone starts, the milestone can be added all issues with the ~"Next Up" label in a bulk action, and the label itself removed.

Workflow

Use of Labels

Proper labelling of issues helps with the classification, traceability and quantification of work the team can and is doing. Some labels are essential. The table below describes these and gives the reason why.

Async update

We aim to make the status of each epic and issue clear and easily accessible for our teammates, counterparts and users.

The primary source of truth for this information is the ~workflow::* label and the health status.

But when the issue spends more than in a week in the ~"workflow::in dev", ~"workflow::in review" or ~"workflow::verification" DRI also leaves an async update on the it using the “Knowledge - async update” comment template.

To keep the track of what issues may need an async update, you can use the following GLQL query:

```glql
---
display: list
fields: title, labels("workflow::*"), healthStatus
---
group = "gitlab-org" and assignee = currentUser() and label in ("workflow::in dev", "workflow::in review", "workflow::verification") and opened = true
```

Priority labels

We use ~Knowledge::P1/P2/P3 labels to indicate issue priority within the ~workflow::* steps and milestones.

• Product Manager is the DRI for these labels, but everybody on the team can assign/adjust them.
• Before the milestone starts, the PM and EM will review the priorities for all issues included in that milestone. It’s expected that: - 40% of issues have ~Knowledge::P1 - 30% of issues have ~Knowledge::P2 - 30% of issues have ~Knowledge::P3, and those issues can’t be ~Deliverable’s
• We also use these labels outside of milestones to keep track of our highest priorities.
• If anyone on the team wants an issue to be scheduled, they should add the appropriate priority label.
• We don’t have a dedicated P4 label, not having ~Knowledge::P* label is equivalent to ~Knowledge::P4.
• When issues are moved to another ~workflow::* stage, it’s likely that the priority will be changed.
• ~Knowledge::P* labels are completely different from ~priority::* labels that are used only for bugs.

Collaboration with other teams

To avoid rework we reach out to other teams early when working on the following domains:

Dashboards

Detailed metrics are available on the Engineering Metrics page.

Application Performance

Additional dashboards are available in Grafana that show application performance of parts of the application for which the team is responsible.

• Stage-Group Dashboard (including 28-day Error Budget)
• Error Budget Detail

Useful links

• Plan:Knowledge - Apply a milestone filter to see work in the current release
• #s_plan in Slack
• Recorded meetings
• Retrospectives
• Group Conversations (archive; group conversations now happen at a the section level)

View page source - Edit this page - please contribute.