The band is back together, and we've got a new horn section! The original dev team line-up of Finn, Stephen, Ekes, Adnan (Croydon) and Andy (BHCC) has been hugely enriched with the addition of Maria, Richard, Dan and core Drupal maintainer Mark Conroy from Annertech!
We've finished sprint 1 on Tuesday (and started sprint 2 on Wednesday) and the project is gathering momentum once again. Following the spirit of ‘public money, public code’, and the Local Digital Declaration, we are still working in the open and aiming to publish regular sprint notes to keep anyone who is interested in the loop. This is the first of 10 sprints of development funded by the MHCLG's LocalDigital Fund and overseen by Cumbria County Council.
Sprint goals
We kicked off with an ambitious list of sprint goals for sprint 1, splitting these into product goals (technical work that contributes immediately to improving the code and functionality) and project goals (non-technical work to build evidence and governance processes to help increase longer term sustainability). Here are the sprint goals as defined at the start of sprint 1.
Product goals
- New release methodology (approved, documented, implemented)
- Drupal 9 upgrade testing architecture
- Documentation for Drupal 9 upgrade.
- Drupal 9 branch/s ready for demo
- Front end architecture improvements: new localgov_base theme
- Updated demo content for the whole product.
- Prepare requirements for sprint 2 / estimated backlog (e.g. alert banners / news)
- Project and Research goals
- Produce a shared theory of change for the project
- Confirm our research priorities, strategy and outputs and a research Plan for User Research
- Develop some user personas to formalise what we know.
- Produce a project / product plan arc across the whole beta project, and clarity on the different strands of work (eg economics).
[TL;DR] We didn't quite score all the goals, but we did really well. read on below for a little about the each of the main areas of work completed in the sprint. You can also see the list of issues that are considered 'Done - sprint 1' on the LocalGov Drupal Beta phase project board.
Release methodology and 1.0.0
From the start we've tried to make LocalGov Drupal modular and we aim to keep dependencies to a minimum. This has led us to separate functionality into discrete projects – 30 of them at last count! The main composer project template requires the core dependencies which then cascade down through the projects to build the codebase. So the modularity adds complexity and we need a strategy to keep released version numbers in line.
Now that we have sites in production and are upgrading to Drupal 9, we've decided to tag all releases at 1.0.0 for the Drupal 8 branch, dropping the -alpha suffix. We are following semantic versioning, so the 1.0.0 release acknowledges the stability of the projects that are already in production for a number of councils while also committing to not making breaking changes between minor version releases. See https://github.com/localgovdrupal/localgov/releases/tag/1.0.0.
Drupal 9 upgrade testing
n recent months we've been involved with the Drupal distributions meetup, where we've been talking to the developers from a number of established distributions such as Thunder, Droopler, OpenSocial, Launchpad. We learnt that the Thunder development team automate testing of upgrades between all major versions of Drupal, so naturally we thought this sounded like a very good idea indeed!
Stephen produced a testing methodology similar to Thunder's, where the tests first install an old database backup from a Drupal 8 installation before running the updates on the Drupal 9 codebase. The automated tests can then be run to confirm all is as expected. This should help to catch any new issues in the upgrade path as we continue to build new features.
Theory of Change
Three hours in a workshop is perhaps a daunting prospect, but in this case it was well worth the effort. Richard led the team through the process of thinking about the high level project goals, the outcomes that we want to see that support these goals, and the activities that will generate said outcomes. This all builds the Theory of Change planning triangle, which can be seen on this publicly accessible Miro board.
https://miro.com/app/board/o9J_lF7TOjE=/
We plan to return to this at various points to confirm the activities that we are working on in our sprints are contributing to the outcomes and goals of the project. This is a great way to keep the project on track and to help new members of the team to understand the bigger picture.
Demo Content
We've had a demo site up for a while for people to test functionality. We also have the localgov_demo module which provides default content through the default_content module. However, as is often the case, the functionality of the distribution has raced ahead of the demo content module, so we're left with some ‘content debt’.
This manifested in a large content management task to create lots of content on the dev site that we could then bake into the localgov_demo module, allowing a test installation to display a decent representation of the variety of content types and how they all hang together.
Having lots of default demonstration content is beneficial in three main ways:
- It allows someone installing for the first time to enable the demo content module to explore the content types and structures.
- We can test examples of the content for styling, user experience and accessibility.
- We can automate tests of a Drupal 8 to Drupal 9 upgrade.
Thanks to Maria (Agile Collective) and Ben Hills-Jones (Croydon / Cumbria) for the considerable effort on this!
Research plan
We're delighted to have Alexandra Clark from Telltale Research on the team to provide expertise in user research. Understanding our users is critical to the success of the project, if we are to drive adoption and grow the LocalGov Drupal community.
The research plan currently has three main strands:
- Research with Current Users (councils)
- Research with Potential Users (councils)
- Research with End Users (public)
In the first strand we are keen to talk to content designers, developers and decision makers about their experience with LocalGov Drupal so far. We are keen to learn from their experiences and suggestions for how to improve.
The second strand will take the form of a survey sent out to a wider number of councils, with interviews to follow up on a selection of those. We are hoping to hear from councils who do not already use Drupal as well as those that do.
The third strand will come a little later in the project and will hopefully allow us to build evidence for which design patterns are working well for users and which are not, possibly extending to some user testing on prototypes for new features.
Future governance of LocalGov Drupal
The long term sustainability of the LocalGov Drupal project is very much on our minds. While there is core funding from the MHCLG, it is possible for Will Callaghan, me and the wider team at Agile Collective to continue to guide and coordinate the work, but future funding is by no means guaranteed. We need to use this beta phase to encourage a culture of self governing teams within the wider LocalGov Drupal community. There are at least 11 councils and 10 suppliers involved with a range of skills, interests, and available time, and we all want the project to continue to grow sustainably.
Over the next few sprints we will be learning a little more about how Sociocracy might be used to help shape our governance processes and actively looking at how working groups can help to delegate work and decision making around specific new features.
If you have any thoughts, questions or suggestions do let us know on Twitter @localgovdrupal / @agilecollective or just drop us a line on hello@agile.coop.
