Policy for adding features to LocalGov Drupal

[finnlewis]

Come from https://github.com/localgovdrupal/localgov/issues/466

The issue of adding autsave_form to the localgov profile has highlighted the question of how we decide what features to add and enable by default in the distribution.

I've started drafting a policy here: https://github.com/localgovdrupal/localgov/wiki/%5BDraft%5D-Policy-for-adding-a-new-feature,-functionality-or-modules-to-LocalGov-Drupal

Initially I think it would be good to answer the questions:

1. Does more than one council want this feature? / Does a significant proportion of our users want this feature?
2. Can the feature be disabled after installation without any dependency problems?
3. Does the product group / product owner / product lead want to prioritise this feature?
4. Will this enhancement be communicated to users with an existing installation? (e.g. release notes / README.md / drupal_set_message )

It would also be good to identify the different ways a feature can be included and supported in LocalGov Drupal.

a) included and enabled by default in the localgov installation profile b) included in the codebase but not enabled by default c) not included in the codebase, but supporting the integration, meaning users would need to manually install the feature

I know that @willguv has been thinking about this from the product group perspecitve and we hope to talk more about it this week.

[keelanfh]

I think there's a wider conversation in here as well about how changes that are added to LocalGov Drupal can be meaningfully rolled out to existing users.

Is there something we can do here around educating councils on how best to handle this? I think this would apply to:

• new features like this
• styling/CSS changes for councils that are overwriting localgov_base
• default config changes (e.g. layouts of content editing pages #487)

It's a tricky question because some of these things will have an impact on the user experience, not all councils may want them, and they may interact with customisation that one council has done.

But I think if we don't help councils with this, we run the risk of having divergent codebases running in different councils, and limit the ability for councils to benefit from new features in the distribution, or in particular, changes to existing features.

One thought could be some best practices on applying customisation to LGD?

[markconroy]

We have a great feature in localgov paragraphs or localgov layouts module which allows for full width backgrounds and background colours that we ported from microsites, but no current council can avail of it as it's not enabled via any update hooks.

For the 2 sites I am currently working on, as they are new sites I am enabling it by default for them, but I bet other existing sites would like these features too.

[finnlewis]

The wider converstion about releasing updates to configuration to existing installations is important, hopefully we will be able to pick it up with a reformed 'product group / product owner' team soon. Good release notes and other communications channels are important to let people know of changes. If we release a change in installation configuration that is optional for existing installs, we need to release notes on how to implement this change should you want it.

I do think the distribution is still indended to be a starting point rather than a finished product and I assume most councils will add to the codebase and augment the configuration to their own needs, so in most cases automatically updating configuration would not be cool. But maybe there is scope for some sort of setting in that says "opt into automated configuration udpates" that we check in update hooks.

[andybroomfield]

Config Distro provides a way to sync and merge config updates from modules whilst trying to preserve the config changes the site builders have made. Its what we have used with BHCC to selectivly import localgov configuration changes when no update hooks present.

[andybroomfield]

I tend to err on the side of, if something is a dependancy then it must be something that is required. For anything else suggestions are usually the way forward. Profiles are a bit different, in that they are including modules for functionality that isn't sticlty nessecary, and in Localgovs case both localgov modules are installed but not enabled, but also thrid party modules such as Gin Login.

There is also the case of treating profiles as a framework to build upon, whilst at the same time providing an out the box experince of what Localgov drupal should be. Sometimes these two points clash, as what if a council team wants to use a different set of modules to what has included, they now have 'dead weight' code installed, and if it then gets enabled by default to support a feature (and switching it on would likly win support if it is already installed) they have to now work around that.

It seems there is scope for potentially three profiles:

• Minimal, perhaps just localgov_core and localgov_base and then gets out the way.
• Standard, what we have now, enough to get you started without being too opionated
• Maxi, council website in a box, doing everything the Localgov Drupal reccomended way.

This does mean though maintaining 3 profiles, and potentially 3 projects so could be more maintaince than avalible from the team.

Noting that council teams can still install whatever extra modules they desire, though managing conflicts is up to them.

There is also the need to consider councils current hosting amongst requirements, and trying to avoid extra incurred costs. This conversation came about because adding a module which makes round trips to the server would add cost to those hosted on a provider that counts that against traffic quota. Having a feature that adds significantly to the hosting bill can act as a deterrant in upgrading, or add significant work to having to work around it.

[willguv]

Pulling in @andybroomfield's comments from elsewhere

Would we be looking at a scoring system, or just something more generic? Are we looking at the main localgov profile being more of a framework that councils build with, or more of a finished product whose feautre set is static?

Let's discuss this next time

Also need to consider a modules securirty support status, release state (activly maintaned, fixes only, abandoned?), Is it a full release, or beta / alpha / dev version only? does it need patches to work correctly? Are there other modules or processes a council is using / would use instead and would they raise complications with the proposed module? Does any feature change / module also change the hosting requirements (updates to apache / PHP / MySQL) or dramatically increase number of website requests.

[willguv]

Proposal here: https://docs.google.com/document/d/1OCs3W7WFGtDNpL0U-6lhT6pQpOf2RydjtpkAMOrUeI4/edit?usp=sharing

[willguv]

Thanks everyone for looking at this policy. I’ve dropped Ben, Angie, Jamie and Michael a line to see if they would like to respond. It’s definitely safe enough to try and we can amend at a later date if needed