mirror of
https://github.com/fleetdm/fleet
synced 2026-05-24 01:18:42 +00:00
Add sectin and DRIs (#5336)
This commit is contained in:
parent
ed66fac362
commit
1582ff4a05
2 changed files with 20 additions and 2 deletions
|
|
@ -28,6 +28,8 @@ DRIs help us collaborate efficiently by knowing exactly who is responsible and c
|
|||
| Quality of fleetctl (and other tools) | Tomás Touceda |
|
||||
| Final cut of what goes into each release | Zach Wasserman |
|
||||
| When we cut a release, version numbers, and whether to release | Zach Wasserman |
|
||||
| When a feature is advertised as "beta" | Zach Wasserman |
|
||||
| When a feature is placed behind a feature flag | Zach Wasserman |
|
||||
| Release notes | Noah Talerman |
|
||||
| Documentation quality | Mike Thomas |
|
||||
| Publishing release blog post, and promoting releases | Mike Thomas |
|
||||
|
|
|
|||
|
|
@ -372,14 +372,30 @@ comment section may contain private information about Fleet's customers.
|
|||
|
||||
Find an example release customer announcement blog post issue [here](https://github.com/fleetdm/confidential/issues/747).
|
||||
|
||||
## Beta features
|
||||
|
||||
At Fleet, features are advertised as "beta" if there are concerns that the feature may not work as intended in certain Fleet
|
||||
deployments. For example, these concerns could be related to the feature's performance in Fleet
|
||||
deployments with hundreds of thousands of hosts.
|
||||
|
||||
The following highlights should be considered when deciding if we promote a as "beta:"
|
||||
|
||||
- The feature will not be advertised as "beta" permanently. This means that the individual who is directly
|
||||
responsible (DRI) that a feature is advertised as "beta" is responsible for creating an issue that
|
||||
explains why the feature is advertised as "beta" and tracks the feature's progress towards advertising the feature as "stable."
|
||||
- The feature will be advertised as "beta" in the documentation on fleetdm.com/docs, release notes, release blog posts, and Twitter.
|
||||
|
||||
## Feature flags
|
||||
|
||||
In Fleet, features are placed behind feature flags if the changes could affect Fleet's availability of existing functionalities.
|
||||
At Fleet, features are placed behind feature flags if the changes could affect Fleet's availability of existing functionalities.
|
||||
|
||||
The following highlights should be considered when deciding if we should leverage feature flags:
|
||||
|
||||
- The feature flag must be disabled by default.
|
||||
- The feature flag will not be permanent. This means that the individual who decides that a feature flag should be introduced is responsible for creating an issue to track the feature's progress towards removing the feature flag and including the feature in a stable release.
|
||||
- The feature flag will not be permanent. This means that the individual who is directly responsible
|
||||
(DRI) that a feature flag should be introduced is responsible for creating an issue to track the
|
||||
feature's progress towards removing the feature flag and including the feature in a stable
|
||||
release.
|
||||
- The feature flag will not be advertised. For example, advertising in the documentation on fleetdm.com/docs, release notes, release blog posts, and Twitter.
|
||||
|
||||
Fleet's feature flag guidelines was 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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue