Plan:Knowledge Engineering Team

Plan:Knowledge team

The Plan:Knowledge team works on both the backend and frontend parts of GitLab’s Knowledge categories in the Plan stage.

For more details about the vision for this area of the product, see the Plan stage page.

Team members

Name	Role
Vladimir Shushlin	Engineering Manager (Interim), Plan:Knowledge
Himanshu Kapoor	Senior Frontend Engineer, Plan:Knowledge
Janis Altherr	Fullstack Engineer, Plan:Knowledge
Kassio Borges	Staff Backend Engineer , Plan:Knowledge
Naman Jagdish Gala	Senior Backend Engineer, Plan:Knowledge

Stable counterparts

Name	Role
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), Govern (Security Policies, Threat Insights), Monitor (Observability), Plan (Product Planning), AI-powered (Duo Chat, 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.

Planning

Picking something to work on

The team build board always shows work targeting the upcoming release, organized into workflow columns. The ~“workflow::ready for development” column is ordered by priority.

The following labels are added by the Engineering Manager at the start of the milestone and communicate the priority of the issue to stakeholders:

• The ~Deliverable label indicates that we have committed to customers that we will deliver this item in the current milestone.
• The ~Stretch label indicates that we have not committed to deliver the item but will attempt to make progress on it.

It’s OK not to take the top item if you are not confident you can solve it, but please post in #s_plan or #g_knowledge if that’s the case, as this probably means the issue should be better specified.

Capacity

We use a lightweight system of issue weighting to help with capacity planning, with the knowledge that things take longer than you think. These weights are used for capacity planning and the main focus is on making sure the overall sum of the weights is reasonable.

It’s OK if an issue takes longer than the weight indicates. The weights are intended to be used in aggregate, and what takes one person a day might take another person a week, depending on their level of background knowledge about the issue. That’s explicitly OK and expected.

These weights we use are:

Weight	Meaning
1	Trivial, does not need any testing
2	Small, needs some testing but nothing involved
3	Medium, will take some time and collaboration
4	Substantial, will take significant time and collaboration to finish
5	Large, will take a major portion of the milestone to finish

Anything larger than 5 should be broken down if possible.

We look at recent releases and upcoming availability to determine the weight available for a release.

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.

Planning Rotation

As a small team with distinct roles this team does not run an allocated planning rotation, as other Plan teams do.

Instead, all members of the team get involved in estimation during the planning process. We rely on the person with the most context around a task to give an accurate estimate. This should start on the 5th and be completed by the 12th of the month.

Weighing bugs

Estimating bugs is inherently difficult. The majority of the effort in fixing bugs is finding the cause, and then a bug 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, or we need to switch state management to Vuex on the frontend), 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.

Label	Use	Handbook Guidance	DRI
~workflow::*	Communicates the current workflow state of an issue. Important for understanding progress & quantifying risk during the course of a milestone.	Updating Issues Throughout Development	Engineer
~type::*	Communicates the type of work being done. Used to quantify and report the split of work to roles inside and outside GitLab.	Work Type Classification
~Deliverable/~Stretch	~Deliverable communicates to customers and stakeholders that we intend to deliver an issue within the assigned milestone. ~Stretch indicates that it might be started during the milestone but is not expected to complete.	Release Scoping Labels	Engineering Manager

Collaboration

Close collaboration outside of Knowledge group or Engineering discipline is often required. To mitigate the effect of Conway’s Law, where siloes in the organization are reflected in the design of the product, and to promote efficiency, here are some guidelines for engaging with counterparts across the organization.

Pipeline Authoring

Changes to the pages product often require changes to pipeline configuration. Help is available from the Pipeline Authoring team, who are directly responsible for this functionality.

It’s encouraged to engage with this team when spiking and planning new work for the pages product. Reference your spike or planning issue when reaching out to #g_pipeline-authoring for any requested guidance. You can use the @verify-pa-backend Slack group to specifically ping the backend team. Engaging with the team at the earliest ensures they’re able to set aside capacity to help with minimal disruption to their own roadmap.

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)