The responsibilities of this stage are described by the Manage product category. Manage is made up of multiple groups, each with their own categories and areas of responsibility.
The direction and strategy for Manage is documented on https://about.gitlab.com/direction/manage/. This page (and the category direction pages under the "Categories" header) is the single source of truth on where we're going and why.
Our priorities should follow overall guidance for Product. This should be reflected in the priority label for scheduled issues:
|Priority||Description||Probability of shipping in milestone|
|priority::1||Urgent: top priority for achieving in the given milestone. These issues are the most important goals for a release and should be worked on first; some may be time-critical or unblock dependencies.||~100%|
|priority::2||High: important issues that have significant positive impact to the business or technical debt. Important, but not time-critical or blocking others.||~75%|
|priority::3||Normal: incremental improvements to existing features. These are important iterations, but deemed non-critical.||~50%|
|priority::4||Low: stretch issues that are acceptable to postpone into a future release.||~25%|
We generally follow the Product Development Flow:
workflow::problem validation- needs clarity on the problem to solve
workflow::design- needs a clear proposal (and mockups for any visual aspects)
workflow::solution validation- needs refinement and acceptance from engineering
workflow::planning breakdown- needs a Weight estimate
workflow::scheduling- needs a milestone assignment
workflow::ready for development
workflow::verification- code is in production and pending verification by the DRI engineer
Generally speaking, issues are in one of two states:
Basecamp thinks about these stages in relation to the climb and descent of a hill.
While individual groups are free to use as many stages in the Product Development Flow workflow as they find useful, we should be somewhat prescriptive on how issues transition from discovery/refinement to implementation.
Backlog management is very challenging, but we try to do so with the use of labels and milestones.
The end goal is defined, where all direct stakeholders says “yes, this is ready for development”. Some issues get there quickly, some require a few passes back and forth to figure out.
The goal is for engineers to have buy-in and feel connected to the roadmap. By having engineering included earlier on, the process can be much more natural and smooth.
To do so, engineering managers, engineers, and designers can be pinged directly from the issue. We're currently exploring converting the Manage project into a group to be able to create groups to more easily ping group members.
To find issues that require refinement, please see the Next Up label and its purpose.
workflow::ready for development. By using this "Next Up" label in addition to workflow labels, we're able to see exactly what is being refined, e.g., problem, design, solution. This helps identify which issues are closer to being ready to schedule.
workflow::ready for development.
Directional milestones indicates a level of intent on whether or not an issue will be scheduled in short/mid/long-term segments. They are also indicative to the level of refinement and "shovel-readiness" of a given feature or topic, i.e., something planned 3+ releases for now is likely very unrefined and not likely to be scheduled or implemented any time soon.
It's important to remember that these are not hard commitments, and that this should be communicated with any stakeholders that may be sensitive to seeing an issue get scheduled into a milestone other than "Backlog".
For issues that are actually being committed to the short-term roadmap, please refer to Next Up
The utility in direction milestones is helping to segment the backlog and form a sort of roadmap. See the Import Roadmap board for an example.
Examples of directional milestones include:
Depending on the complexity of an issue, it may be necessary to break down or promote issues. A couple sample scenarios may be:
If none of the above applies, then the issue is probably fine as-is! It's likely then that the weight of this issue is quite low, e.g., 1-2.
As part of breaking down or promoting issues, you may find that there are a significant number of threads and comments in a given issue.
It's very important that we make sure any proposal details, pending action items, and decisions are easily visible to any stakeholder coming into an issue. Therefore, it's paramount that the issue description is kept up-to-date, or otherwise broken down or promoted as per the above section.
Before work can begin on an issue, we should estimate it first after a preliminary investigation.
If the scope of work of a given issue touches several disciplines (docs, design, frontend, backend, etc.) and involves significant complexity across them, consider creating separate issues for each discipline (see an example).
Issues without a weight should be assigned the "workflow::planning breakdown" label.
When estimating development work, please assign an issue an appropriate weight:
|1||The simplest possible change. We are confident there will be no side effects.|
|2||A simple change (minimal code changes), where we understand all of the requirements.|
|3||A simple change, but the code footprint is bigger (e.g. lots of different files, or tests affected). The requirements are clear.|
|5||A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way. We should challenge ourselves to break this issue in to smaller pieces.|
|8||A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. These issues will often need further investigation or discovery before being
|13||A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues.|
As part of estimation, if you feel the issue is in an appropriate state for an engineer to start working on it, please add the ~"workflow::ready for development" label. Alternatively, if there are still requirements to be defined or questions to be answered that you feel an engineer won't be able to easily resolve, please add the ~"workflow::blocked" label. Issues with the
workflow::blocked label will appear in their own column on our planning board, making it clear that they need further attention. When applying the
workflow::blocked label, please make sure to leave a comment and ping the DRI on the blocked issue and/or link the blocking issue to raise visibility.
For engineers, you may want to create an implementation approach when moving an issue out of
~workflow::planning breakdown. A proposed implementation approach isn't required to be followed, but is helpful to justify a recorded weight.
As the DRI for
workflow::planning breakdown, consider following the example below to signal the end of your watch and the issues preparedness to move into scheduling. While more straightforward issues that have already been broken down may use a shorter format, the plan should (at a minimum) always justify the "why" behind an estimation.
The following is an example of an implementation approach from https://gitlab.com/gitlab-org/gitlab/-/issues/247900#implementation-plan. It illustrates that the issue should likely be broken down into smaller sub-issues for each part of the work:
### Implementation approach ~database 1. Add new `merge_requests_author_approval` column to `namespace_settings` table (The final table is TBD) ~"feature flag" 1. Create new `group_merge_request_approvers_rules` flag for everything to live behind ~backend 1. Add new field to `ee/app/services/ee/groups/update_service.rb:117` 1. Update `ee/app/services/ee/namespace_settings/update_service.rb` to support more than just one setting 1. *(if feature flag enabled)* Update the `Projects::CreateService` and `Groups::CreateService` to update newly created projects and sub-groups with the main groups setting 1. *(if feature flag enabled)* Update the Groups API to show the settings value 1. Tests tests and more tests :muscle: ~frontend 1. *(if feature flag enabled)* Add new `Merge request approvals` section to Groups general settings 1. Create new Vue app to render the contents of the section 1. Create new setting and submission process to save the value 1. Tests tests and more tests :muscle:
Once an issue has been estimated, it can then be moved to
workflow::scheduling to be assigned a milestone before finally being
workflow::ready for development.
We plan in monthly cycles in accordance with our Product Development Timeline. While meeting this timeline is up to the discretion of individual groups, a typical planning cycle is suggested to look like:
workflow::planning breakdownlabel applied to make estimation easier and be marked for the coming release as
Deliverable. Issues of particular significance to our stage's strategy should be marked with
quad-planning::readylabel to all
featureissues and assigns them to the SET counterpart for the group.
workflow:ready for development).
We strongly believe in Iteration and delivering value in small pieces. Iteration can be hard, especially when you lack product context or are working in a particularly risky/complex part of the codebase. If you are struggling to estimate an issue or determine whether it is feasible, it may be appropriate to first create a proof-of-concept MR. The goal of a proof-of-concept MR is to remove any major assumptions during planning and provide early feedback, therefore reducing risk from any future implementation.
The need for a proof-of-concept MR may signal that parts of our codebase or product have become overly complex. It's always worth discussing the MR as part of the retrospective so we can discuss how to avoid this step in future.
Everyone at GitLab has the freedom to manage their work as they see fit, because we measure results, not hours. Part of this is the opportunity to work on items that aren't scheduled as part of the regular monthly release. This is mostly a reiteration of items elsewhere in the handbook, and it is here to make those explicit:
When you pick something to work on, please:
#s_manageto encourage transparency
After the Kickoff, the Manage stage conducts an asynchronous retrospective on the prior release. You can find current and past retrospectives for Manage in https://gitlab.com/gl-retrospectives/manage/issues/.
We're currently exploring group-specific retrospectives, in order to create a private and safe environment for group members to share thoughts, feedback, and concerns amongst group members they work more often with.
It can be hard to understand how you're doing in your role, because feedback can come off as formal (annual reviews, 360 surveys, career development conversations, goal check-ins) or casual (in Slack channels, 1-1's, MR reviews, team meetings.) We receive various kinds of feedback regularly and through different formats, so the type of feedback you're receiving is not always clear. In order to be more intentional about the types of feedback given, here is a classification chart based on three types of feedback:
|(appreciation)||I want to thank you for doing this, and please do more of it in the future||"I did not expect that you would have created a working group, because you've done so, our whole team will benefit from the results."|
|(coaching)||I'm trying to help you improve a behavior you are already exhibiting or change a behavior that you currently have||"The reports that you give me are very helpful, and in the future we can schedule them for the first of the month to be more consistent."|
|(evaluation)||Tells you where you stand according to existing standards or expectations||"My expectation was that our decision would be transparent. Since it was not, our team has forgotten the decision, so we must be sure and meet that expectation next time."|
Access works on components of the application that have a far-reaching impact. Because only a simple change can cause widespread support tickets and/or production incidents, there is less room for error which requires us to take these extra steps:
The Access group are responsible for several product categories that attract a significant amount of scrutiny from a security perspective. An outcome of this is that we see a higher number of new security issues being created compared to other groups, which over time has caused the security backlog to grow. To help tackle the backlog, from milestone 13.3, we will assign 2 Backend Engineers per milestone to a security rota.
The goal of this new process is to achieve more consistent progress in burning through the backlog. Historically we have focussed on solving high severity (severity::1/severity::2) issues, while trying to maintain a pragmatic balance with other concerns in the team - but this hasn't been effective in reducing the overall backlog. By dedicating capacity each milestone we can separate the planning of security issues from the main milestone goals, with the aim of introducing a more optimal process.
Engineers who are part of the rota should work from this board.
|Release||Start Date||First Engineer||Second Engineer|
|13.3||17th July 2020||mksionek||dblessing|
|13.4||17th August 2020||ifarkas||manojmj|
|13.5||~28th September 2020||alexpooley||-|
|13.6||~26th October 2020||ifarkas||manojmj|
|13.7||~23rd November 2020||mksionek||sarcila|
|14.0||~23rd May 2021||mksionek||dblessing|
|14.1||~23rd June 2021||mksionek||dblessing|
|14.2||~23rd July 2021||mksionek||dblessing|
|14.3||~23rd August 2021||serenafang||dblessing|
|14.4||~23rd September 2021||serenafang|
More information about security rota can be found here.
To help with milestone planning, we encourage asynchronously weighing issues to help get them
ready for development.
workflow:ready for developmentor not. Clarifying questions are asked on the issue. Product Manager adjusts description and scope as needed. This process may take a few days and the objective is to have an issue defined well enough to be estimated.
workflow:ready for developmentlabel. Alternatively they should raise their concerns in the issue. If the proposal is changed, the issue description should be updated.
The Compliance group would like to include an experimental section in issue descriptions. The section gives the author the opportunity to specify whether or not an issue requires subsequent implementation issues. ￼ In previous milestones, we've found that it's easy to miss linked implementation issues. In most cases, less complex issues already have a detailed implementation plan. In other cases, there may be links to follow-up issues. Other issues may be promoted to epics with the issues contained within the epic. ￼ We think that a dedicated section in issue descriptions, such as the following, would help:
### Does this issue require subsequent implementation issues? Yes/No
While group Import follows the Manage's process described above, we utilize additional flows that help us better prepare issues for scheduling into milestones.
The Import group does not use the
~priority::x labels. Instead, we use
In order to assign an incoming issue to a milestone or close it, the product manager may require input from the engineers.
To facilitate an asynchronous triage question and answer flow, the issue is labeled with the
triage question label and the team members are invited into a thread where the question is discussed. Any team member can answer the question and mention the product manager in the answer. If the product manager has enough information to triage the issue, the
triage question label is removed and the issue is assigned to the appropriate milestone or closed as infeasible.
For an issue to be deemed
workflow::ready for development, the issue goes through a refinement stage, where the engineers, the product manager, and other stable counterparts are able to evaluate the issue, ask any clarifying questions, and discuss potential approaches. At the end of that conversation, the issue can be deemed
workflow::ready for development, marked for further breakdown or even canceled if determined not feasible. As the team creates context around the issue, they also estimate the weight during this phase.
To place an issue into refinement, the issue is labeled with
workflow::refinement so it appears in the relevant list on our kanban board. To ensure a steady flow of work that is ready for development, engineers should attempt to refine an issue that is
workflow::refinement before picking up their next
workflow::ready for development issue. For issues with high urgency, issues can be assigned directly to engineers asking them to complete the refinement process as a top priority so it can be moved to
workflow::ready for development faster.
Our refinement process is asynchronous and encourages input from all team members. We vote (using emojis) whether the issue is ready for development or not. Any "no" votes are explained and further discussed in comments until the vote becomes a "yes", or the issue is removed from consideration.
Emojis are also used to vote for the issue weight. Any outlier votes are discussed in comments until a compromise is reached. Large estimates are also discussed to determine if the issue can be broken down further.
If the issue has all "yes" votes and has a weight estimate, it is deemed
workflow::ready for development.
During planning we don't plan 100% of the team's capacity to go into deliverable work each milestone. Instead, we reserve a buffer of 15% per team member to allow for more time to research and scope work.
Documentation is a crucial part of our definition of done. For any change that requires documentation, we may create a separate documentation issue that is linked to both backend and frontend issues. The frontend issue should be blocked by the documentation issue to prevent it from being closed prematurely. Backend will create a first draft and pass it on to frontend for adding screenshots and additional UI information if needed. The documentation MR and the feature MR(s) need to be merged in the same milestone.
Although we have a bias for asynchronous communication, synchronous meetings are necessary and should adhere to our communication guidelines. Some regular meetings that take place in Manage are:
|Weekly||Group-level meeting||Backend Engineering Managers||Ensure current release is on track by walking the board, unblock specific issues|
|Every 2 weeks||Stage-level Product/Engineering||@ogolowinski||Collaborate across groups on specific issues, discuss global stage-level optimization (process, people)|
|Monthly||Stage-level meeting (Manage Monthly)||@ogolowinski||Stage-level news, objectives, accomplishments|
|Monthly||Stage-level social call||@dennis||Getting to know each other|
|Monthly||Planning meetings||Product Managers||See Planning section|
For one-off, topic specific meetings, please always consider recording these calls and sharing them (or taking notes in a publicly available document).
Agenda documents and recordings can be placed in the shared Google drive (internal only) as a single source of truth.
Meetings that are not 1:1s or covering confidential topics should be added to the Manage Shared calendar.
All meetings should have an agenda prepared at least 12 hours in advance. If this is not the case, you are not obligated to attend the meeting. Consider meetings canceled if they do not have an agenda by the start time of the meeting.
The following people are permanent members of the Manage stage:
|Haris Delalić||Senior Product Manager, Manage:Import|
|Hannah Sutor||Senior Product Manager, Manage:Access|
|Sam Kerr||Principal Product Manager, Manage:Compliance|
|Austin Regnery||Senior Product Designer, Manage:Compliance|
|Daniel Mora||Senior Product Designer, Manage:Access|
|Nick Post||Senior Product Designer, Manage:Optimize|
|Evan Read||Senior Technical Writer, Create (Gitaly), Verify (Testing), Manage (Access, Compliance)|
|Marcin Sędłak-Jakubowski||Technical Writer, Plan, Manage (Optimize)|
|Andrejs Cunskis||Senior Software Engineer in Test, Manage:Import|
|Adam Hegyi||Senior Backend Engineer, Manage:Optimize|
|Alex Pooley||Senior Backend Engineer, Manage:Workspace|
|Bogdan Denkovych||Backend Engineer, Manage:Access|
|Brandon Labuschagne||Frontend Engineer, Manage:Optimize|
|Dan Jensen||Backend Engineering Manager, Manage, Manage:Optimize & Manage:Compliance|
|Dennis Tang||Frontend Engineering Manager, Manage:Access & Manage:Compliance & Manage:Import|
|Drew Blessing||Backend Engineer, Manage:Access|
|Ezekiel Kigbo||Senior Frontend Engineer, Manage:Optimize|
|George Koltsov||Backend Engineer, Manage:Import|
|Huzaifa Iftikhar||Backend Engineer, Manage:Compliance|
|Illya Klymov||Senior Frontend Engineer, Manage:Import|
|Imre Farkas||Staff Backend Engineer, Manage:Access|
|Jiaan Louw||Senior Frontend Engineer, Manage:Compliance|
|Kassio Borges||Senior Backend Engineer, Manage:Import|
|Liam McAndrew||Backend Engineering Manager, Manage:Access & Manage:Import|
|Magdalena Frankiewicz||Backend Engineer, Manage:Optimize|
|Małgorzata Ksionek||Acting Backend Engineering Manager, Manage:Workspace|
|Manoj M J||Senior Backend Engineer, Manage:Access|
|Martin Wortschack||Frontend Engineering Manager, Manage:Optimize & Manage:Import|
|Max Woolf||Senior Backend Engineer, Manage:Compliance|
|Michelle Gill||Senior Manager, Engineering, Manage|
|Pavel Shutsin||Senior Backend Engineer, Manage:Optimize|
|Peter Hegman||Frontend Engineer, Manage:Access|
|Robert Hunt||Frontend Engineer, Manage:Compliance|
|Rohit Shambhuni||Senior Security Engineer, Application Security, Manage (Access, Workspace, Compliance, Import, Optimize)|
|Sanad Liaquat||Senior Software Engineer in Test, Manage:Access|
|Serena Fang||Backend Engineer, Manage:Workspace|
|Orit Golowinski||Group Manager, Product Management, Manage|