mirror of
https://github.com/fleetdm/fleet
synced 2026-05-23 00:49:03 +00:00
"Significant product changes" (#10539)
# Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] Changes file added for user-visible changes in `changes/` or `orbit/changes/`. See [Changes files](https://fleetdm.com/docs/contributing/committing-changes#changes-files) for more information. - [ ] Documented any API changes (docs/Using-Fleet/REST-API.md or docs/Contributing/API-for-contributors.md) - [ ] Documented any permissions changes - [ ] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [ ] Added support on fleet's osquery simulator `cmd/osquery-perf` for new osquery data ingestion features. - [ ] Added/updated tests - [ ] Manual QA for all new/changed functionality - For Orbit and Fleet Desktop changes: - [ ] Manual QA must be performed in the three main OSs, macOS, Windows and Linux. - [ ] Auto-update manual QA, from released version of component to new version (see [tools/tuf/test](../tools/tuf/test/README.md)).
This commit is contained in:
parent
92f47c7716
commit
d696c91dba
1 changed files with 13 additions and 0 deletions
|
|
@ -319,6 +319,19 @@ The following highlights should be considered when deciding if we should leverag
|
|||
|
||||
Fleet's feature flag guidelines is borrowed from GitLab's ["When to use feature flags" section](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) of their handbook. Check out [GitLab's "Feature flags only when needed" video](https://www.youtube.com/watch?v=DQaGqyolOd8) for an explanation of the costs of introducing feature flags.
|
||||
|
||||
## Significant changes
|
||||
|
||||
For product changes that cause major impact for users, or even just create impression of major impact, the company plans migration thoughtfully. That means the product department and E-group:
|
||||
|
||||
1. **Written:** Write a migration guide, even if that's just a Google Doc
|
||||
2. **Tested:** Test out the migration ourselves, first-hand, as an engineer.
|
||||
3. **Gamed out:** We pretend we are one or two key customers and try it out as a role play.
|
||||
4. **Adapt:** If it becomes clear that the plan is insufficient, then fix it.
|
||||
5. **Communicate:** Develop a plan for how to proactively communicate the change to customers.
|
||||
|
||||
That all happens prior to work getting prioritized for the change.
|
||||
|
||||
|
||||
## Competition
|
||||
|
||||
We track competitors' capabilities and adjacent (or commonly integrated) products in Google doc [Competition](https://docs.google.com/document/d/1Bqdui6oQthdv5XtD5l7EZVB-duNRcqVRg7NVA4lCXeI/edit) (private).
|
||||
|
|
|
|||
Loading…
Reference in a new issue