diff --git a/handbook/company/product-groups.md b/handbook/company/product-groups.md index ba60bd9b3d..c4aab6ae7a 100644 --- a/handbook/company/product-groups.md +++ b/handbook/company/product-groups.md @@ -16,44 +16,48 @@ At Fleet, [anyone can contribute](https://fleetdm.com/handbook/company#openness) | Product group | Goal _(value for customers and/or community)_ | Capacity\* | |:--------------------------|:--------------------------------------------------------------------|:-----------------| -| [MDM](#mdm-group) | Reach maturity in the "MDM" product category. | 65 | -| [Customer experience (CX)](#customer-experience-group) | Make customers happier and more successful. | 78 | +| [Endpoint ops](#endpoint-ops-group) | Increase and exceed maturity in the "Endpoint operations" category. | 78 | +| [MDM](#mdm-group) | Reach maturity in the "MDM" product category. | 65 | | [Infrastructure](#infrastructure-group) | Provide and support reliable and secure infrastructure. | 13 | -| [Website](#website-group) | Make the website wonderful. | 13 | +| [Website](#website-group) | Make the website wonderful. | 13 | \* The number of estimated story points this group can take on per-sprint under ideal circumstances, used as a baseline number for planning and prioritizing user stories for drafting. In reality, capacity will vary as engineers are on-call, out-of-office, filling in for other product groups, etc. -### MDM group - -The goal of the MDM group is to reach [product maturity](https://drive.google.com/file/d/11yQ_2WG7TbRErUpMBKWu_hQ5wRIZyQhr/view?usp=sharing) in the "MDM" product category, across macOS and Windows. - -| Responsibility | Human(s) | -|:----------------------------------|:--------------------------| -| Designer | Marko Lisica -| Engineering manager | George Karr -| Quality assurance | Sabrina Coy -| Product manager | Noah Talerman -| Software engineers (developers) | Gabe Hernandez, Roberto Dip, Sarah Gillespie, Marcos Oviedo, Martin Angers - -> The Slack channel, kanban release board, and label for this product group is `#g-mdm`. +> _**What happened to "CX"?** The customer experience (CX) group at Fleet is now [`#g-endpoint-ops`](#endpoint-ops-group)._ +> +> _Why? Making users and customers happier and more successful is the goal of _every_ product group. This includes simpler usage, lovable design + help text + error messages, fixed bugs, responding quickly to incidents, using Fleet's brand standards, more successful customer onboarding, features that drive more win-win meetings with contributors and Fleet's sales team, and "whole product solutions", including professional services, design partnerships, and training._ -### Customer experience group - -The goal of the customer experience (CX) group is to make users and customers happier and more successful. This includes simpler usage, more successful customer onboarding, features that drive more win-win meetings with contributors and Fleet's sales team (such as initiatives like out-of-the-box CIS compliance for customers), and "whole product solutions", including professional services, design partnerships, and training. - -> _**Note:** If a user story involves only changes to fleetdm.com, without changing the core product, then that user story is prioritized, drafted, implemented, and shipped by the [website group](https://fleetdm.com/handbook/company/development-groups#website-group)._ +### Endpoint ops group +The goal of the endpoint ops group is to increase and exceed [Fleet's product maturity goals in the endpoint operations category](https://drive.google.com/file/d/11yQ_2WG7TbRErUpMBKWu_hQ5wRIZyQhr/view?usp=sharing). | Responsibility | Human(s) | |:----------------------------------|:--------------------------| | Designer | Rachael Shaw | Engineering manager | Sharon Katz +| Product manager | Noah Talerman | Quality assurance | Reed Haynes -| Product manager | Mo Zhu -| Software engineers (developers) | Jacob Shandling, Lucas Rodriguez, Rachel Perkins, Eric Shaw, Tim Lee, Jahziel Villasana-Espinoza, Victor Lyuboslavsky +| Developers (software engineers) | Jacob Shandling, Lucas Rodriguez, Rachel Perkins, Eric Shaw, Tim Lee, Jahziel Villasana-Espinoza, Victor Lyuboslavsky + +> The Slack channel, kanban release board, and label for this product group is `#g-endpoint-ops`. + + +### MDM group + +The goal of the MDM group is to increase and exceed [Fleet's product maturity goals](https://drive.google.com/file/d/11yQ_2WG7TbRErUpMBKWu_hQ5wRIZyQhr/view?usp=sharing) in the "MDM" product category. + +| Responsibility | Human(s) | +|:----------------------------------|:--------------------------| +| Designer | Marko Lisica +| Engineering manager | George Karr +| Product manager | Noah Talerman +| Quality assurance | Sabrina Coy +| Developers (software engineers) | Gabe Hernandez, Roberto Dip, Sarah Gillespie, Marcos Oviedo, Martin Angers + +> The Slack channel, kanban release board, and label for this product group is `#g-mdm`. + -> The Slack channel, kanban release board, and label for this product group is `#g-cx`. ### Infrastructure group @@ -72,12 +76,12 @@ The goal of the infrastructure group is to provide and support reliable and secu The goal of the website group is to manage and maintain Fleet's website and documentation by prioritizing and actioning meaningful changes to enhance brand awareness and provide visitors with the information they need when they need it. This includes making the content and user experience more beautiful, simple, and easier to understand. -> _**Note:** If a user story involves **both** changes to the core product **and** to fleetdm.com, then that user story is prioritized, drafted, implemented, and shipped by the [CX group](https://fleetdm.com/handbook/company/development-groups#customer-experience-group)._ +> _**Note:** If a user story involves only changes to fleetdm.com, without changing the core product, then that user story is prioritized, drafted, implemented, and shipped by the [#g-website group](https://fleetdm.com/handbook/company/development-groups#website-group). Otherwise, if the story **also** involves changes to the core product **as well as** fleetdm.com, then that user story is prioritized, drafted, implemented, and shipped by [the other relevant product group](https://fleetdm.com/handbook/company/development-groups#current-product-groups), and not by `#g-website`._ | Responsibility | Human(s) | |:----------------------------------|:--------------------------| | Designer | Michael Thomas -| Engineering manager | Mike McNeil +| Engineering manager | Eric Shaw | Quality assurance | Michael Thomas | Product manager | Michael Thomas | Software engineers (developers) | Eric Shaw @@ -116,7 +120,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-cx`, `#g-mdm`) +- [ ] [Product group](https://fleetdm.com/handbook/company/product-groups) label added (e.g. `#g-endpoint-ops`, `#g-mdm`) - [ ] 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) - [ ] [Estimated](https://fleetdm.com/handbook/company/why-this-way#why-scrum) @@ -288,5 +292,14 @@ No API changes are merged without accompanying API documentation and approval fr + +#### Stubs +The following stubs are included only to make links backward compatible. + +##### Endpoint ops group +Please see [๐Ÿ“–handbook/company/product-groups#endpoint-ops-group](https://fleetdm.com/handbook/company/product-groups#endpoint-ops-group). + + + diff --git a/handbook/customers/README.md b/handbook/customers/README.md index 4794b11c47..ad8d08a9df 100644 --- a/handbook/customers/README.md +++ b/handbook/customers/README.md @@ -282,7 +282,7 @@ To schedule an [ad hoc meeting](https://www.vocabulary.com/dictionary/ad%20hoc) - Confirm that contact information is accurate and that the customer can receive and access meeting invites. ### Close a new customer deal -To close a deal with a new customer (non-self-service), create a GitHub issue using the ["Sale" issue template](https://github.com/fleetdm/confidential/issues/new?assignees=hollidayn%2Czayhanlon&labels=project%2C%23cx%2C%23sales%2C%23business-operations&template=3-sale.md&title=New+customer%3A+_____________) and follow the steps. +To close a deal with a new customer (non-self-service), create a GitHub issue using the ["Sale" issue template](https://github.com/fleetdm/confidential/issues/new?assignees=hughestaylor&labels=%23g-business-operations&projects=&template=3-sale.md&title=New+customer%3A+_____________) and follow the steps. > TODO: dedupe between this section and the "Sale" issue template diff --git a/handbook/engineering/README.md b/handbook/engineering/README.md index 1b076edece..2fcddee496 100644 --- a/handbook/engineering/README.md +++ b/handbook/engineering/README.md @@ -24,23 +24,9 @@ The ๐Ÿš€ Engineering department at Fleet is directly responsible for writing and - If urgent, or if you need help submiting an issue, mention a [team member](#team) in the [#help-engineering](https://fleetdm.slack.com/archives/C019WG4GH0A) Slack channel. - Any Fleet team member can view the dedicated sprint boards managed by this department: - ๐Ÿ’ป [MDM (#g-mdm)](https://app.zenhub.com/workspaces/-g-mdm-current-sprint-63bc507f6558550011840298/board) - - ๐ŸŒŸ [Customer experience (#g-cx)](https://app.zenhub.com/workspaces/-g-cx-current-sprint-63bd7e0bf75dba002a2343ac/board) + - ๐ŸŒŸ [Endpoint ops (#g-endpoint-ops)](https://app.zenhub.com/workspaces/-g-endpoint-ops-current-sprint-63bd7e0bf75dba002a2343ac/board) - โš™๏ธ [Infra (#g-infra)](https://app.zenhub.com/workspaces/-g-infra-642c83a53e96760014c978bd/board) - - - ## Scrum at Fleet - [Sprint ceremonies](#sprint-ceremonies) - [Scrum boards](#scrum-boards) @@ -247,7 +233,7 @@ Before kicking off release QA, confirm that we are using the latest versions of Our goal is to keep these dependencies up-to-date with each release of Fleet. If a release is going out with an old dependency version, it should be treated as a [critical bug](https://fleetdm.com/handbook/engineering#critical-bugs) to make sure it is updated before the release is published. #### Create release QA issue -Next, create a new GitHub issue using the [Release QA template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=&projects=&template=smoke-tests.md&title=). Add the release version to the title, and assign the quality assurance members of the [MDM](https://fleetdm.com/handbook/company/development-groups#mdm-group) and [CX](https://fleetdm.com/handbook/company/development-groups#customer-experience-group) product groups. +Next, create a new GitHub issue using the [Release QA template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=&projects=&template=smoke-tests.md&title=). Add the release version to the title, and assign the quality assurance members of the [MDM](https://fleetdm.com/handbook/company/development-groups#mdm-group) and [Endpoint ops](https://fleetdm.com/handbook/company/product-groups#endpoint-ops-group) product groups. ### Merging during the freeze period We merge bug fixes and documentation changes during the freeze period, but we do not merge other code changes. This minimizes code churn and helps ensure a stable release. To merge a bug fix, you must first unfreeze the PR in [Merge Freeze](https://app.mergefreeze.com/installations/3704/branches), and click the "Unfreeze 1 pull request" text link. @@ -288,7 +274,7 @@ Immediately after publishing a new release, we close out the associated GitHub i 1. **Rename current milestone**: In GitHub, [change the current milestone name](https://github.com/fleetdm/fleet/milestones) from `4.x.x-tentative` to `4.x.x`. `4.37.0-tentative` becomes `4.37.0`. ### ZenHub housekeeping -2. **Update product group boards**: In ZenHub, go to each product group board tracking the current release. Usually, these are [#g-cx](https://app.zenhub.com/workspaces/-g-cx-current-sprint-63bd7e0bf75dba002a2343ac/board) and [#g-mdm](https://app.zenhub.com/workspaces/-g-mdm-current-sprint-63bc507f6558550011840298/board). +2. **Update product group boards**: In ZenHub, go to each product group board tracking the current release. Usually, these are [#g-endpoint-ops](https://app.zenhub.com/workspaces/-g-endpoint-ops-current-sprint-63bd7e0bf75dba002a2343ac/board) and [#g-mdm](https://app.zenhub.com/workspaces/-g-mdm-current-sprint-63bc507f6558550011840298/board). 3. **Remove milestone from unfinished items**: If you see any items in columns other than "Ready for release" tagged with the current milestone, remove that milestone tag. These items didn't make it into the release. @@ -348,7 +334,7 @@ PRs should remain in draft until they are ready to be reviewed for final approva All PRs from the community are routed through the oncall engineer. For documentation changes, the community contact ([Kathy](https://github.com/ksatter)) is assigned by the oncall engineer. For code changes, if the oncall engineer has the knowledge and confidence to review, they should do so. Otherwise, they should request a review from an engineer with the appropriate domain knowledge. It is the oncall engineer's responsibility to monitor community PRs and make sure that they are moved forward (either by review with feedback or merge). #### Customer success meetings -The oncall engineer is encouraged to attend some of the customer success meetings during the week. Post a message to the #g-cx Slack channel requesting invitations to upcoming meetings. +The oncall engineer is encouraged to attend some of the customer success meetings during the week. Post a message to the #g-endpoint-ops Slack channel requesting invitations to upcoming meetings. This has a dual purpose of providing more context for how our customers use Fleet. The engineer should actively participate and provide input where appropriate (if not sure, please ask your manager or organizer of the call). @@ -580,7 +566,7 @@ QA may also propose that a reported bug is not actually a bug. A bug is defined #### Reproduced QA has reproduced the issue successfully. It should now be transferred to engineering. -Remove the โ€œreproduceโ€ label, add the label of the relevant team (e.g. #g-cx, #g-mdm, #g-infra, #g-website), and assign it to the relevant engineering manager. (Make your best guess as to which team. The EM will re-assign if they think it belongs to another team.) [See on GitHub](https://github.com/fleetdm/fleet/issues?q=archived%3Afalse+org%3Afleetdm+is%3Aissue+is%3Aopen+label%3Abug+label%3A%3Aproduct%2C%3Arelease+-label%3A%3Areproduce+sort%3Aupdated-asc+). +Remove the โ€œreproduceโ€ label, add the label of the relevant team (e.g. #g-endpoint-ops, #g-mdm, #g-infra, #g-website), and assign it to the relevant engineering manager. (Make your best guess as to which team. The EM will re-assign if they think it belongs to another team.) [See on GitHub](https://github.com/fleetdm/fleet/issues?q=archived%3Afalse+org%3Afleetdm+is%3Aissue+is%3Aopen+label%3Abug+label%3A%3Aproduct%2C%3Arelease+-label%3A%3Areproduce+sort%3Aupdated-asc+). ##### Fast track for Fleeties Fleeties do not have to wait for QA to reproduce the bug. If you're confident it's reproducible, it's a bug, and the reproduction steps are well-documented, it can be moved directly to the reproduced state. @@ -597,12 +583,12 @@ When fixing the bug, if the proposed solution requires changes that would affect Engineering teams coordinate on bug fixes with the product team during the joint sprint kick-off review. If one team is at capacity and a bug needs attention, another team can step in to assist by following these steps: -For MDM support on CX bugs: -- Remove the `#g-cx` label and add `#g-mdm` label. -- Add `~assisting g-cx` to clarify the bugโ€™s origin. +For MDM support on Endpoint ops bugs: +- Remove the `#g-endpoint-ops` label and add `#g-mdm` label. +- Add `~assisting g-endpoint-ops` to clarify the bugโ€™s origin. -For CX support on MDM bugs: -- Remove the `#g-mdm` label and add `#g-cx` label. +For Endpoint ops support on MDM bugs: +- Remove the `#g-mdm` label and add `#g-endpoint-ops` label. - Add `~assisting g-mdm` to clarify the bugโ€™s origin. @@ -646,13 +632,13 @@ A critical bug is a bug with the `~critical bug` label. A critical bug is define We need to 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 #help-product 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. (We would expect this to be customer experience in the community Slack or QA in the bug inbox, though it could be anyone.) +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. (We would expect this to be Customer success in the community Slack or QA in the bug inbox, though it could be anyone.) 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! Once raised, product confirms whether or not it's critical and defines expected behavior. When outside of working hours for the product team or if no one from product responds within 1 hour, then fall back to the #help-p1. -Once the critical bug is confirmed, customer experience needs to ping both customers and the community to warn them. If CX is not available, the oncall engineer is responsible for doing this. +Once the critical bug is confirmed, Customer success needs to ping both customers and the community to warn them. If Customer success is not available, the oncall engineer is responsible for doing this. If a quick fix workaround exists, that should be communicated as well for those who are already upgraded. When a critical bug is identified, we will then follow the patch release process in [our documentation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Releasing-Fleet.md#patch-releases). diff --git a/handbook/product/README.md b/handbook/product/README.md index 896f289f1a..b1f180ee07 100644 --- a/handbook/product/README.md +++ b/handbook/product/README.md @@ -414,28 +414,28 @@ Directly Responsible Individuals (DRI) engage in the ritual(s) below at the freq | Ritual | Frequency | Description | DRI | |:-----------------------------|:-------------------------|:----------------------------------------------------|-------------------| -| Design sprint review (CX) | Sprintly (Wednesday) | After the last estimation session, the Head of Product reviews the board with each group PM and designer and de-prioritizes all design issues that were not estimated. The Head of Product also collects all items that are product-driven and puts them in the ๐ŸŽ๐Ÿ—ฃ Feature Fest meeting agenda to consider for continuing work. The number of de-prioritized issues should be recorded in the KPI spreadsheet. | Mo Zhu | +| Design sprint review (Endpoint ops) | Sprintly (Wednesday) | After the last estimation session, the Head of Product reviews the board with each group PM and designer and de-prioritizes all design issues that were not estimated. The Head of Product also collects all items that are product-driven and puts them in the ๐ŸŽ๐Ÿ—ฃ Feature Fest meeting agenda to consider for continuing work. The number of de-prioritized issues should be recorded in the KPI spreadsheet. | Mo Zhu | | Design sprint review (MDM) | Sprintly (Thursday) | After the last estimation session, the Head of Product reviews the board with each group PM and designer and de-prioritizes all design issues that were not estimated. The group PM collects all items that were de-prioritized and, if desired, puts them in the ๐ŸŽ๐Ÿ—ฃ Feature Fest meeting agenda to consider for continuing work. The number of de-prioritized issues should be recorded in the KPI spreadsheet. | Mo Zhu | | ๐ŸŽ Feature fest prep | Sprintly (Thursday) | The Head of Product reviews the agenda and pre-comments on items in order to be well-prepared for the discussion. | Mo Zhu | | ๐ŸŽ๐Ÿ—ฃ Feature fest | Sprintly (Thursday) | We make a decision regarding which customer and community feature requests can be committed to in the next six weeks. We create issues for any requests that don't already have one. | Mo Zhu | | ๐ŸŽ Feature fest cleanup | Sprintly (Thursday) | Clean up the agenda in anticipation of the next meeting | Mo Zhu | -| Design sprint kickoff (CX) | Sprintly (Thursday) | the Head of Product introduces and determines the order of the newly prioritized list of work with each group PM | Mo Zhu | +| Design sprint kickoff (Endpoint ops) | Sprintly (Thursday) | the Head of Product introduces and determines the order of the newly prioritized list of work with each group PM | Mo Zhu | | Design sprint kickoff (MDM) | Sprintly (Thursday) | the Head of Product introduces and determines the order of the newly prioritized list of work with each group PM | Mo Zhu | | ๐Ÿ—ฃ Product office hours | Weekly (Tuesday) | Ask questions to the product team | Mo Zhu | -| Sprint Kickoff Review (CX) | Sprintly (Monday) | After each sprint kickoff, the Head of Product reviews the Estimated column with each group PM and de-prioritizes the features that were not included in the sprint and prepares recommended highlights for the release notes. The number of de-prioritized issues should be recorded in the KPI spreadsheet. | Mo Zhu | +| Sprint Kickoff Review (Endpoint ops) | Sprintly (Monday) | After each sprint kickoff, the Head of Product reviews the Estimated column with each group PM and de-prioritizes the features that were not included in the sprint and prepares recommended highlights for the release notes. The number of de-prioritized issues should be recorded in the KPI spreadsheet. | Mo Zhu | | Sprint Kickoff Review (MDM) | Sprintly (Monday) | After each sprint kickoff, the Head of Product reviews the Estimated column with each group PM and de-prioritizes the features that were not included in the sprint and prepares recommended highlights for the release notes. The number of de-prioritized issues should be recorded in the KPI spreadsheet. | Mo Zhu | | Sprint release notes kick-off meeting | Sprintly (Wednesday) | Communicate high-value features from the current sprint to prepare release blog post and drumbeat social posts, etc in the leadup to release at the end of each sprint. Marketing is responsible for getting what they need to publish and promote the release, including a great release post. Product is responsible for helping marketing understand what is coming early enough that there is time to prepare. | Mo Zhu | | โš—๏ธโœจ๐Ÿ—ฃ Design review (MDM) | Daily | Review designs from the MDM team | Marko Lisica | -| โš—๏ธโœจ๐Ÿ—ฃ Design review (CX) | Daily | Review designs from the CX team | Rachael Shaw | +| โš—๏ธโœจ๐Ÿ—ฃ Design review (Endpoint ops) | Daily | Review designs from the Endpoint ops team | Rachael Shaw | | Product development process review | Sprintly | CEO, Director of Product Development, and Head of Product get together to review boards and process to make sure everything still makes sense | Mo Zhu | -| Report number of estimated stories (CX) | Weekly | Report the number of product-driven stories estimated that week to the Head of Product for KPI tracking purposes | Isabell Reedy | +| Report number of estimated stories (Endpoint ops)) | Weekly | Report the number of product-driven stories estimated that week to the Head of Product for KPI tracking purposes | Isabell Reedy | | Report number of estimated stories (MDM) | Weekly | Report the number of product-driven stories estimated that week to the Head of Product for KPI tracking purposes | Noah Talerman | | Maintenance | Weekly (Friday) | Product Operations checks the latest versions of relevant platforms, updates the maintenance tracker, and notifies the #help-product Slack channel. | Isabell Reedy | | Quality check | Daily | Every day, Product Operations will review the "Settled" column on the drafting board to ensure all product action items are complete. | Isabell Reedy | | Bug de-prioritization | Mid-sprint | CEO, Head of Product, and Director of Product Development review the bugs which did not meet the 6-week delivery timeline. Align on next steps for which bugs to schedule into the next sprint and which can be de-prioritized. | Mo Zhu | | Product confirm and celebrate | Weekly (Wednesday) | The Head of Product meets with the designers and product managers to discuss completed user stories. They also verify all updates to documentation, communications, guides, and the pricing and transparency pages, ensuring everything is set for the next steps. | Mo Zhu | -| Pre-sprint prioritization call (CX) | Sprintly (Monday) | The product manager, engineering manager, and product operations meet before each sprint to align on priorities and note what wasn't completed in the previous sprint. Product operations then informs the customer success team about related customer requests. | Mo Zhu | -| Bug review (CX) | Weekly (Tuesday) | The product manager meets with the engineering manager and a product quality engineer to ensure synchronization on bug prioritization and actions preceding CX estimation sessions. | Mo Zhu | +| Pre-sprint prioritization call (Endpoint ops) | Sprintly (Monday) | The product manager, engineering manager, and product operations meet before each sprint to align on priorities and note what wasn't completed in the previous sprint. Product operations then informs the customer success team about related customer requests. | Mo Zhu | +| Bug review (Endpoint ops) | Weekly (Tuesday) | The product manager meets with the engineering manager and a product quality engineer to ensure synchronization on bug prioritization and actions preceding Endpoint ops estimation sessions. | Mo Zhu | | Bug round-up | Mid-sprint | Product Operations will compile a list of churned bugs, including issue numbers, specifics, and age. They will also notify the Customer Success team of any churned bugs that have customer tags | Isabell Reedy | | Churned bug review | Mid-sprint | The Head of Product meets with the group product managers to examine churned bugs and categorize them as either schedule, needs prioritization, or de-prioritize. | Mo Zhu | | Churned bug clean-up | Mid-sprint | Following the bug de-prioritization meeting, Product Operations completes the churned bug clean-up, ensuring all necessary follow-up tasks are actioned to classify bugs as schedule, needs prioritization, or de-prioritized. This may include relocating bug tickets, adjusting labels, communicating with stakeholders, writing documentation, and closing issues. | Isabell Reedy | @@ -454,7 +454,7 @@ This group maintains the following [Slack channels](https://fleetdm.com/handbook |:------------------------------------|:--------------------------------------------------------------------| | `#help-product` | Mo Zhu | | `#g-mdm` | Noah Talerman | -| `#g-cx` | Mo Zhu | +| `#g-endpoint-ops` | Mo Zhu |