diff --git a/handbook/company/product-groups.md b/handbook/company/product-groups.md index 4a6adf3bfc..cfc80b5254 100644 --- a/handbook/company/product-groups.md +++ b/handbook/company/product-groups.md @@ -113,7 +113,9 @@ To make a change to Fleet: - Then, it will be [drafted](https://fleetdm.com/handbook/company/product-groups#drafting) (planned). - Next, it will be [implemented](https://fleetdm.com/handbook/company/product-groups#implementing) and [released](https://fleetdm.com/handbook/engineering#release-process). -> 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. +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. ### Planned and unplanned changes diff --git a/handbook/engineering/README.md b/handbook/engineering/README.md index 42c136ce35..d8195cf788 100644 --- a/handbook/engineering/README.md +++ b/handbook/engineering/README.md @@ -69,7 +69,7 @@ All bug fix pull requests should reference the issue they resolve with the issue ### Review a community pull request -If you're assigned a community pull request for review, it is important to keep things moving for the contributor. The goal is to not go more than one business day without following up with the contributor. +If you're assigned a community pull request (PR) for review, it is important to keep things moving for the contributor. The goal is to not go more than one business day without following up with the contributor. This applies to PRs from Fleeties, open source contributors, member of the Customer Success team, etc. If the PR is a quick fix (i.e. typo) or obvious technical improvement that doesn't change the product, it can be merged. @@ -77,18 +77,14 @@ Make sure to create a Github issue and link it to the PR so that we can track th **For PRs that change the product:** -- Assign the PR to the appropriate product group EM (Engineering Manager). -- Notify the EM in the #help-engineering Slack channel. +- Assign the PR to the appropriate Product Designer (PD). +- Notify the relevant PD in the #g-mdm, #g-software, or #g-orchestration Slack channel. -The EM will be the contact point for the contributor and will ensure the PR is reviewed by the appropriate team member when ready. The EM should: +The PD will be the contact point for the contributor and will ensure the PR is reviewed by the appropriate team member when ready. The PD should: - Set the PR to draft. -- Thank the contributor for their hard work, explain that all changes to the product go through Fleet's [prioritization process](https://fleetdm.com/handbook/company/product-groups#how-feature-requests-are-prioritized), and ask them to file a [feature request](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=%3Aproduct&projects=&template=feature-request.md&title=) that describe the change their PR is introducing. - -**For PRs that will not be merged:** - -- Thank the contributor for their effort and explain why the changes won't be merged. -- Close the PR. +- Immediately decide whether to prioritize a user story and bring it through drafting or put the change to the side (not prioritize). +- Thank the contributor for their hard work, notify them on whether their change was prioritized or put to the side. If the change was put to the side, ask the contributor to file a [feature request](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=%3Aproduct&projects=&template=feature-request.md&title=) that describes the change, let them know that it only means the change has been rejected _at that time_, and close the PR. ### Merge a community pull request