This outlines a new patch branching strategy to avoid the conflicts
we've been running into recently.
This will introduce more friction in the form of two PRs for released
bug fixes during patch weeks. The benefit is that we won't have to deal
with merge conflicts when we're cherry-picking commits into the patch
branch, which sometimes becomes a big distraction for the team.
We also found ourselves in a situation with 4.46.3 where we couldn't
release a fix without rewriting it because it had been built on top of
feature code that was not included in the patch. That was the motivation
to make this change.
---------
Co-authored-by: George Karr <georgekarrv@users.noreply.github.com>
Co-authored-by: Sam Pfluger <108141731+Sampfluger88@users.noreply.github.com>
Changes:
- Fixed two broken links on the digital experience handbook page
- Updated link text and removed a broken link on the engineering
handbook page.
Also updated the language in the notification process slightly so that
we only notify impacted customers and the community if community
features are impacted.
Changes:
- Removed Markdown links from ritual descriptions (and added them to the
moreInfoUrl value of the rituals)
- Updated the "Generate merged schema" ritual to be weekly, and added a
`moreInfoUrl` value.
- Fixed the ritual table on the sales handbook page.
---------
Co-authored-by: Sam Pfluger <108141731+Sampfluger88@users.noreply.github.com>
This PR consolidates various subheadings into one list that appears
"above the fold" to make it easier for contributors to find the info
they are looking for on the page. As it was previously, important info
was getting buried under the "Connect to Dogfood" instructions, which
gave the wrong impression about the scope of the page content.
Closes: #14246
Changes:
- Added a new key to the rituals YAML configuration: `autoIssue.repo`.
This value should be a string that is the name of the GH repo that
issues for the ritual should be created in.
- Updated ritual validation in `build-static-content`.
- Added support for the "monthly" ritual frequency for rituals with an
`autoIssue` value.
- Updated the `create-issues-for-todays-rituals` script to create GitHub
issues for rituals.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Co-authored-by: Sam Pfluger <108141731+Sampfluger88@users.noreply.github.com>
We will begin conducting postmortems for critical bugs in addition to
outages.
1. How was the bug introduced?
2. What is the gap in our testing process that we didn't find the bug
before it was released?
3. How are we going to change our testing (both manual and automated) so
that we will catch a similar bug in the future?
Why? We want to start evaluating the three questions above for every
critical bug so that we can learn and improve our processes.
- Add Isabell to team table
- reorder contact-us in leadership page
- Standardize "Contact us" on all departmental pages
- Convert all responsibilities to imperative mood verb phrase
- Untangle and deduplicate Engineering <> Product groups <> Product
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
Related issue: https://github.com/fleetdm/fleet/issues/15089
Changes:
- Added a new engineering ritual to check the Slack invitation linked to
from Fleet and the Fleet website. (Slack invitations expire after 400
people have accepted the invitation)
- "Head of Product" => "Head of Product Design"
- #help-product => #help-product-design
- "Sprint kickoff review" is now one ritual that includes both MDM and
Endpoint ops teams
- "Pre-sprint prioritization" ritual is now one ritual that includes
both MDM and Endpoint ops teams
- Remove "Sprint release notes kickoff" ritual. Plan is to inform
#g-demand of new features asynchronously. Any discussion that needs to
happen live will happen at product office hours
- Remove "Report number of estimated stories (Endpoint ops))" and
"Report number of estimated stories (MDM)" rituals. One person (Head of
Product Design) is both reporting and tracking product KPIs
- Remove "Bug de-prioritization" ritual. Trying this instead: ~~CEO,~~
Head of Product Design, and Head of Product Development align on next
steps for which bugs to schedule into the next sprint and which can be
de-prioritized during the "Churned bug review" ritual. Less meetings.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Closes: https://github.com/fleetdm/confidential/issues/4015
Changes:
- Changed the url for `/fleetctl-preview` to
`/try-fleet/fleetctl-preview`
- Updated the controller for the `/fleetctl-preview` page to redirect
non-logged-in users to `/try-fleet/login`
- Removed the route for `/try-fleet/sandbox-expired`, and added a
redirect going to `/try-fleet/fleetctl-preview`.
- Updated the controller for `/try-fleet/sandbox` to redirect the users
without a non-expired Sandbox instance to `/try-fleet/fleetctl-preview`.
- Updated `signup.js` to not provision Fleet sandbox instances for
users.
- Updated the `User` model to support a third `signupReason`: "Try
Fleet"
- Updated `/try-fleet/register` to submit "Try Fleet" as a
`signupReason` when users sign up.
- Renamed the files for the `/fleetctl-preview` page (`get-started` »
`fleetctl-preview`)
- Updated/removed Fleet Sandbox related handbook sections.
- Replaced the "Fleet vs Fleet Sandbox" section in the deploying
documentation with a note about `fleetctl preview`.
- Updated links to Fleet Sandbox in articles.
---------
Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com>
Adding the annual ritual to make sure our Cert is always valid for new
customers to generate Push certificates. ...
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
I want to highlight:
1. That we only demo features, improvements, and bug fixes. (not all
accomplishments might be unrelated to the release)
2. Specify that we want the content of the presentations to be
accessible to everyone and not too technical.
---------
Co-authored-by: George Karr <georgekarrv@users.noreply.github.com>
1. Process to formalize how we prioritize bugs across teams, recognize a
bug's origin, and indicate the team who is currently working on it.
2. Formalize that this coordination will happen at a joint sprint
kick-off review (there are currently separate sprint kick-off reviews
for each team).
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>