Clarify feature flag status in PROCESS.md
This commit is contained in:
parent
e4c61726b4
commit
422efcd823
10
PROCESS.md
10
PROCESS.md
|
@ -110,6 +110,16 @@ picked into the stable branches) up to the 19th of the month. Such merge
|
||||||
requests should have the ~"feature flag" label assigned, and don't require a
|
requests should have the ~"feature flag" label assigned, and don't require a
|
||||||
corresponding exception request to be created.
|
corresponding exception request to be created.
|
||||||
|
|
||||||
|
A level of common sense should be applied when deciding whether to have a feature
|
||||||
|
behind a feature flag off or on by default.
|
||||||
|
|
||||||
|
The following guideliness can be applied to help making this decision:
|
||||||
|
|
||||||
|
* If the feature is not fully ready or functioning, feature flag should be disabled by default
|
||||||
|
* If the feature is ready but there are concerns with performance or impact, feature flag should be enabled by default but feature flag
|
||||||
|
disabled via chatops before deploy on GitLab.com environments. If the performance concern is confirmed, the final release should have the feature disabled
|
||||||
|
* In most other cases, feature flag can be enabled by default
|
||||||
|
|
||||||
In order to build the final package and present the feature for self-hosted
|
In order to build the final package and present the feature for self-hosted
|
||||||
customers, the feature flag should be removed. This should happen before the
|
customers, the feature flag should be removed. This should happen before the
|
||||||
22nd, ideally _at least_ 2 days before. That means MRs with feature
|
22nd, ideally _at least_ 2 days before. That means MRs with feature
|
||||||
|
|
Loading…
Reference in New Issue