The responsibilities of this collective team are described by the Plan stage. Among other things, this means
working on GitLab's functionality around issues, issue boards, milestones, todos, issue lists and filtering, roadmaps, time tracking, requirements management, and notifications.
Issues have the following lifecycle. The colored circles above each workflow stage represents the emphasis we place on collaborating across the entire lifecycle of an issue; and that disciplines will naturally have differing levels of effort required dependent upon where the issue is in the process. If you have suggestions for improving this illustration, you can leave comments directly on the whimsical diagram.
If an issue is > 3 weight, consider promoting it to an epic (quick action) and split it up into multiple issues. It's helpful to add a task list with each task representing a vertical feature slice (MVC) on the newly promoted Epic. This enables us to practice "Just In Time Planning" by creating new issues from the task list as there is space downstream for implementation. When creating new vertical feature slices from an epic, please remember to add the appropriate labels - devops::plan, group::*, Category:* or feature label, and the appropriate workflow stage label - and attach all of the stories that represent the larger epic. This will help capture the larger effort on the roadmap and make it easier to schedule.
A["devops::plan"] --> B["group::*"];
B --> C["Category:*"];
B --> D["non-category feature"];
C --> E["maturity::minimal"];
C --> F["maturity::viable"];
C --> G["maturity::complete"];
C --> H["maturity::lovable"];
E--> I["Iterative Epic(s)"];
G --> I;
H --> I;
D --> I;
The retrospective issue is created by a scheduled pipeline in the
async-retrospectives project. For more information on how it works, see that
Most of our group meetings are recorded and publicly available on
YouTube in the Plan group playlist.
Weekly group meeting
The only regular meeting we have is a Wednesday group-wide
meeting. Because of timezone constraints, not everyone is able to
attend, and the meeting is currently more suitable for people in EMEA
and the eastern side of the Americas.
Smaller Iterations: A 4-6 weeks release cycle is helpful from a marketing perspective, but it is too long of a time horizon for continuously delivering working software incrementally and iteratively. We can accomplish this by breaking bigger features intto smaller vertical feature slices. If an Issue has a weight of > 3, it is a good signal it should be broken down into smaller pieces. The larger the weight, the more risk and likelihood the Issue will take longer than the estimate.
Limit Work In Progress:Context switching is expensive. By limiting the amount of Issues in progress at any given time, the less frequently you will have to incur this cost. You may think multitasking is inevitable, but by adhering to a work in progress limit, you will more quickly surface the parts of our process that are inefficient; enabling us to collectively fix them as a team.
Our stage level dashboard (internal) is a work in progress and is where we keep track of SMAU, feature usage, and other metrics we care about.
We have two versions for SMAU, with the "loose" version currently taking precedence as our Stage's externally communicated "North Star". It is our hope and long term goal to move away from defining our success according to vanity metrics and move towards a more congruent model that is based upon actual feature usage and adoption.
The definitive metric is driven by total count of unique users with one or more page views over a given reporting period, where views attributable to the Plan Stage are being derived from the following paths:
Issue List - ~/issues
Issue - ~/issues/(.*?)
Issue Board - ~/boards/(.*?)
Epic List - ~/epics
Epic - ~/epics/(.*?)
Roadmap - ~/roadmap
Labels - ~/labels
Milestones List - ~/milestones
Milestone - ~/milestones/(.*?)
Todos - ~/dashboard/todos
Personal Issues - ~/dashboard/issues(.*?)
Notification Settings - ~/profile/notifications
We are currently in the process of implementing the necessary telemetry instrumentation to properly track the "strict" definition. The definitive metric is driven by total count of unique users with one or more actions over a given reporting period, where actions attributable to the Plan Stage are being derived from the following events:
Project Management - Issue Tracking
Filter Bar - A user adds a filter (applies to issue lists, issue boards, epics list…anywhere the filter bar is used).
Issue Weight - An issue weight is added, removed, or updated.
Issues - A user creates an issue, updates an issue, or interacts with an issue via a comment, emoji award.
Labels - User creates or updates a group or project label; or applies or removes a label on an issue.
Markdown - Issue or epic descriptions added or updated.
Milestones - A user associates an issue to a milestone, creates a milestone, updates a milestone, removes a milestone, or toggles the burndown view type on a milestone.
Notifications - A user disables or enables on an issue, or updates their global notification settings.
Quick Actions - A quick action is used.
Todos - A Todo is manually added or marked as done
Project Management - Issue Boards
A user creates a board, adds a list, or manually moves a card across lists or changes the priority order of the card within the same list by dragging it up or down.
Project Management - Time Tracking
A user adds a time estimate, updates a time estimate, or records time spent.
Portfolio Management - Agile Portfolio Management
Epics - An epic is created or update. An epic or issue is associated to an epic. A user comments on an epic or adds an emoji award.
Roadmap - Since we don't have a ton of specific interaction events yet. In the interim, we can fallback on unique roadmap views.
Certify - Service Desk
The number of inbound requests and outbound responses.