From c27cccb767dc7178f1fab9e2050d5f55cf21aef6 Mon Sep 17 00:00:00 2001 From: Luke Heath Date: Fri, 17 Jul 2026 15:23:16 -0700 Subject: [PATCH] Handbook: continuous flow for all product groups (4.91.0) (#49500) --- .claude/skills/aikido-tickets/SKILL.md | 2 +- .github/ISSUE_TEMPLATE/release-qa.md | 2 +- handbook/company/communications.md | 4 +- handbook/company/go-to-market-operations.md | 2 +- handbook/company/open-positions.yml | 4 +- handbook/company/product-groups.md | 384 ++++++------------ handbook/company/why-this-way.md | 17 +- handbook/customer-success/README.md | 4 +- .../customer-success.rituals.yml | 4 +- handbook/engineering/README.md | 16 +- handbook/engineering/engineering.rituals.yml | 12 +- handbook/engineering/releases.md | 14 +- handbook/finance/finance.rituals.yml | 6 +- handbook/it/it.rituals.yml | 4 +- handbook/marketing/README.md | 13 +- handbook/marketing/marketing.rituals.yml | 10 +- handbook/product-design/README.md | 26 +- .../product-design/product-design.rituals.yml | 14 +- ...ogle-chrome-managed-bookmarks.mobileconfig | 2 +- tools/github-manage/cmd/gm/bugs.go | 2 +- tools/github-manage/pkg/ghapi/estimates.go | 2 +- tools/github-manage/pkg/ghapi/projects.go | 33 +- .../github-manage/pkg/ghapi/projects_test.go | 23 +- tools/release/publish_release.sh | 3 +- 24 files changed, 242 insertions(+), 361 deletions(-) diff --git a/.claude/skills/aikido-tickets/SKILL.md b/.claude/skills/aikido-tickets/SKILL.md index 0e7dc79377..afddcb7ab9 100644 --- a/.claude/skills/aikido-tickets/SKILL.md +++ b/.claude/skills/aikido-tickets/SKILL.md @@ -55,7 +55,7 @@ Ask the user for these if not provided: | Team | Label | GitHub Project | |------|-------|----------------| | Orchestration | `#g-orchestration` | https://github.com/orgs/fleetdm/projects/71/ | -| Security & Compliance | `#g-security-compliance` | https://github.com/orgs/fleetdm/projects/97/ | +| Supply Chain | `#g-supply-chain` | https://github.com/orgs/fleetdm/projects/97/ | | MDM | `#g-mdm` | https://github.com/orgs/fleetdm/projects/58/ | | Software | `#g-software` | https://github.com/orgs/fleetdm/projects/70/ | | First Impressions | `#g-first-impressions` | https://github.com/orgs/fleetdm/projects/105/ | diff --git a/.github/ISSUE_TEMPLATE/release-qa.md b/.github/ISSUE_TEMPLATE/release-qa.md index cd7294ed55..f219ae3b2b 100644 --- a/.github/ISSUE_TEMPLATE/release-qa.md +++ b/.github/ISSUE_TEMPLATE/release-qa.md @@ -2,7 +2,7 @@ name: Release QA about: Checklist of required tests prior to release title: 'Release QA:' -labels: '#g-orchestration,#g-apple-at-work,#g-power-to-pc,#g-auto-patching,#g-security-compliance,:release' +labels: '#g-orchestration,#g-apple-at-work,#g-power-to-pc,#g-auto-patching,#g-supply-chain,#g-byod,:release' assignees: 'xpkoala,andreykizimenko,chrstphr84,Brajim20,marcusallen97,thisisjoegrant' --- diff --git a/handbook/company/communications.md b/handbook/company/communications.md index 4f20df7503..34d300dd4a 100644 --- a/handbook/company/communications.md +++ b/handbook/company/communications.md @@ -193,7 +193,7 @@ This works because every Fleetie grants edit access to everyone else at Fleet as ### Shared calendars -Team calendars are the primary source for sprint rituals; they facilitate the execution of each sprint. +Team calendars are the primary source for release rituals; they facilitate the execution of each release cycle. Looking to add, change, or remove a shared calendar? [Create an issue](https://fleetdm.com/handbook/people#contact-us) and the appropriate DRI will reply with feedback. ### 1:1 meetings @@ -504,7 +504,7 @@ When posting about a personal or philosophical topic that potential Fleet custom - Don't show or say customer names, codenames, or real email addresses. **Playback:** -- Don't enable closed captions during sprint demo recording (they're added later if needed). +- Don't enable closed captions during release demo recording (they're added later if needed). ## Feedback diff --git a/handbook/company/go-to-market-operations.md b/handbook/company/go-to-market-operations.md index f0e45f35d1..ac00933c98 100644 --- a/handbook/company/go-to-market-operations.md +++ b/handbook/company/go-to-market-operations.md @@ -205,7 +205,7 @@ There are many times in which community members, customers, and contributors are #### Video -Fleet uses YouTube to help keep the community up-to-date and informed. These videos facilitate community engagement, provide educational resources, and help share essential information about Fleet and the people using it. Meetings regularly uploaded to YouTube will have a "▶️" emoji prepended to the calendar event title (e.g. "▶️ ☁️🌈 Sprint demos!"). +Fleet uses YouTube to help keep the community up-to-date and informed. These videos facilitate community engagement, provide educational resources, and help share essential information about Fleet and the people using it. Meetings regularly uploaded to YouTube will have a "▶️" emoji prepended to the calendar event title (e.g. "▶️ ☁️🌈 Release demos!"). ## Processing intent signals diff --git a/handbook/company/open-positions.yml b/handbook/company/open-positions.yml index 3e4cea3a47..13b0ae7711 100644 --- a/handbook/company/open-positions.yml +++ b/handbook/company/open-positions.yml @@ -182,7 +182,7 @@ onTargetEarnings: "$80,000 - $160,000" responsibilities: | - ⏫ Work closely with engineering to continually improve overall quality assurance efficiency and effectiveness throughout the product design and engineering process. - - 🤝 Collaborate with the engineering managers and quality assurance engineers in the [product groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups), actively participating in some engineering scrum meetings, sprint planning, daily standups, sprint demos, sprint retrospectives, and estimation sessions. + - 🤝 Collaborate with the engineering managers and quality assurance engineers in the [product groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups), actively participating in engineering rituals including daily standups, weekly planning, release demos, and release retros. - 🌟 Contribute to the overall success of all [product groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups) by ensuring users receive valuable new features that work as intended. - 🧪 Develop and execute testing plans based on feature specifications, outlining step-by-step actions for each user role to confirm that features function as intended. - 🚀 Perform manual testing of newly developed features on all supported devices, platforms, and browsers, ensuring a seamless user experience. @@ -195,7 +195,7 @@ - 🎯 Strong attention to detail and ability to identify inconsistencies or deviations from specifications. - 💡 Excellent communication and collaboration skills, with the ability to work closely with engineering and product teams. - 🌐 Experience in manual testing across various devices, platforms, and browsers. - - 🏃‍♂️ Familiarity with agile development processes and scrum methodologies. + - 🏃‍♂️ Familiarity with agile, continuous-flow development processes. - 👥 A customer-centric mindset, focusing on delivering value and a positive user experience. - 🤝 Collaboration: You work best in a participatory, team-based environment. - 🛠️ Technical: You understand the software development processes. diff --git a/handbook/company/product-groups.md b/handbook/company/product-groups.md index 36bce31c38..07890f1655 100644 --- a/handbook/company/product-groups.md +++ b/handbook/company/product-groups.md @@ -24,8 +24,8 @@ At Fleet, [anyone can contribute](https://fleetdm.com/handbook/company#openness) | Role | Responsibilities | |:---------------------|:-----------------| -| Product Designer | Wireframe changes to the product, API, configuration surface, GitOps YAML, CLI, and UI. [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) for product changes in the current sprint. | -| Engineering Manager | Oversee sprint progress, plan and coordinate efforts, technical communication with stakeholders, recruit and mentor engineers. | +| Product Designer | Wireframe changes to the product, API, configuration surface, GitOps YAML, CLI, and UI. [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) for in-progress product changes. | +| Engineering Manager | Oversee day-to-day progress, plan and coordinate efforts, technical communication with stakeholders, recruit and mentor engineers. | | Tech Lead | Oversee day-to-day engineering efforts, assist with user story drafting, support engineers. Capacity is 1/3 support, 2/3 Individual Contributor. | | Quality Assurance | Write and conduct test plans for user stories, report new unreleased bugs, test released bug fixes, conduct smoke testing before each release. | | Software Engineer | [Implement changes](https://fleetdm.com/handbook/company/product-groups#implementing) to the product, provide technical expertise, research user stories, fix bugs, assist with quality assurance. | @@ -33,12 +33,15 @@ At Fleet, [anyone can contribute](https://fleetdm.com/handbook/company#openness) ## Current product groups -| Product group | Goal _(value for customers and/or community)_ | Capacity | -|:------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------|:---------| -| [Orchestration](#orchestration-group) | Increase and exceed maturity in the [orchestration](https://fleetdm.com/orchestration) product category. | 60 | -| [Security & Compliance](#security-compliance-group) | Increase and exceed maturity in the security and compliance product category. | 38 | - -\* The number of [estimated story points](https://fleetdm.com/handbook/product-groups#estimation-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. +| Product group | Goal _(value for customers and/or community)_ | +|:-------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------| +| [Orchestration](#orchestration-group) | Increase and exceed maturity in the [orchestration](https://fleetdm.com/orchestration) product category. | +| [Supply Chain](#supply-chain-group) | Help customers secure the software and dependencies running on their fleet. | +| [Apple @ Work](#apple--work-group) | Increase the number of Apple devices managed by Fleet. | +| [Auto Patching](#auto-patching-group) | Reduce the time before software is patched after vulnerabilities are discovered. | +| [Power to the PC](#power-to-the-pc-group) | Empower Windows users to fully leverage Fleet as an MDM. | +| [BYOD](#byod-group) | Enable Fleet to manage personally-owned Android devices used at work. | +| [Website](#website-group) | Increase and exceed Fleet's product maturity goals for fleetdm.com. | ### Orchestration group @@ -67,9 +70,9 @@ The goal of the orchestration group is to increase and exceed [Fleet's product m > The [Slack channel](https://fleetdm.slack.com/archives/C084F4MKYSJ), [kanban release board](https://github.com/orgs/fleetdm/projects/71), and [GitHub label](https://github.com/fleetdm/fleet/labels/%23g-orchestration) for this product group is `#g-orchestration`. -### Security & compliance group +### Supply Chain group -The goal of the security and compliance group is to increase and exceed Fleet's product maturity goals in the security and compliance category. +The goal of the Supply Chain group is to help customers secure the software and dependencies running on their fleet, reducing exposure to vulnerabilities and ensuring compliance across the device lifecycle. | Responsibility | Human(s) | |:----------------------------------|:--------------------------| @@ -77,9 +80,8 @@ The goal of the security and compliance group is to increase and exceed Fleet's | Engineering Manager | [Sharon Katz](https://www.linkedin.com/in/sharon-katz-45b1b3a/) _([@sharon-fdm](https://github.com/sharon-fdm))_ | Tech Lead | [Juan Fernandez](https://www.linkedin.com/in/juan-fdz-hawa/) _([@juan-fdz-hawa](https://github.com/juan-fdz-hawa))_ | Quality Assurance | [Marcus Allen](https://www.linkedin.com/in/marcus-a-785b3b7/) _([@MarcusAllen](https://github.com/marcusallen97))_ -| Software Engineer | [Dante Catalfamo](https://www.linkedin.com/in/dante-catalfamo-a6330412b/) _([@dantecatalfamo](https://github.com/dantecatalfamo))_ -> The [Slack channel](https://fleetdm.slack.com/archives/C09HG9VMRSS), [kanban release board](https://github.com/orgs/fleetdm/projects/97), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=state%3Aopen%20label%3A%23g-security-compliance) for this product group is `#g-security-compliance`. +> The [Slack channel](https://fleetdm.slack.com/archives/C09HG9VMRSS), [kanban release board](https://github.com/orgs/fleetdm/projects/97), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=state%3Aopen%20label%3A%23g-supply-chain) for this product group is `#g-supply-chain`. **Areas of expertise**: - Software inventory ingestion @@ -94,40 +96,18 @@ The goal of the security and compliance group is to increase and exceed Fleet's ### Product group capacity -Product group capacity is allocated based on our [bug open time KPI](https://docs.google.com/spreadsheets/d/1Hso0LxqwrRVINCyW_n436bNHmoqhoLhC8bcbvLPOs9A/edit?usp=sharing). If the average bug open time is greater than 32 days, 50% of each sprint's total capacity is allocated to bugs and [engineering-initiated stories](https://fleetdm.com/handbook/engineering#create-an-engineering-initiated-story). Allocating less than 50% when above our bug open time KPI requires approval from the CEO. +Product group capacity is allocated based on our [bug open time KPI](https://docs.google.com/spreadsheets/d/1Hso0LxqwrRVINCyW_n436bNHmoqhoLhC8bcbvLPOs9A/edit?usp=sharing). If the average bug open time is greater than 32 days, 50% of each product group's capacity is allocated to bugs and [engineering-initiated stories](https://fleetdm.com/handbook/engineering#create-an-engineering-initiated-story). Allocating less than 50% when above our bug open time KPI requires approval from the CEO. -## Working groups +## Continuous flow -Like a product group at Fleet, a working group is an arrangement of people from different functions. What makes a working group unique is that it is tasked with achieving a high-impact business goal fast. A working group disbands when the goal is achieved so Fleet stays fast and avoids unnecessary process. +Fleet's product groups use a continuous flow process. Well-drafted stories can often be implemented in a day or two, so batching work into fixed multi-week iterations creates unnecessary latency. Instead, issues flow continuously across each product group's board from intake to release. -Working groups are for important work that needs to be done quickly, when asynchronous work would be too slow. +Planning is decoupled from the release boundary. We ship what is complete at each [three-week release](https://fleetdm.com/handbook/company/why-this-way#why-a-three-week-cadence), and fleetd changes follow their own cadence. -Working groups have their own section in the handbook that includes the name, goal, resources, and contributors. See the commented out section in the handbook for an example. +### Roles -Items to cover in the section: -- Name of the working group -- Desired business outcomes (goals) -- Link to the working group Slack channel and GitHub project -- Who is involved. This should include who the DRI is. -- Timeline. When will the working group start? When do we think we'll be done by? - - -### Continuous flow - -Unlike product groups, which use [scrum](#scrum-at-fleet) with 3-week sprints, working groups use a continuous flow process. Well-drafted stories can often be implemented in a day or two, so batching work into 3-week sprints creates unnecessary latency. Instead, issues flow continuously across the working group's board from intake to release. - -#### What is the same - -- **Group roles**: Same group roles and overall responsibilities. -- **Standups**: Daily standups become 30 minutes so fast draft can happen. -- **Weekly planning**: Sprint planning becomes a weekly 1-hour standup. -- **3-week release cadence**: Planning is decoupled from the release boundary. We ship what is complete at each release. fleetd changes follow their own cadence. -- **Release retros**: 30-minute retrospective at the end of each 3-week release. - -#### Roles - -Working groups use the same [product group roles](#product-group-roles), with the following continuous-flow responsibilities: +Product groups use the [group roles](#product-group-roles) above, with the following continuous-flow responsibilities: | Role | Responsibility in continuous flow | |:---------------------|:----------------------------------| @@ -139,9 +119,9 @@ Working groups use the same [product group roles](#product-group-roles), with th > While the PD is responsible for ensuring an issue reaches **Ready**, in practice the EM is most often the one physically moving the issue into the column during standup or weekly planning. -#### DRI areas +### DRI areas -The Roles table covers day-to-day responsibilities. Use this section to determine who owns a given decision within the working group. When two roles overlap, the named DRI has the final call; collaboration is still expected. +The Roles table covers day-to-day responsibilities. Use this section to determine who owns a given decision within the product group. When two roles overlap, the named DRI has the final call; collaboration is still expected. **Engineering Manager** - Cadence and health of all rituals (standup, weekly planning, release demo, release retro). @@ -175,18 +155,18 @@ The Roles table covers day-to-day responsibilities. Use this section to determin - Whether a story meets minimum criteria for testability before it leaves drafting. - Whether a regression warrants a [release-blocker](#all-bugs) call, in coordination with the EM. -#### Item types +### Item types -Working groups use the same six [scrum items](#scrum-items) as product groups: user stories, sub-tasks, timeboxes, bugs, quick wins, and reliability issues. +Product groups use six [work item types](#work-items): user stories, sub-tasks, timeboxes, bugs, quick wins, and reliability issues. -#### Board columns +### Board columns -Each working group runs its own GitHub project board with the following columns, ordered left-to-right: +Each product group runs its own GitHub project board with the following columns, ordered left-to-right: | Column | What it means | |:---|:---| -| 📨 Inbox | Any issue labeled with the working group's `#g-*` label lands here. | -| 🦢 Full draft | The PD is drafting the issue on the formal [drafting board](https://github.com/orgs/fleetdm/projects/67). The issue stays in this column on the working group board until drafting is complete. | +| 📨 Inbox | Any issue labeled with the product group's `#g-*` label lands here. | +| 🦢 Full draft | The PD is drafting the issue on the formal [drafting board](https://github.com/orgs/fleetdm/projects/67). The issue stays in this column on the product group board until drafting is complete. | | 🪿 Fast draft | The team hasn't looked at the issue together yet. Drafting happens in-place on the issue, often during standup or async in the group's Slack channel. | | 🚧 Blocked | The issue is stuck and needs discussion before it can move forward. Try to resolve async first; otherwise raise at the next standup. | | 🥚 Ready | The issue has enough detail to start implementation, though not always enough to finish. | @@ -198,7 +178,7 @@ Each working group runs its own GitHub project board with the following columns, There are no formal WIP limits today, but the group should watch for buildup in any one column. -#### Drafting tracks: full draft vs. fast draft +### Drafting tracks: full draft vs. fast draft The PD decides which stories go through full drafting and is responsible for drafting them. Default to **fast draft**; reserve **full draft** for the highest-risk work. Keeping the full-draft queue small protects PD bandwidth and is a chance for Product Designers to grow their decision-making skills. @@ -206,11 +186,11 @@ The PD decides which stories go through full drafting and is responsible for dra **Fast draft** is the default for everything else: bug fixes, improvements, well-understood patterns, internal tooling, and most new work. The PD collaborates with the team on what guidance is needed to implement the change. This may be a Figma wireframe, a quick sketch, a bulleted list of changes, or a prototype built directly into the product to choose between options. The PD and EM are responsible for escalating to the HPD and/or CTO if needed. If a customer promise or activation blocker is fast-drafted, it should still be t-shirt sized to reduce risk to the customer. -#### Estimation +### Estimation Continuous flow does not use story points or track velocity. [T-shirt sizing](#t-shirt-sizing-capacity-planning) is part of **full draft** and happens async, with anything unresolved discussed at standup. The goal is to minimize the number of stories that require sizing — full draft (and the estimation that comes with it) is reserved for customer promises, activation blockers, and other high-risk work. -#### How issues move +### How issues move - **Inbox → Fast draft or Full draft**: every issue moves into a drafting lane. The PD picks the lane (see above). Bugs and priority issues (P2 or greater) are triaged at the daily standup; stories are triaged at the weekly planning meeting. - **Fast draft → Ready**: stories move to **Ready** only during weekly planning, or during standup if they are a priority story (P2 or greater) or if there is nothing else for the group to work on. The team should review fast-draft bugs at standup but may defer them when more pressing items exist. @@ -218,43 +198,28 @@ Continuous flow does not use story points or track velocity. [T-shirt sizing](#t - **Ready → In progress → Ready for review → Awaiting QA**: the assigned engineer is responsible for moving the issue through these columns as work progresses. - **Awaiting QA → Ready for release**: the QA Engineer is responsible for moving the issue from **Awaiting QA** to **Ready for release** once they have verified the change. -#### Working the board +### Working the board - **Multiple issues in flight is OK.** Contributors can run several agents in parallel and have many issues open at once. Use judgment; don't start more than you can shepherd through review. - **Pick up unassigned work as you finish in-flight items.** When an issue moves to the next column (e.g. Ready for review), pick the next unassigned item from **Ready**. For bugs, use the standard [bug prioritization order](#bug-prioritization). - **Help finish in-flight work when nothing in Ready is available.** Assist with code review, QA, or sub-issues for active stories. - **Hit a blocker or have a question?** It's okay — blockers happen. Move the issue to **Blocked** and try to resolve it async (in the group's Slack channel, with the relevant collaborator, etc.) rather than waiting for standup. If it isn't resolved async, the next standup is the latest it should go without being addressed. -#### Daily standup (30 minutes) +### Daily standup (30 minutes) By-person updates first, then parking lot, then walk the board as time allows. The Inbox is reviewed during standup for bugs and any priority issues (P2 or greater). -#### Weekly planning (1 hour, Monday) +### Weekly planning (1 hour, Monday) -The working group walks the board **right-to-left**, starting at "Ready for release" and moving back toward "Inbox". Stories in the Inbox are triaged during this meeting and either moved straight to **Ready** or assigned a drafting lane. +The product group walks the board **right-to-left**, starting at "Ready for release" and moving back toward "Inbox". Stories in the Inbox are triaged during this meeting and either moved straight to **Ready** or assigned a drafting lane. -#### Release demo (every 3 weeks) +### Release demo (every 3 weeks) -On the last day of each three-week release cycle, working groups demo shipped changes alongside product groups at the [release demo](#sprint-ceremonies). +On the last day of each three-week release cycle, product groups demo shipped changes for the upcoming release alongside stakeholders. Engineers are allotted 3-10 minutes to showcase features, improvements, and bug fixes they contributed. We focus on changes that can be demoed live and avoid overly technical details so the presentation is accessible to everyone. (These meetings are recorded and posted publicly, so participants should avoid mentioning customer names. Instead of a customer name, use a general description like "a publicly-traded hosting company", or the [customer's codename](https://fleetdm.com/handbook/customers#customer-codenames).) -#### Release retro (30 minutes, every 3 weeks) +### Release retro (30 minutes, every 3 weeks) -At the end of every three-week release cycle, the working group holds a 30-minute retro. Action items are created as [`~timebox`](https://github.com/fleetdm/fleet/labels/~timebox) issues, added to the board, and assigned to the EM for the next release cycle. - - -### Working group rollout - -The transition to working groups happens over the following release cycles, following a buffer cycle in 4.87.0 to give everyone time to absorb the handbook change before any team changes: - -| Release | Change | -|:---|:---| -| 4.87.0 | Handbook change published. No team changes this cycle (buffer/ramp-up). | -| 4.89.0 | First Impressions pauses. Power to the PC continues with Konstantin Sykulev and Victor Lyuboslavsky, and continues to own Android. | -| 4.90.0 | MDM becomes Apple @ Work. Software becomes Auto Patching. | -| 4.91.0 | Orchestration product group becomes Digital Employee Experience (DEX). Security & Compliance product group becomes Supply Chain. Both become working groups. | -| TBD | BYOD group spins out from Power to the PC to lead Android device management. | - -> When an engineer moves into a new area of the code, allocate one release cycle for ramp-up. Reduced output during that cycle is expected and planned for. +At the end of every three-week release cycle, the product group holds a 30-minute retro. Action items are created as [`~timebox`](https://github.com/fleetdm/fleet/labels/~timebox) issues, added to the board, and assigned to the EM for the next release cycle. ### Website group @@ -268,7 +233,7 @@ The goal of the website group is to increase and exceed Fleet's product maturity | Quality Assurance | [Eric Shaw](https://www.linkedin.com/in/eric-shaw-1423831a9/) _([@eashaw](https://github.com/eashaw))_ | Software Engineer | [Eric Shaw](https://www.linkedin.com/in/eric-shaw-1423831a9/) _([@eashaw](https://github.com/eashaw))_ -> The [Slack channel](https://fleetdm.slack.com/archives/C097P4TAPRR), [kanban board](https://github.com/orgs/fleetdm/projects/92), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-website) for this working group is `#g-website`. +> The [Slack channel](https://fleetdm.slack.com/archives/C097P4TAPRR), [kanban board](https://github.com/orgs/fleetdm/projects/92), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-website) for this product group is `#g-website`. - ### Power to the PC group -The goal of the Power to the PC working group is to empower Windows users to fully leverage Fleet as an MDM. This group also owns Android device management for the time being, until the BYOD group spins out. +The goal of the Power to the PC group is to empower Windows users to fully leverage Fleet as an MDM. | Responsibility | Human(s) | |:----------------------------------|:--------------------------| -| Product Designer | [Mel Pike](https://www.linkedin.com/in/melpike/) _([@melpike](https://github.com/melpike))_, [Mel Pike](https://www.linkedin.com/in/melpike/) _([@melpike](https://github.com/melpike))_ (Windows), [Noah Talerman](https://www.linkedin.com/in/noah-talerman/) _([@noahtalerman](https://github.com/noahtalerman))_ (Android) -| Engineering Manager | [Luke Heath](https://www.linkedin.com/in/lukeheath/) _([@lukeheath](https://github.com/lukeheath))_ +| Product Designer | [Mel Pike](https://www.linkedin.com/in/melpike/) _([@melpike](https://github.com/melpike))_ +| Engineering Manager | [Sharon Katz](https://www.linkedin.com/in/sharon-katz-45b1b3a/) _([@sharon-fdm](https://github.com/sharon-fdm))_ | Tech Lead | [Victor Lyuboslavsky](https://www.linkedin.com/in/lyuboslavsky/) _([@getvictor](https://github.com/getvictor))_ | Quality Assurance | [Joe Grant](https://www.linkedin.com/in/thisisjoegrant/) _([@thisisjoegrant](https://github.com/thisisjoegrant))_ -| Software Engineer | [Konstantin Sykulev](https://www.linkedin.com/in/konstantins/) _([@ksykulev](https://github.com/ksykulev))_ -> The [Slack channel](https://fleetdm.slack.com/archives/C0AQY8D7FM4), [kanban board](https://github.com/orgs/fleetdm/projects/106/), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-power-to-pc) for this working group is `#g-power-to-pc`. +> The [Slack channel](https://fleetdm.slack.com/archives/C0AQY8D7FM4), [kanban board](https://github.com/orgs/fleetdm/projects/106/), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-power-to-pc) for this product group is `#g-power-to-pc`. ### Apple @ Work group -The goal of the Apple @ Work working group is to increase the number of Apple devices managed by Fleet. +The goal of the Apple @ Work group is to increase the number of Apple devices managed by Fleet. | Responsibility | Human(s) | |:----------------------------------|:--------------------------| @@ -324,12 +287,12 @@ 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-apple-at-work) for this working group is `#g-apple-at-work`. +> 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 product group is `#g-apple-at-work`. ### Auto Patching group -The goal of the Auto Patching working group is to reduce the amount of time before software is patched after vulnerabilities are discovered. +The goal of the Auto Patching group is to reduce the amount of time before software is patched after vulnerabilities are discovered. | Responsibility | Human(s) | |:----------------------------------|:--------------------------| @@ -348,85 +311,26 @@ 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-auto-patching) for this working group is `#g-auto-patching`. +> 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 product group is `#g-auto-patching`. - - - - +> The [Slack channel](https://fleetdm.slack.com/archives/C0BK050C3BJ), [kanban board](https://github.com/orgs/fleetdm/projects/112), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-byod) for this product group is `#g-byod`. -### Publish sprint demo video +### Publish release demo video -After each sprint demo, the marketing team is responsible for doing a quick post-production pass on the recording and publishing it. +After each release demo, the marketing team is responsible for doing a quick post-production pass on the recording and publishing it. -1. **Download the sprint demo recording** +1. **Download the release demo recording** This video is recorded and found in Gong. If the video is not uploaded, reach out to the CTO and Head of Product Design in the #help-marketing channel. @@ -370,7 +370,7 @@ After each sprint demo, the marketing team is responsible for doing a quick post 6. **Upload the video to Youtube** Follow the steps to [upload the video to YouTube](#upload-to-youtube). - Make sure the YouTube title follows the pattern `Sprint-demo - ` (eg. "Sprint demo - 4.82.0"). + Make sure the YouTube title follows the pattern `Release-demo - ` (eg. "Release demo - 4.82.0"). Add a brief description highlighting the new features. @@ -379,7 +379,7 @@ After each sprint demo, the marketing team is responsible for doing a quick post ### Upload to YouTube -Fleet regularly uploads a variety of content to YouTube such as podcast episodes, sprint demos, educational updates, design reviews, and more. +Fleet regularly uploads a variety of content to YouTube such as podcast episodes, release demos, educational updates, design reviews, and more. - Login to the Fleet YouTube channel, click the create button and then upload the video. - Fill out relevant information such as: @@ -423,6 +423,9 @@ Although details on how to format and meta tag a blog are in [the writing handbo #### Stubs The following stubs are included only to make links backward compatible +##### Publish sprint demo video +Please see [handbook/marketing#publish-release-demo-video](https://fleetdm.com/handbook/marketing#publish-release-demo-video) + ##### Programs Please see [handbook/company/communications#product-marketing-programs](https://fleetdm.com/handbook/company/communications#product-marketing-programs) diff --git a/handbook/marketing/marketing.rituals.yml b/handbook/marketing/marketing.rituals.yml index 2863498f42..ca383c0ce2 100644 --- a/handbook/marketing/marketing.rituals.yml +++ b/handbook/marketing/marketing.rituals.yml @@ -1,8 +1,8 @@ - - task: "Prioritize for next sprint" # Title that will actually show in rituals table + task: "Prioritize for next release cycle" # Title that will actually show in rituals table startedOn: "2023-09-04" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday frequency: "Triweekly" - description: "Using your departmental kanban board, prioritize and finalize next sprint's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing: description: "[Prioritizing next sprint](https://fleetdm.com/handbook/company/communication)" + description: "Using your departmental kanban board, prioritize and finalize next release cycle's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing: description: "[Prioritizing next release cycle](https://fleetdm.com/handbook/company/communication)" moreInfoUrl: "https://fleetdm.com/handbook/company/why-this-way#why-make-work-visible" #URL used to highlight "description:" test in table dri: "mikermcneil" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title) - @@ -40,14 +40,14 @@ task: "Process pending swag requests" # Title that will actually show in rituals table startedOn: "2025-04-02" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday frequency: "Daily" # must be supported by - description: "Complete draft orders." # example of a longer thing: description: "[Prioritizing next sprint](https://fleetdm.com/handbook/company/communication)" + description: "Complete draft orders." # example of a longer thing: description: "[Prioritizing next release cycle](https://fleetdm.com/handbook/company/communication)" moreInfoUrl: "https://fleetdm.com/handbook/marketing#process-pending-swag-requests-from-the-website" #URL used to highlight "description:" test in table dri: "irenareedy" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title) - - task: "Publish ☁️🌈 Sprint demos" + task: "Publish ☁️🌈 Release demos" startedOn: "2023-11-03" frequency: "Triweekly" - description: "Every release cycle, upload the ☁️🌈 Sprint demos video to YouTube" + description: "Every release cycle, upload the ☁️🌈 Release demos video to YouTube" moreInfoUrl: "https://fleetdm.com/handbook/marketing#upload-to-youtube" dri: "irenareedy" autoIssue: diff --git a/handbook/product-design/README.md b/handbook/product-design/README.md index accc7e8b96..ed94bf364b 100644 --- a/handbook/product-design/README.md +++ b/handbook/product-design/README.md @@ -34,9 +34,9 @@ Fleet's roadmap flows in this order (from highest to lowest fidelity): ### Triage new requests -The Head of Product Design is responsible for going through the inbox on the [drafting board](https://github.com/orgs/fleetdm/projects/67) and adding the correct [working group](https://fleetdm.com/handbook/company/product-groups#working-groups) label. +The Head of Product Design is responsible for going through the inbox on the [drafting board](https://github.com/orgs/fleetdm/projects/67) and adding the correct [product group](https://fleetdm.com/handbook/company/product-groups#continuous-flow) label. -Once labeled, each working group's Product Designer (PD) is responsible for reviewing the inbox and deciding whether each new request contributes to Fleet's [product maturity](https://fleetdm.com/handbook/company/product-maturity-assessment) goals for the current calendar year. If yes, the PD adds the `~product-maturity` and `:product` labels so the request is reviewed at the next [unpacking the why](#unpacking-the-why) call. If a request doesn't meet these criteria but meets a different [criteria for prioritization](https://fleetdm.com/handbook/company/product-groups#criteria-for-prioritization), the PD removes the "Unpacked" checkbox in the feature request issue and either prioritizes a [user story or quick win](https://fleetdm.com/handbook/company/product-groups#scrum-items) to bring through [fast draft or full draft](https://fleetdm.com/handbook/company/product-groups#drafting-tracks-full-draft-vs-fast-draft), or sets it aside and adds it to the [feature fest](https://fleetdm.com/handbook/company/product-groups#feature-fest) board. +Once labeled, each product group's Product Designer (PD) is responsible for reviewing the inbox and deciding whether each new request contributes to Fleet's [product maturity](https://fleetdm.com/handbook/company/product-maturity-assessment) goals for the current calendar year. If yes, the PD adds the `~product-maturity` and `:product` labels so the request is reviewed at the next [unpacking the why](#unpacking-the-why) call. If a request doesn't meet these criteria but meets a different [criteria for prioritization](https://fleetdm.com/handbook/company/product-groups#criteria-for-prioritization), the PD removes the "Unpacked" checkbox in the feature request issue and either prioritizes a [user story or quick win](https://fleetdm.com/handbook/company/product-groups#work-items) to bring through [fast draft or full draft](https://fleetdm.com/handbook/company/product-groups#drafting-tracks-full-draft-vs-fast-draft), or sets it aside and adds it to the [feature fest](https://fleetdm.com/handbook/company/product-groups#feature-fest) board. ### Unpacking the why @@ -85,8 +85,8 @@ 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-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. + - For example, if a #g-apple-at-work Product Designer drafts a story that #g-supply-chain will implement, the #g-apple-at-work Product Designer invites the #g-supply-chain Tech Lead to #g-apple-at-work design reviews. Once the story is approved, it’s brought to #g-supply-chain user story review. + - At that point, the #g-supply-chain 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. > @@ -120,16 +120,16 @@ changing specifications while ensuring that Fleet meets our brand and quality gu You'll know it's time for expedited drafting when: - The team discovers that a drafted user story is missing crucial information that prevents contributors from continuing the development task. - A user story is taking more effort than was originally estimated, and Product Designer (PD) wants to find ways to cut aspects of planned functionality in order to still ship the improvement in the currently scheduled release. -- A user story on the drafting board wasn't estimated by the last estimation session in the current sprint and cannot wait until the next sprint. This can also happen when we decide to bring a user story in mid-sprint. +- A user story on the drafting board wasn't estimated by the last estimation session in the current release cycle and cannot wait until the next release. This can also happen when we decide to bring a user story in mid-release cycle. What happens during expedited drafting? 1. If we cut planned functionality, the PD notifies the [customer support DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris). Up to the PD to let the customer support DRI know if we're still planning on building the functionality in a later release and if so, when. The customer support DRI should confirm that the updated scope and/or timeline still meets the requester's needs. 2. The PD notifies the [DRI for what goes in a release](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) (release DRI), Head of Product Design, and the relevant product group's Engineering Manager (EM) in the `#help-leadership` Slack channel. - - If the user story wasn't "Ready for spec" by the last estimation session, decision to allow the user story to make it into the next engineering sprint is up to the release DRI. - - If the user story is in the current engineering sprint and there are significant changes to the requirements, then the user story might be pushed to the next sprint. Decision is up to the release DRI. -3. Drafts are updated, changes [are approved](https://fleetdm.com/handbook/company/development-groups#drafting-process), and the user story is estimated or brought back into the current sprint. + - If the user story wasn't "Ready for spec" by the last estimation session, decision to allow the user story to make it into the next engineering release cycle is up to the release DRI. + - If the user story is in the current engineering release cycle and there are significant changes to the requirements, then the user story might be pushed to the next release. Decision is up to the release DRI. +3. Drafts are updated, changes [are approved](https://fleetdm.com/handbook/company/development-groups#drafting-process), and the user story is estimated or brought back into the current release cycle. ### Consider a feature eligible to be flagged @@ -180,14 +180,14 @@ The Head of Product Design (HPD), Product Designers (PD), and the relevant Custo If the original request is a customer request, it's up to the relevant CSA to decide if the request is fulfilled. If it is, we assign the relevant Customer Success Manager (CSM) and add the `:help-customers` label to add the customer request to the [🌦️ :help-customers board](https://github.com/orgs/fleetdm/projects/79). -### Notify stakeholders when a user story is pushed to the next sprint +### Notify stakeholders when a user story is pushed to the next release -[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: +[User stories](https://fleetdm.com/handbook/company/product-groups#work-items) are intended to be [drafted](#drafting) and estimated in a single release cycle. 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-apple-at-work, #g-auto-patching, #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 relevant [product group's](https://fleetdm.com/handbook/company/product-groups#current-product-groups) Slack channel. -> Instead of waiting until the end of the sprint, notify stakeholders as soon as you know the story is being pushed. +> Instead of waiting until the end of the release cycle, notify stakeholders as soon as you know the story is being pushed. ### Update a company brand front @@ -212,6 +212,8 @@ When a new major macOS version is announced, it's the Head of Product Design's r #### Stubs The following stubs are included only to make links backward compatible. +##### Notify stakeholders when a user story is pushed to the next sprint +Please see [handbook/product-design#notify-stakeholders-when-a-user-story-is-pushed-to-the-next-release](https://fleetdm.com/handbook/product-design#notify-stakeholders-when-a-user-story-is-pushed-to-the-next-release). diff --git a/handbook/product-design/product-design.rituals.yml b/handbook/product-design/product-design.rituals.yml index 74b045e2de..462f828ccc 100644 --- a/handbook/product-design/product-design.rituals.yml +++ b/handbook/product-design/product-design.rituals.yml @@ -1,8 +1,8 @@ - - task: "🦢📊 Product design sprint review" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes - startedOn: "2024-03-07" - frequency: "Triweekly" - description: "1. For all stories, targeted for the next sprint, that are not estimated, update their milestone. 2. For stories that we're no longer working on, remove them from the drafting board, remove them from the release planning board, and notify stakeholders. 3. Prepare the '🎁 Feature fest' board." + task: "🦢📊 Product design review" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes + startedOn: "2024-03-07" + frequency: "Triweekly" + description: "1. For all stories, targeted for the next release cycle, that are not estimated, update their milestone. 2. For stories that we're no longer working on, remove them from the drafting board, remove them from the release planning board, and notify stakeholders. 3. Prepare the '🎁 Feature fest' board." moreInfoUrl: dri: "noahtalerman" - @@ -13,7 +13,7 @@ moreInfoUrl: "https://fleetdm.com/handbook/company/product-groups#feature-fest" dri: "noahtalerman" - - task: "Product design sprint kickoff" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes + task: "Product design kickoff" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes startedOn: "2024-03-07" frequency: "Triweekly" description: "1. Pull up all contributors' calendars to review time off and, if needed, update design review calendar events. 2. Create reference docs release branches for any milestones newly added to the drafting board 3. For feature requests prioritized during feature fest, add user stories to the drafing and release planning boards, add milestones to the stories, confirm available capacity in targeted release, and align on priorities." @@ -105,14 +105,14 @@ task: "📝 Understanding our competitor(s)" startedOn: "2026-01-26" frequency: "Weekly" - description: "For each user story in the current design sprint, find a solution using our competitor(s) tools. Discuss how this solution affects how we're thinking about the Fleet solution. For each story, do we just want to be as good as our competitor(s)? Better?" + description: "For each user story in the current release cycle, find a solution using our competitor(s) tools. Discuss how this solution affects how we're thinking about the Fleet solution. For each story, do we just want to be as good as our competitor(s)? Better?" moreInfoUrl: dri: "noahtalerman" - task: "Review reference docs for upcoming release" startedOn: "2025-10-20" frequency: "Triweekly" - description: "After sprint kickoff: 1. Check for API design PRs on estimated stories that were not brought into the sprint, then @-mention the product designer to request documentation changes be reverted. 2. Check for unmerged API design PRs on the release docs branch (filter: is:pr is:open base:docs-vX.X.X). For stories that made it into the sprint, merge the PR. For stories that did not make it in, close the PR and @-mention the author." + description: "After kickoff: 1. Check for API design PRs on estimated stories that were not brought into the release cycle, then @-mention the product designer to request documentation changes be reverted. 2. Check for unmerged API design PRs on the release docs branch (filter: is:pr is:open base:docs-vX.X.X). For stories that made it into the release cycle, merge the PR. For stories that did not make it in, close the PR and @-mention the author." moreInfoUrl: "" dri: "rachaelshaw" autoIssue: diff --git a/it-and-security/lib/macos/configuration-profiles/google-chrome-managed-bookmarks.mobileconfig b/it-and-security/lib/macos/configuration-profiles/google-chrome-managed-bookmarks.mobileconfig index f512b246ff..b474ca7239 100644 --- a/it-and-security/lib/macos/configuration-profiles/google-chrome-managed-bookmarks.mobileconfig +++ b/it-and-security/lib/macos/configuration-profiles/google-chrome-managed-bookmarks.mobileconfig @@ -530,7 +530,7 @@ name - 🛡️ Current sprint (#g-security-compliance) + 🛡️ Current sprint (#g-supply-chain) url https://github.com/orgs/fleetdm/projects/97 diff --git a/tools/github-manage/cmd/gm/bugs.go b/tools/github-manage/cmd/gm/bugs.go index ee373ba264..c10529ab2a 100644 --- a/tools/github-manage/cmd/gm/bugs.go +++ b/tools/github-manage/cmd/gm/bugs.go @@ -31,7 +31,7 @@ type BugIssue struct { } `json:"labels"` } -var productGroupLabels = []string{"#g-software", "#g-orchestration", "#g-mdm", "#g-security-compliance"} +var productGroupLabels = []string{"#g-software", "#g-orchestration", "#g-mdm", "#g-supply-chain"} func (i BugIssue) ProductGroup() string { for _, label := range i.Labels { diff --git a/tools/github-manage/pkg/ghapi/estimates.go b/tools/github-manage/pkg/ghapi/estimates.go index 73c225057c..e723ef264a 100644 --- a/tools/github-manage/pkg/ghapi/estimates.go +++ b/tools/github-manage/pkg/ghapi/estimates.go @@ -12,7 +12,7 @@ import ( // when syncing to Releases: drafting and product group projects. func DefaultEstimateSourceProjects() []int { // unique list; ignore releases itself (87) as a source - return []int{Aliases["draft"], Aliases["mdm"], Aliases["g-software"], Aliases["g-orchestration"], Aliases["g-security-compliance"]} + return []int{Aliases["draft"], Aliases["mdm"], Aliases["g-software"], Aliases["g-orchestration"], Aliases["g-supply-chain"]} } // GetEstimateFromProject returns the numeric estimate for an issue from a specific project. diff --git a/tools/github-manage/pkg/ghapi/projects.go b/tools/github-manage/pkg/ghapi/projects.go index 3b2a6cd56a..461acb9d61 100644 --- a/tools/github-manage/pkg/ghapi/projects.go +++ b/tools/github-manage/pkg/ghapi/projects.go @@ -13,25 +13,28 @@ import ( ) var Aliases = map[string]int{ - "mdm": 58, - "g-mdm": 58, - "draft": 67, - "drafting": 67, - "g-software": 70, - "soft": 70, - "g-orchestration": 71, - "orch": 71, - "sec": 97, - "g-security-compliance": 97, - "releases": 87, + "mdm": 58, + "g-mdm": 58, + "draft": 67, + "drafting": 67, + "g-software": 70, + "soft": 70, + "g-orchestration": 71, + "orch": 71, + "sec": 97, + "g-supply-chain": 97, + "byod": 112, + "g-byod": 112, + "releases": 87, } // ProjectLabels maps project IDs to their corresponding label filters for the drafting project var ProjectLabels = map[int]string{ - 58: "#g-mdm", // mdm project - 70: "#g-software", // g-software project - 71: "#g-orchestration", // g-orchestration project - 97: "#g-security-compliance", // g-security-compliance project + 58: "#g-mdm", // mdm project + 70: "#g-software", // g-software project + 71: "#g-orchestration", // g-orchestration project + 97: "#g-supply-chain", // g-supply-chain project + 112: "#g-byod", // g-byod project } // ResolveProjectID resolves a project identifier (alias or numeric string) to a project ID. diff --git a/tools/github-manage/pkg/ghapi/projects_test.go b/tools/github-manage/pkg/ghapi/projects_test.go index 9d768a97b1..f427936bb4 100644 --- a/tools/github-manage/pkg/ghapi/projects_test.go +++ b/tools/github-manage/pkg/ghapi/projects_test.go @@ -124,16 +124,19 @@ func TestParseJSONtoProjectItems(t *testing.T) { func TestAliases(t *testing.T) { expectedAliases := map[string]int{ - "mdm": 58, - "g-mdm": 58, - "draft": 67, - "drafting": 67, - "g-software": 70, - "soft": 70, - "g-orchestration": 71, - "orch": 71, - "sec": 97, - "g-security-compliance": 97, + "mdm": 58, + "g-mdm": 58, + "draft": 67, + "drafting": 67, + "g-software": 70, + "soft": 70, + "g-orchestration": 71, + "orch": 71, + "sec": 97, + "g-supply-chain": 97, + "byod": 112, + "g-byod": 112, + "releases": 87, } if !reflect.DeepEqual(Aliases, expectedAliases) { diff --git a/tools/release/publish_release.sh b/tools/release/publish_release.sh index 7634efaa29..70d853f971 100755 --- a/tools/release/publish_release.sh +++ b/tools/release/publish_release.sh @@ -390,7 +390,8 @@ create_qa_issue() { --assignee "AndreyKizimenko" --label "#g-apple-at-work" --label ":release" \ --label "#g-auto-patching" \ --assignee "xpkoala" --label "#g-orchestration" \ - --label "#g-security-compliance" + --label "#g-supply-chain" \ + --label "#g-byod" rm -f temp_qa_issue_file fi else