Skip to content

Rename product groups: #g-mdm → #g-apple-at-work, #g-software → #g-auto-patching #48482

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
georgekarrv merged 2 commits into from
Jul 1, 2026
Merged

Rename product groups: #g-mdm → #g-apple-at-work, #g-software → #g-auto-patching #48482

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a95433e
Rename product groups #g-mdm to #g-apple-at-work and #g-software to #…
georgekarrv Jun 30, 2026
af60451
Apply suggestion from @georgekarrv
georgekarrv Jul 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions handbook/company/product-groups.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ The goal of the MDM group is to increase and exceed [Fleet's product maturity go
- Setup experience
- OS configuration & updates

> The [Slack channel](https://fleetdm.slack.com/archives/C03C41L5YEL), [kanban release board](https://github.com/orgs/fleetdm/projects/58), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3A%23g-mdm) for this product group is `#g-mdm`.
> The [Slack channel](https://fleetdm.slack.com/archives/C03C41L5YEL), [kanban release board](https://github.com/orgs/fleetdm/projects/58), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3A%23g-apple-at-work) for this product group is `#g-apple-at-work`.


### Software group
Expand All @@ -86,7 +86,7 @@ The goal of the software group is to increase and exceed [Fleet's product maturi
- Scripts
- End user self-service

> The [Slack channel](https://fleetdm.slack.com/archives/C086V2QK76X), [kanban release board](https://github.com/orgs/fleetdm/projects/70), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-software) for this product group is `#g-software`.
> The [Slack channel](https://fleetdm.slack.com/archives/C086V2QK76X), [kanban release board](https://github.com/orgs/fleetdm/projects/70), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-auto-patching) for this product group is `#g-auto-patching`.


### Orchestration group
Expand Down Expand Up @@ -375,7 +375,7 @@ The goal of the Apple @ Work working group is to increase the number of Apple de
- Apple setup experience
- macOS, iOS, and iPadOS configuration & updates

> The [Slack channel](https://fleetdm.slack.com/archives/C03C41L5YEL), [kanban board](https://github.com/orgs/fleetdm/projects/58), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3A%23g-mdm) for this working group is `#g-mdm`.
> The [Slack channel](https://fleetdm.slack.com/archives/C03C41L5YEL), [kanban board](https://github.com/orgs/fleetdm/projects/58), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3A%23g-apple-at-work) for this working group is `#g-apple-at-work`.


### Auto Patching group
Expand All @@ -399,7 +399,7 @@ The goal of the Auto Patching working group is to reduce the amount of time befo
- End user self-service
- Scripts

> The [Slack channel](https://fleetdm.slack.com/archives/C086V2QK76X), [kanban board](https://github.com/orgs/fleetdm/projects/70), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-software) for this working group is `#g-software`.
> The [Slack channel](https://fleetdm.slack.com/archives/C086V2QK76X), [kanban board](https://github.com/orgs/fleetdm/projects/70), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-auto-patching) for this working group is `#g-auto-patching`.
-->


Expand Down Expand Up @@ -508,7 +508,7 @@ 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`, `#g-security-compliance`), the `:release` label, and notify the product group's Engineering 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-apple-at-work`, `#g-orchestration`, `#g-auto-patching`, `#g-security-compliance`), the `:release` label, and notify the product group's Engineering Manager to make sure the changes go through testing (QA) before release.

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.

Expand Down Expand Up @@ -581,7 +581,7 @@ The DRI for defining and drafting issues for a product group is the product mana

A user story is considered ready for implementation once:
- [ ] User story [issue created](https://github.com/fleetdm/fleet/issues/new/choose)
- [ ] [Product group](https://fleetdm.com/handbook/company/product-groups) label added (e.g. `#g-mdm`, `#g-orchestration`, `#g-software`, `#g-security-compliance`)
- [ ] [Product group](https://fleetdm.com/handbook/company/product-groups) label added (e.g. `#g-apple-at-work`, `#g-orchestration`, `#g-auto-patching`, `#g-security-compliance`)
- [ ] Changes [specified](https://fleetdm.com/handbook/company/development-groups#drafting) and [designed](https://fleetdm.com/handbook/company/why-this-way#why-do-we-use-a-wireframe-first-approach)
- [ ] [Designs revised and settled](#design-reviews)
- [ ] Reviewed and approved during [weekly user story review](#user-story-reviews)
Expand Down Expand Up @@ -803,7 +803,7 @@ All unreleased bugs are addressed before publishing a release. Released bugs tha

### Notify the community about a critical bug

We inform customers and the community about critical bugs immediately so they don’t trigger it themselves. When a bug meeting the definition of critical is found, the bug finder is responsible for raising an alarm. Raising an alarm means pinging @here in the `#g-mdm`, `#g-software`, `#g-orchestration`, or `#g-security-compliance` channel with the filed bug.
We inform customers and the community about critical bugs immediately so they don’t trigger it themselves. When a bug meeting the definition of critical is found, the bug finder is responsible for raising an alarm. Raising an alarm means pinging @here in the `#g-apple-at-work`, `#g-auto-patching`, `#g-orchestration`, or `#g-security-compliance` channel with the filed bug.

If the bug finder is not a Fleetie (e.g., a member of the community), then whoever sees the critical bug should raise the alarm. Note that the bug finder here is NOT necessarily the **first** person who sees the bug. If you come across a bug you think is critical, but it has not been escalated, raise the alarm!

Expand Down Expand Up @@ -863,7 +863,7 @@ At the **🎁🗣 Feature Fest** meeting, the Feature prioritization DRI weighs

If a feature is not prioritized during a 🎁🗣 Feature Fest meeting, it only means the feature has been rejected _at that time_. Requestors will be notified by the Feature prioritization DRI, and they can add their request back to the feature fest board (`~feature fest` label) to bring it back to a future meeting.

> If a feature request has an urgent Fleet need and can't wait until the next feature fest, @ mention the Head of Product Design in the `#g-mdm`, `#g-software`, `#g-orchestration`, or `#g-security-compliance` channel with a link to the request's GitHub issue. It's up to the HPD to decide whether it is immediately prioritized to go through drafting or put to the side. If prioritized, the HPD will decide to de-prioritize one or more feature requests to make room in the current design sprint and notify requesters.
> If a feature request has an urgent Fleet need and can't wait until the next feature fest, @ mention the Head of Product Design in the `#g-apple-at-work`, `#g-auto-patching`, `#g-orchestration`, or `#g-security-compliance` channel with a link to the request's GitHub issue. It's up to the HPD to decide whether it is immediately prioritized to go through drafting or put to the side. If prioritized, the HPD will decide to de-prioritize one or more feature requests to make room in the current design sprint and notify requesters.


### After the feature is accepted
Expand Down Expand Up @@ -916,7 +916,7 @@ You can read our guide to diagnosing issues in Fleet on the [debugging page](htt

#### Inbox

> Working groups use the bug triage process below. For product groups (#g-mdm, #g-software, #g-orchestration, and #g-security-compliance) Product Designers are responsible for triaging bugs [as they do today](https://github.com/fleetdm/fleet/blob/dbe9a3434217f2dc934c9af9778541aea60f4fc9/handbook/company/product-groups.md#inbox). Learn more about the [working group rollout](https://fleetdm.com/handbook/company/product-groups#working-group-rollout).
> Working groups use the bug triage process below. For product groups (#g-apple-at-work, #g-auto-patching, #g-orchestration, and #g-security-compliance) Product Designers are responsible for triaging bugs [as they do today](https://github.com/fleetdm/fleet/blob/dbe9a3434217f2dc934c9af9778541aea60f4fc9/handbook/company/product-groups.md#inbox). Learn more about the [working group rollout](https://fleetdm.com/handbook/company/product-groups#working-group-rollout).

Quickly confirming and reproducing bug reports is a [priority for Fleet](https://fleetdm.com/handbook/company/why-this-way#why-make-it-obvious-when-stuff-breaks). When a new bug is created using the [bug report template](https://github.com/fleetdm/fleet/issues/new?template=bug-report.md), it is in the "inbox" state. Website bugs (label: `#g-website`) are triaged by the [website group](https://fleetdm.com/handbook/company/product-groups#website-group).

Expand Down Expand Up @@ -1341,7 +1341,7 @@ See the [rituals contributor docs](https://github.com/fleetdm/fleet/tree/main/do

Each release cycle is marked by five essential ceremonies:

1. **Sprint kickoff**: On the first day of the sprint, the team, along with stakeholders, selects issues from the [🦢 Drafting board](https://github.com/orgs/fleetdm/projects/67) to work on. To move issues to the sprint board, add `:release` and the product group label (`#g-mdm`, `#g-orchestration`, `#g-software`, `#g-security-compliance`) and remove the 🦢 Drafting project. The team then commits to completing these items within the sprint.
1. **Sprint kickoff**: On the first day of the sprint, the team, along with stakeholders, selects issues from the [🦢 Drafting board](https://github.com/orgs/fleetdm/projects/67) to work on. To move issues to the sprint board, add `:release` and the product group label (`#g-apple-at-work`, `#g-orchestration`, `#g-auto-patching`, `#g-security-compliance`) and remove the 🦢 Drafting project. The team then commits to completing these items within the sprint.
2. **Daily standup**: Every day, the team convenes for updates. During this session, each team member shares what they accomplished since the last standup, their plans until the next meeting, and any blockers they are experiencing. The team briefly reviews the [bug Inbox](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%3Areproduce) to identify any bugs ready to move forward or that need a QA engineer assigned, the goal is that these bugs are timeboxed for 30m-1hr to reproduce or ask for additional details. Standups should last no longer than fifteen minutes. If additional discussion is necessary, it takes place after the standup with only the required participants.
3. **Weekly estimation sessions**: The team estimates backlog items once a week (three times per sprint). These sessions help to schedule work completion and align the roadmap with business needs. They also provide estimated work units for upcoming sprints. The EM is responsible for the point values assigned to each item and ensures they are as realistic as possible.
4. **Scrum of scrums**: Each product group's Tech Lead, and optionally the EMs, meet once per sprint. This is a coordination technique used to scale scrum for multiple teams working on a large, complex product by having representatives from each team meet regularly to share progress, discuss dependencies, and solve inter-team issues.
Expand Down
2 changes: 1 addition & 1 deletion handbook/customer-success/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -166,7 +166,7 @@ Business reviews are conducted quarterly or bi-annually to ensure initial succes
- Have a support engineer collect data on open and closed bugs from the previous quarter and highlight any P0 or P1 incidents along with a summary of the postmortem (search Unthread and GitHub for issues tagged with the customer codename and ':bug').
- Summarize status updates for open feature requests and highlight delivered feature requests.
- For managed cloud customers, reach out to #help-infrastructure to collect information on cloud uptime and any outages or alarms.
- Provide one slide with information on the latest Fleet release and any upcoming big ticket features which can be found on the product board and current release board for #g-mdm and #g-endpoint-ops
- Provide one slide with information on the latest Fleet release and any upcoming big ticket features which can be found on the product board and current release board for #g-apple-at-work and #g-endpoint-ops
Comment thread
georgekarrv marked this conversation as resolved.
Outdated
3. After the business review, save the presentation as a PDF and share it with your customer.

### Track a customer promise
Expand Down
4 changes: 2 additions & 2 deletions handbook/engineering/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -119,7 +119,7 @@ All conversation about an unfixed vulnerability stays in the confidential repo
1. Add the `~pushed` label to the user story.
2. Update the user story's milestone to the next minor version milestone.
3. Comment on the GitHub issue and at-mention the Head of Product Design, the product group's Engineering Manager, and anyone listed in the requester field.
4. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the #g-mdm, #g-software, #g-orchestration, or #g-security-compliance Slack channel.
4. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the #g-apple-at-work, #g-auto-patching, #g-orchestration, or #g-security-compliance Slack channel.

> Instead of waiting until the end of the sprint, notify stakeholders as soon as you know the story is being pushed.
Expand All @@ -139,7 +139,7 @@ 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 Designer (PD).
- Notify the relevant PD in the #g-mdm, #g-software, #g-orchestration, or #g-security-compliance Slack channel.
- Notify the relevant PD in the #g-apple-at-work, #g-auto-patching, #g-orchestration, or #g-security-compliance Slack channel.

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:

Expand Down
2 changes: 1 addition & 1 deletion handbook/engineering/engineering.rituals.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@
task: "Release QA"
startedOn: "2023-08-09"
frequency: "Triweekly"
description: "Every release cycle, by end of day Friday of release week, move all issues to the ”✅ Ready for release” column on the #g-mdm and #g-endpoint-ops sprint boards."
description: "Every release cycle, by end of day Friday of release week, move all issues to the ”✅ Ready for release” column on the #g-apple-at-work and #g-endpoint-ops sprint boards."

@coderabbitai coderabbitai Bot Jun 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

This rename is incomplete for the Release QA workflow.

Line 112 now tells people to use #g-apple-at-work, but the supplied release tooling still hard-codes #g-mdm for QA issue creation in tools/release/publish_release.sh:383-394, and tools/github-manage/pkg/ghapi/views.go:11-16 plus tools/github-manage/pkg/ghapi/views_test.go:23-28 still treat #g-mdm as the canonical label. That leaves the handbook and automation pointing at different boards/labels for the same process. Please update those consumers in the same rollout, or keep the old name here until the tooling migration lands.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@handbook/engineering/engineering.rituals.yml` at line 112, The Release QA
rename is only partial because the handbook now says `#g-apple-at-work` while the
release automation and GitHub label canonicalization still use `#g-mdm`. Update
the related tooling in publish_release.sh and the ghapi views code plus its
tests so they all reference the same board/label as the handbook, or revert this
handbook rename until the automation migration is completed. Use the existing
symbols publish_release.sh, views.go, and views_test.go to locate the affected
logic and keep the naming consistent across the workflow.

moreInfoUrl:
dri: "AndreyKizimenko"
-
Expand Down
4 changes: 2 additions & 2 deletions handbook/product-design/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ Additionally:
- If the original request is a customer promise, specify what the due date is and who it's for.

- Sometimes a Product Designer in one product group drafts a user story or bug that will be specified, estimated, or implemented by another product group. This happens when the original group is constrained by design or engineering capacity. You'll know this is happening when they're a `assisting-g-*` label on the story or bug.
- For example, if a #g-mdm Product Designer drafts a story that #g-security-compliance will implement, the #g-mdm Product Designer invites the #g-security-compliance Tech Lead to #g-mdm design reviews. Once the story is approved, it’s brought to #g-security-compliance user story review.
- For example, if a #g-apple-at-work Product Designer drafts a story that #g-security-compliance will implement, the #g-apple-at-work Product Designer invites the #g-security-compliance Tech Lead to #g-apple-at-work design reviews. Once the story is approved, it’s brought to #g-security-compliance user story review.
- At that point, the #g-security-compliance Product Designer becomes the [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris). They bring the story to their group’s estimation and handle questions from their team, coordinating with others as needed.

>**Questions and missing information:** Take a screenshot of the area in Figma and add a comment in the story's GitHub issue. Figma does have a commenting system, but we use GitHub issues so that all questions/conversation live in one place.
Expand Down Expand Up @@ -184,7 +184,7 @@ If the original request is a customer request, it's up to the relevant CSA to de
[User stories](https://fleetdm.com/handbook/company/product-groups#scrum-items) are intended to be [drafted](#drafting) and estimated in a single sprint. When the Product Designers (PD) knows a user story will be pushed, it is the PD's responsibility to notify stakeholders:

1. Comment on the GitHub issue and at-mention the Head of Product Design and [release DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris).
2. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the #g-mdm, #g-software, #g-orchestration, or #g-security-compliance Slack channel.
2. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the #g-apple-at-work, #g-auto-patching, #g-orchestration, or #g-security-compliance Slack channel.

> Instead of waiting until the end of the sprint, notify stakeholders as soon as you know the story is being pushed.

Expand Down
Loading