Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Add documentation for experimental features. #10865

Merged
merged 4 commits into from
Sep 22, 2021
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/10865.doc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Add developer documentation about experimental configuration flags.
1 change: 1 addition & 0 deletions docs/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -74,6 +74,7 @@
- [Testing]()
- [OpenTracing](opentracing.md)
- [Database Schemas](development/database_schema.md)
- [Experimental features](development/experimental_features.md)
- [Synapse Architecture]()
- [Log Contexts](log_contexts.md)
- [Replication](replication.md)
Expand Down
37 changes: 37 additions & 0 deletions docs/development/experimental_features.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Implementing experimental features in Synapse

It can be desirable to implement "experimental" features which are disabled by
default and must be explicitly enabled via the Synapse configuration. This is
applicable for features which:

* Are unstable in the Matrix spec (e.g. those defined by an MSC).
clokep marked this conversation as resolved.
Show resolved Hide resolved
* Developers are not confident are ready for use by general Synapse administrators/users
clokep marked this conversation as resolved.
Show resolved Hide resolved
(e.g. a feature is incomplete, buggy, performs poorly, or needs further testing).

Note that this does *not* include features which are not expected to be desirable
clokep marked this conversation as resolved.
Show resolved Hide resolved
to a broad audience. The [module infrastructure](../modules/index.md) should be
investigated for non-standard features.
clokep marked this conversation as resolved.
Show resolved Hide resolved

Guarding experimental features behind configuration flags should help with some
of the following scenarios:

* Ensure that clients do not assume that unstable features exist (failing
gracefully if they do not).
* Unstable features do not become de-facto standards and can be removed
aggressively (since only those who have opted-in will be affected).
* Ease finding the implementation of unstable features in Synapse (for future
removal or stabilization).
* Ease testing a feature (or removal of feature) due to enabling/disabling without
code changes. It also becomes possible to ask for wider testing, if desired.

Experimental configuration flags should be disabled by default (requiring Synapse
administrators to explicitly opt-in), although there are situations where it makes
sense (from a product point-of-view) to enable features by default. This is
expected and not an issue.

It is not a requirement that experimental features require a configuration flag,
but if one should be included if unsure.
clokep marked this conversation as resolved.
Show resolved Hide resolved

New experimental configuration flags should be added under the `experimental`
configuration key (see the `synapse.config.experimental` file) and either explain
(briefly) what is being enabled, or include the MSC number.