mirror of
https://github.com/fleetdm/fleet
synced 2026-05-24 09:28:54 +00:00
Air guitar process: add issue template & update process (#26808)
Co-authored-by: Sam Pfluger <108141731+Sampfluger88@users.noreply.github.com>
This commit is contained in:
parent
ed12731475
commit
3195d0f974
2 changed files with 53 additions and 14 deletions
46
.github/ISSUE_TEMPLATE/air-guitar.md
vendored
Normal file
46
.github/ISSUE_TEMPLATE/air-guitar.md
vendored
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
name: 🎸 Air guitar
|
||||
about: Request wireframes to be designed right away
|
||||
title: '🎸 ____________'
|
||||
labels: ['~air-guitar', ':product']
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
<!-- **This is an air guitar: https://fleetdm.com/handbook/company/product-groups#initiate-an-air-guitar-session -->
|
||||
|
||||
|
||||
## Goal
|
||||
|
||||
| User story |
|
||||
|:---------------------------------------------------------------------------|
|
||||
| As a _________________________________________,
|
||||
| I want to _________________________________________
|
||||
| so that I can _________________________________________.
|
||||
|
||||
## Context
|
||||
|
||||
<!-- Requesters leave this section blank. -->
|
||||
|
||||
- Product designer: _________________________ <!-- Who is the product designer to contact if folks have questions about the UI, CLI, or API wireframes? -->
|
||||
|
||||
<!--
|
||||
What else should contributors [keep in mind](https://fleetdm.com/handbook/company/development-groups#developing-from-wireframes) when working on this change? (Optional.)
|
||||
1.
|
||||
2.
|
||||
-->
|
||||
|
||||
## Changes
|
||||
|
||||
<!-- Requesters leave this section blank. -->
|
||||
|
||||
### Product
|
||||
- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. Make sure wireframes show the UI down to 768px (min screen width). Put "No changes" if there are no changes to the user interface. -->
|
||||
- [ ] CLI (fleetctl) usage changes: TODO <!-- Insert the link to the relevant Figma cover page. Put "No changes" if there are no changes to the CLI. -->
|
||||
- [ ] YAML changes: TODO <!-- Specify changes in the YAML files doc page as a PR to the reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. -->
|
||||
- [ ] REST API changes: TODO <!-- Specify changes in the the REST API doc page as a PR to reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. Move this item to the engineering list below if engineering will design the API changes. -->
|
||||
- [ ] Fleet's agent (fleetd) changes: TODO <!-- Specify changes to fleetd. If the change requires a new Fleet (server) version, consider specifying to only enable this change in new Fleet versions. Put "No changes" if there are no changes necessary. -->
|
||||
- [ ] GitOps mode changes: TODO <!-- Specify UI changes for read-only GitOps mode. Put "No changes" if there are no changes necessary. -->
|
||||
- [ ] Activity changes: TODO <!-- Specify changes to the Audit log page in the contributor docs. Put "No changes" if there are no changes necessary. -->
|
||||
- [ ] Permissions changes: TODO <!-- Specify changes in the Manage access doc page as a PR to the reference docs release branch. If doc changes aren't necessary, explicitly mention no changes to the doc page. Put "No changes" if there are no permissions changes. -->
|
||||
- [ ] Once wireframes are approved, notify the requestor.
|
||||
|
|
@ -230,26 +230,19 @@ These questions are helpful for the product team when considering what to priori
|
|||
|
||||
Anyone in the product group can initiate an air guitar session.
|
||||
|
||||
1. Initiate: Create a user story and add the `~air-guitar` label to indicate that it is going through the air guitar process. Air guitar issues are always intended to be designed right away. If they can't be, the requestor is notified via at-mention in the issue (that person is either the CSM or AE).
|
||||
1. [Create a new air guitar issue](https://github.com/fleetdm/fleet/issues/new?template=air-guitar.md). Air guitar issues are always intended to be designed right away. If they can't be, the Head of Product Design notifies the requestor (normally a CSM or AE) via at-mention in the issue.
|
||||
|
||||
> An air guitar session may be used to design features that won't be shipped.
|
||||
|
||||
2. Prioritize: Bring the user story to [feature fest](https://fleetdm.com/handbook/product#rituals). If the user story is prioritized, proceed through the regular steps of specifying and designing as outlined in the drafting process. However, keep in mind that these are conceptual and may or may not proceed to engineering.
|
||||
2. If the air guitar is prioritized, it's assigned to a Product Designer who brings it through the [drafting process](https://fleetdm.com/handbook/company/product-groups#drafting). However, keep in mind that these are conceptual and may or may not proceed to engineering.
|
||||
|
||||
> An air guitar session may be needed before the next feature fest. In this case, the Product Designer will prioritize the user story.
|
||||
3. When the wireframes are approved, assign the requester to the issue, at-mention them to let them know that the wireframes are ready, remove the `:product` label, and add the appropriate label(s) to move the issue to the requester's board (`:help-customers` for CSMs and `#g-unicorns` for AEs). The requester (CSM or AE) will then bring the wireframes to a call with the customer or prospect to collect feedback. It's up to the requester to record feedback and add Gong snippets to the issue.
|
||||
|
||||
3. Review: Conduct an air guitar meeting where the idea or feature is discussed. Involve roles like the product manager, designer, and a sampling of engineers to provide various perspectives.
|
||||
4. After feedback has been added to the issue, the requester adds the `:product` label and assigns the issue to the Head of Product Design to determine an outcome:
|
||||
|
||||
4. Feedback: Collect internal feedback and iterate on the design. Optionally, conduct customer interviews or gather external feedback.
|
||||
|
||||
5. Document: Summarize the learnings, decisions, and next steps in the user story issue.
|
||||
|
||||
6. Decide: Assign the issue to the Head of Product Design to determine an outcome:
|
||||
1. Move forward with the formal drafting process leading to engineering.
|
||||
2. Keep it open for future consideration.
|
||||
3. Discard if it is invalidated through the process.
|
||||
|
||||
Air guitar sessions are timeboxed to ensure they are fast and focused. Documentation from this process may inform future user stories and can be invaluable when revisiting the idea at a later stage. While the air guitar process is exploratory in nature, it should be thorough enough to provide meaningful insights and data for future decision-making.
|
||||
- Move forward with the formal drafting process leading to engineering.
|
||||
- Keep it open for future consideration.
|
||||
- Discard if it is invalidated through the process.
|
||||
|
||||
|
||||
### Implementing
|
||||
|
|
|
|||
Loading…
Reference in a new issue