For more details about the product vision for Telemetry, see our Telemetry page.
Telemetry manages several product categories:
|🧺 Collection||The structure(s) and platform(s) of how we collect Telemetry data|
|🔍 Analysis||Manages GitLab's internal needs for an analysis tool that serves the Product department|
|James Lopez||Engineering Manager, Fulfillment and Telemetry|
|A. M||Backend Engineer, Telemetry|
We plan in monthly cycles in accordance with our Product Development Timeline.
Release scope for an upcoming release should be finalized by the
On or around the
26th: Product meets with Engineering Managers for a preliminary issue review. Issues are tagged with a milestone and are estimated initially.
Our planning process is reflected in boards that should always reflect our current priorities. You can see our priorities for backend.
Priorities should be reflected in the priority label for scheduled issues:
|Priority||Description||Probability of shipping in milestone|
|P1||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%|
|P2||High: important issues that have significant positive impact to the business or technical debt. Important, but not time-critical or blocking others.||~75%|
|P3||Normal: incremental improvements to existing features. These are important iterations, but deemed non-critical.||~50%|
|P4||Low: stretch issues that are acceptable to postpone into a future release.||~25%|
You can read more about prioritization on the direction page.
Before work can begin on an issue, we should estimate it first after a preliminary investigation. This is normally done in the monthly planning meeting.
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 effected). 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.|
|8||A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements.|
|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.|
Issues that may take longer than 2 days or have a weight of 3 or more, may require additional splitting (either in smaller issues if the requirements can be simplified, or by creating separate MRs for the same issue).
This will ensure that we can reach 10 MRs per dev per month, therefore increasing throughput.
If a developer has completed work on an issue, they may open the prioritization board. and begin working on the next prioritized issue (First P1s, then P2s, and so on…).
An issue will have 4 stages, and they should be moved accordingly using the Telemetry workflow board
8th, the Telemetry team conducts an asynchronous retrospective.