From 4624ff2b37c1a949588f9d021d9ab3207318b7a1 Mon Sep 17 00:00:00 2001 From: Noah Talerman <47070608+noahtalerman@users.noreply.github.com> Date: Tue, 16 Sep 2025 07:16:20 -0700 Subject: [PATCH] Product groups handbook: Process for contributors outside product groups (#33032) Update handbook to reflect reality (how things work at Fleet today). --- handbook/company/product-groups.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/handbook/company/product-groups.md b/handbook/company/product-groups.md index fbc139c612..7875426436 100644 --- a/handbook/company/product-groups.md +++ b/handbook/company/product-groups.md @@ -143,7 +143,7 @@ Goal Fleet's highest product ambition is to create experiences that users want. -To deliver on this mission, we need a clear, repeatable process for turning an idea into a set of cohesively-designed changes in the product. We also need to allow [open source contributions](https://fleetdm.com/handbook/company#open-source) at any point in the process from the wider Fleet community - these won't necessarily follow this process. +To deliver on this mission, we need a clear, repeatable process for turning an idea into a set of cohesively-designed changes in the product. > Learn more about Fleet's philosophy and process for making interface changes to the product, and [why we use a wireframe-first approach](https://fleetdm.com/handbook/company/why-this-way#why-do-we-use-a-wireframe-first-approach). @@ -158,7 +158,7 @@ To make a change to Fleet: Occasionally, a contributor outside of the [product groups](https://fleetdm.com/handbook/product-groups#current-product-groups) (open source contributor, member of the Customer Success team, etc.) will implement a change that was prioritized and drafted. On the user story for these changes, add the product group label (e.g. `#g-mdm`, `#g-orchestration`, `#g-software`), the `:release` label, and notify the product group's Engineer Manager to make sure the changes go through testing (QA) before release. -Also, sometimes a contributor will propose a change in the form of a pull request (PR). When this happens, the PR will be [reviewed](https://fleetdm.com/handbook/engineering#review-a-community-pull-request) and then merged or closed. +When an [open source contributor](https://fleetdm.com/handbook/company#open-source) proposes a change in the form of a pull request (PR), the PR will be [reviewed](https://fleetdm.com/handbook/engineering#review-a-community-pull-request) and then merged or closed. ### Planned and unplanned changes @@ -922,7 +922,7 @@ Each sprint is marked by five essential ceremonies: Many open source contributions that start as a small, seemingly innocuous pull request come with lots of additional [unplanned work](https://fleetdm.com/handbook/company/development-groups#planned-and-unplanned-changes) down the road: unforeseen side effects, documentation, testing, potential breaking changes, database migrations, [and more](https://fleetdm.com/handbook/company/development-groups#defining-done). -Thus, to ensure consistency, completeness, and secure development practices, no matter where a contribution comes from, Fleet will still follow the standard process for [prioritizing](#prioritizing-improvements) and [drafting](https://fleetdm.com/handbook/company/development-groups#drafting) a feature when it comes from the community. +Thus, to ensure consistency, completeness, and secure development practices, no matter where a contribution comes from, Fleet will still follow the standard process for [drafting](https://fleetdm.com/handbook/company/development-groups#drafting) a feature when it comes from the community. #### Stubs