Multi-council Drupal code sharing: Discovery, Sprint 2 notes

Croydon, Brighton and Hove, Bracknell Forest, and Oxford City Councils have joined forces to understand how councils co-develop and share open-source website code on Drupal. Here’s everything we’ve posted so far.

What we’re thinking about

Discovery problem statement: “How might we help councils co-develop, share and maintain open-source code for their citizen-facing websites?”

We finished our second sprint of the discovery work we’re conducting as part of an MHCLG Local Fund project. In this sprint, we focussed our efforts on:

• analysing the interviews conducted with 10 councils in the first sprint
• finishing our code and theme audits on the existing codebase shared between Brighton and Hove and Croydon Councils
• researching ways of facilitating decision-making between different organisations that work on the same codebase (product managers and other tech members)
• researching how to formalise the collaboration among the participating councils in a way that is proportionate to the flexibility of discovery and alpha phases

What we’ve been doing

Analysis of the interviews so far

We started our analysis by documenting all our observations from the research sessions on a Miro board. This is a fun exercise to immerse ourselves in the richness of the qualitative data that’s coming out of the research with councils.

 

The second pass of that data is to group them under a few themes that help us make certain conclusions and assumptions under what problem we’re trying to solve, how codesharing can help these problems, and how codesharing can work in practice

 

We are now in the process of organising our findings in a switching forces model. This will enable us to design our alpha proposal that we’d like to test with users. By building on the problems that councils currently have, and solving them with a new approach that deals with their worries, the model below gives us a good steer about our vision, but also informs us where where our proposition might not apply.

 

Code and theme audits

We completed code and theme audits into the shared codebase owned by Brighton and Hove and Croydon Councils. The audits had some interesting findings for us to consider on our way to a potential alpha:

1. The back end code needs to be structured properly to better enable sharing from scratch and allow the optional selection of components required – our research shows this flexibility is essential to bring more people on board.
2. The front end theme needs similar work to make it more flexible, and to enable councils to stamp their own brand on the site. If councils joined the project at this point they would incur some technical debt, which is obviously not the best way to begin.

It’s also essential that we document all the inter-dependencies between the current architecture of the codebase and the way components, modules and other Drupal entities are built, and how they are named. Since the aim of the project is to open up the codebase to a larger group of councils, we are working to also document how we might untangle some of those dependencies.

How to take decisions, governance and coding standards

In parallel to user research and the technical discovery, the team has been busy researching how it might look like for Councils to work together on the same codebase. This raises questions around joiners and leavers, taking product-related decisions, and contributors and committers into the code.

To that end, we’ve drafted a Memorandum of Understanding (MoU). We’d like to test with councils whether it gives enough assurance to them to start working together and outlines a basic division of responsibilities. The MoU introduces two governance groups: the Product Group (PG) and the Technical Group (TG).

1. The Product Group involves product managers and technical leads from TG, and is responsible for the overall direction of the project, its architecture and governance, its roadmap, and its quality standards.
2. The Technical Group involves committers representing the required technical expertise to resolve disputes when necessary. They are also responsible for git repo hosting, managing the list of committers, and maintaining the development process and coding standards. Some of its members also join the PG.

Within the PG, we also looked into how different product managers might work together. As the project grows, we are proposing a three-cluster approach that plays into each PM’s strengths and their time-availability that might change from sprint to sprint.

We believe each product manager from participating councils can play an important role that is often one PM’s responsibility. That’s why we propose that we test this model in Alpha where a new PM joins the project either in the Account or Research cluster to get socialised into the project, digests the research so far, and understands the logistics of the project. That means they can gradually move in and out of clusters as they feel fit and comfortable. We also know that not every PM will be able to participate in Drupal-based conversations, so we will rely on the Technical cluster of PMs for those activities.

One last element that we’re looking into is how decisions are taken. There are many different models out there, such as lazy consensus or majority voting. We’d like to keep decision-making in the project as flexible as possible, and we suggest that only the most important decisions require a consensus, whilst others might depend on available participants taking a decision while others might not have the time to investigate the issue. We’re also being inspired by different prioritisation matrices, primarily the one from the GOV.UK team.

In sum, we’re documenting all of this thinking in a draft MoU that we might be able to test with some councils either in the last sprint of discovery, or in a potential alpha.

What’s next?

• We’re going into the last sprint of the discovery work. We’ve also submitted an alpha bid to MHCLG, and are waiting for their feedback.
• We’re having conversations with developers involved from the councils to see how they react to our proposed architecture and Drupal components
• We will test our draft MoU and decision-making models with volunteering councils
• Our end of discovery show and tell is on 10 March, in dxw digital’s offices in Hoxton, as well as on Google Hangouts. Get in touch if you’d like to get an invite for it.