Design decision 7 - Experimental features

Summary

Issue

There has never been any easy way to test out experimental features on WET. If anyone was to create a new CSS class or JavaScript plugin on WET, they would have to test it on their local machine, constraining its exposure amongst other things.

There are also numerous of other reasons to come up with this approach, such as:

To circumvent that, the WET community came up with a solution.

Proposed solution

Every new GCWeb release now contains a set of experimental features. In order to use any of the features, whether it is a CSS class or a Javascript plugin, one can simply wrap such feature around an element containing the “.experimental” class.

With that solution, a contributor can easily add new features to GCWeb to try them out and a publisher/developer can easily implement them on any page.

Approach

The experimental features approach is designed to try new things that could eventually make it to the standard/stable version of GCWeb or WET, not to brake their progress or to diverge without any supervision. In that sense, if proper documentation for a plugin or a style doesn’t come sometimes after its release as an experimental feature, it will eventually be dropped instead of making it to the standards.

For instance, if someone would add an experimental feature to turn the Canada.ca website red at version 5.2 and then wouldn't document it (functionnality, possibilities, examples, etc.) by version 5.3, the feature would get flagged for removal upon next minor or major version, which in this case would be 5.4 or 6.0 respectively.

Important notices

Experimental features are unstable and are to be used at your own risk.

An overall documentation page on experimental features and their current statuses is also available.

Temporary features

This solution works great with temporary features that would be needed only for a certain period of time and that should not be used afterwards.