Agile Collective currently is working with developers and managers at Croydon Council and Brighton & Hove City Council (among other councils) to refactor existing Drupal 8 code and configuration shared between the two councils into a more generic Drupal Distribution, aptly named LocalGov Drupal.
The aim is to provide an open source baseline to help UK councils set up public-facing publishing platforms, with less cost and less time, in Drupal 8 or 9. Following a successful discovery phase earlier in the year, the MHCLG provided funding for this alpha phase to allow us to rework the code in line with discovery recommendations and test this functionality with other UK councils.
We’re now two sprints in and following the spirit of the Local Digital Declaration by “working in the open wherever we can, sharing our plans and experience, working collaboratively with other organisations, and reusing good practice”. So we are working in the open on Github and sharing our progress as we go through blog posts and public issue queues and sprint boards.
Working fully in the open is a very different feeling to working in a private code repository. All code and comments are visible to anyone in the world, which I think encourages an enhanced level of care, rigour and consistency that might end up being deprioritised when working on standard client projects behind closed doors with client pressures to deliver quantity over quality.
It is a privilege to be able to deploy a full time project team to work alongside council developers and product owners to produce an open source solution to a common problem, which has only been made possible by the funding from the MHCLG.
What we’re thinking about
The alpha problem statement: How can we create a Drupal distribution that will be flexible enough for use by many UK councils, and easy for all to contribute to and maintain?
What we’ve been doing
In sprint 1 the team focussed on project infrastructure and baseline architecture. We established the open source project on Github (https://github.com/localgovdrupal), set up the repositories with packagist to allow for an easy install with composer, following Drupal 8 best practice. See https://github.com/localgovdrupal/localgov for details. Getting the infrastructure in place and making architectural decisions takes time, but hopefully lays a solid foundation for open source collaboration to grow. Standardised local development environments on Lando, ensuring automated test coverage with PHPUnit and following a strict pull request workflow will all help to encourage contribution and consistent quality.
Services information architecture
In sprint 1 we brought in the three core content types that comprise the huge quantity of services content on Croydon and BHCC’s sites. In sprint 2 we spent time delving deeper into the intended information architecture and navigation between service landing pages, service sub-landing pages and service pages. Various references between these content types needed rationalising with naming conventions confirmed. With the knowledge that other content types might want to opt in to the services information architecture at a later point, we took time to architect this as flexibly as possible. Interestingly, this service based ‘spoke and hub’ information architecture has evolved from Clearleft’s work on the Brighton & Hove City Council site and has also been followed by Kensington & Chelsea Council, also working with Clearleft. A post on the Kensington & Chelsea Council website clearly illustrates “How the website is structured”, giving us further confidence that this information architecture works for at least three councils.
In sprint 2 our focus also moved on to the base theme. The Croydon Council site theme evolved from the Brighton & Hove theme, so we’ve taken the former as the starting point and have started the process of stripping out any Croydon specific naming or functionality. This is still in its nascent form, but we have a basic theme that does not mention Croydon in it anymore. https://github.com/localgovdrupal/localgov_theme.
While developers can run the installation locally, it is important to be able to view progress and demonstrate the evolving functionality to non-developer stakeholders, so we’ve set up a demo site with some demo content for development purposes, https://localgovdrupal.agile.coop/service-status. In time we hope to have a permanent demo site so that people can test the functionality quickly and easily.
A common thread throughout our work is to try to reduce dependencies wherever possible. We are conscious that our primary audience is a council who wants to take the distribution as a starting point and build on top of it, but other councils will want to make use of a single feature such as local directories or step-by-step content. We are aiming to architect the distribution in such a way that it is possible for such features to be used without the full distribution, but this dependency separation is a multidimensional nightmare at times and takes time to get right!
What we’ll be doing next
In sprint 3 we will be:
- starting work on the step-by-step and guide page functionality,
- furthering the theme work to improve the presentation of services content and related content
- automating the testing on Github CI which should save time when reviewing pull requests
- confirming the usage of the topic taxonomy to relate content and improve admin user experience
Luckily we have more front end developer resources from Croydon Council to help with the theme work and we are hoping that developers from other councils will start to join the development team to help us increase the velocity.
It takes time to refactor code, configuration and naming conventions while teasing apart dependencies, but we are convinced that it is worth putting in the effort now to create a robust, scalable but flexible architecture upon which to grow. We’ve made good progress and continue to work well together. If you have developer resources to contribute to the project, please let us know and get involved at the Github project.