An Early Access section in the configuration for testing features that are under development

My idea is:

I think that we should have a way to provide features that are still in development to Mautic users so that they can test them and provide feedback. Currently we don’t have any way to do this (which was a challenge with the new builder, for example).

Here is a screencast with some basic wireframes:

I think these groups of people would benefit from this idea:

Developers - get feedback on a feature before it is released
Marketers - early access to new features that are ‘in the pipeline’ and clarity of what status they are in so that you can decide whether to enable them or not
Mautic project - a better way to get new features in front of people without shipping by default with Core

Any code or resources to support this idea:

Happy to work with someone to develop the idea (and also hopefully to tie in with the Marketplace initiative!)

Are you willing to work on this idea?:

Yes, in an advisory capacity

What skills and resources do you need to explore this further?

  • Developers to help create the infrastructure
  • UX folk to help with making the experience really slick for the users
1 Like

Great idea! That way it’s also very easy for folks to enable early access features. I remember with the GrapesJS builder is was quite painful to set up (installing the plugin, clearing the cache, etc.) - you basically already needed access to the CLI in order to enable it properly.

It’d probably be good to have some minimum requirements for all levels of early access, like

  • Alpha: can be installed easily, but no guarantee that data is kept across updates - there can still be BC breaks which means folks would have to completely reinstall the feature or Mautic itself for a clean state
  • Beta: can be installed easily and “best effort” data consistency - at this stage, there very likely won’t be BC breaks anymore, unless a critical bug or design flaw is found. Updating to newer versions should also be painless & smooth unless stated otherwise
  • Release Candidate: can be installed easily, guaranteed data consistency - (auto-)updating to future versions will be smooth, just like the release version

This is similar to what Microsoft is doing with their Release Channels (dev, beta, release preview)

In terms of scalability, I think it’d be great to have a setting called allow_enabling_beta_features (or similar) so that companies like Webmecanik and Acquia can disable it for their customers. If their customers would enable such features, it could lead to increased support calls while their support agents won’t be able to help with a feature (yet).

1 Like

Are we using the “Update stability level” in config for anything?

This is used when updating Mautic - it determines what releases to make available to you (for example if you are set to Stable you will never be offered to update to an alpha, beta or Release Candidate release).

So, this is used at the global Mautic level - what I have suggested would enable a similar option but it would allow us to list out official core features or settings that are not yet in Stable (eg they are alpha, beta or Release Candidate) so that folk can decide to install or enable them.