A year in the LGD Developer role. What can we achieve today?

The LocalGov Drupal (LGD) Lead Developer role has been the most challenging role of Tony Barker’s career so far. In this blog, he reflects on a year that has stretched his skills, challenged his thinking and opened doors to opportunities he never imagined.

A year ago, I stepped into the role of LocalGov Drupal Lead Developer. It has been the most challenging role of my career so far, but also one of the most rewarding.

How do you maintain more than 90 Drupal modules used by over 70 councils? How do you manage change upstream, downstream and across all those modules? And how do you do that effectively?

After a year, I think I’ve started to figure it out: with a little help from my friends.

LGD’s incredible community

When I titled this blog, I meant the “we” in “What can we achieve today?” literally.

I truly feel privileged to be playing a role at the heart of technical development in such an important project for so many millions of people who depend on their public services.

In recent weeks I have been working through reviewing many accessibility and UI improvements to forms. In the first 30 minutes of testing the forms with a screenreader I realised that there is so much potential for positive impact in this area. There are so many brilliant examples of work being done in the LocalGov Drupal community, like the award-winning PDF importer, that can benefit people around the globe.

The list of credits over this year starts to get ridiculous, and to try to name people risks leaving out those who deserve equal credit. Contributions matter big and small. In my first years using Drupal I asked so many questions of others who were generous with their time. People who engage and ask questions are already contributing — sharing experience that improves the product, and taking the first step.

We need Open Source software to be freely available, and to trust that people will step up to contribute where they can, and where a feature is compelling and interesting to them. Where we need to focus is making those contributions as frictionless as possible, so that contribution is more of a pleasure and less of a chore.

The lead developer role: one year in

With all these contributions, what is the Lead Developer’s role? I think there are three functions: One is having oversight of a family of large Drupal distributions and accompanying features that require deep immersion to even begin to architect. Two is to listen, learn, support, review and offer guidance to contributors. Three is the far-from-glamorous work that keeps the base stable and sets up people to thrive.

My own growth

I’ve grown a lot, both personally and professionally, during this role. My first Merge Tuesday was back in the summer of 2025, deputising for LGD Technical Lead Finn Lewis. It took several minutes for my nerves to settle so I could use my mouse properly, encouraged by a nurturing and supporting group of friendly faces. 

Learning communication and interaction from LGD team members Finn, Aaron Hirtenstein, Tim Hunt and Will Callaghan helped me toward compèring DrupalCamp England in the Spring. By the time I chaired the tech drop-in at the end of July there was no such sign of the nerves.

Looking back to the LocalGov Drupal Camp in the Summer of 2025, with six months of focused contribution and a learning curve under my belt as I converted from a Front End Specialist to a LocalGov Drupal specialist, using my knowledge of the Drupal ecosystem as a basis for new features and best practices, I presented twice: With Anthony Lindsay, as Annertech were announced as the LocalGov Drupal developer, and with Finn, where we presented on how LocalGov Drupal sits within an ecosystem.

And it’s here where the magic really happens – using Drupal’s powerful features in the LocalGov Drupal distribution and vice versa. In April, Gareth Alexander of the University of Edinburgh and I took "Same image, different story: why Drupal needs contextual architecture" to the Drupal Dev Days stage in Athens, the third instalment after DrupalCamp Scotland and DrupalCamp England. 

Working alongside members of the LocalGov Drupal community to improve media and accessibility formed part of the research for the work upstream in Drupal: the architectural gaps that lead to poor editorial decisions and compromised accessibility show up clearly when you have 70 councils publishing every day.

Athens was the point where we stopped cataloguing problems and started proposing fixes. If the research develops as I hope, it will benefit every Drupal user.

Understanding the Drupal environment

And this is one of the keys to sustained success for the project: understanding that ecosystem, from the building blocks of coding languages and Symfony, through Drupal Core and Contrib, the LocalGov specific modules and the production stacks of councils.

Early on in 2026, I led the development of ‘Local’, a Drupal CMS site template for local organisations, a demonstration of Site Templates, and of Drupal Canvas with ECA, to help drive those features forward.

Keeping abreast of innovation and upcoming upstream changes means that we can be more proactive and less reactive. We can also influence what happens upstream in our contribution.

We have a set of guiding principles and, as a generalisation, the further upstream a change can happen the better: more sites can use the code, it gets more activity and more scrutiny. Although I asked “What can we achieve today?”, moving upstream is not always fast.  Features can begin their journeys in custom code or LocalGov modules and mature. The LocalGov Alert Banner and LocalGov Events to Finders work are examples of features that are maturing to be stronger in general contribution.

There are exceptions, and they matter enormously to councils and residents: identity, character and localisation. A council's site should look and feel representative of their community, and the things that make a place a place don't generalise.

The praises of the LocalGov Drupal community are often sung where councils and suppliers come together to share experiences centred on regular online meet-ups and in-person events. If I may be indulged with food metaphors, I think one key ingredient that we can overlook and take for granted is that the LocalGov Drupal project is baked in the wild on living, breathing council sites, and people bring their experiences and practices back to the group to improve the product. 

That’s one of the reasons I love the opportunity to get my hands dirty with development and maintenance. It means I can bring my knowledge to Annertech’s clients and feed things back upstream into the project too.

One such opportunity was to work with Annertech’s Juanluis Lozano on the front-end development for the Luton Council website, which was developed and launched in six months.

Through the autumn and winter I also worked regularly with developers from Annertech’s Managed Services team and our Account Managers to figure out how to join some dots between code releases and updates to sites. We realised that digging through noisy release notes at update time wasn’t the most effective way. 

So the ‘Release Diary’ was born. Not only is it now easier to differentiate between a non-impactful and impactful change at update time, it’s also a catalogue of new and improved features by the month. And I decided to publish the Release Diary in public so that any council web team or supplier can use it. 

2026: The year for Drupal 11, contributions and stability

The beginning of 2026 brought three major threads of work.

We needed to finalise and ship Drupal 11 support so that councils would have ample time to upgrade their sites before Drupal 10 end of life in December.

Two outputs of LocalGov Drupal Camp in Finsbury Park in February were the acceleration of onboarding contributions with the LocalGov Drupal Ladder, and a sprint toward a stable release of Elections. An overhaul of the Elections module became the focus in Spring. And then heading toward the summer we kept up the momentum as we brought LocalGov Forms to a stable release.

Stable isn't cosmetic. On Drupal.org, security advisory coverage only applies to stable releases, so it's the difference between a module a council can rely on and one they probably shouldn’t. Getting there is real work: depending on the module it may involve security review of roles, permissions and access, error handling, test coverage, dependency stability, coding standards.

We are gradually working through the modules but I want to be realistic that this effort is an ongoing process that will take months and years. Alpha versions really mean that councils shouldn’t depend on the modules: use at your own risk, does not have security coverage, may not have tests, may be undergoing rapid development.

As a community we can help ourselves in not adding to that technical debt by ensuring that new features and modules are developed with best practices, suitable PHPUnit tests and are meeting requirements from the outset. It's a bar we have been keen to meet sooner rather than later for the new LocalGov Microsites Demo module.

At the same time, code in public is better than code hidden away in a private repository, so sandbox and alpha modules have their place for experimental and new modules under active development – so they can be tested and reviewed by peers, leading to match fit modules earlier.

The first half of 2026 demonstrates the real trade-offs in prioritising work. Being adaptable to new and changing objectives meant that delivering the missions (product-led initiatives) took a back seat.

I think the trade-off is a cadence. Reactive and architectural priorities take turns. Media, images, paragraphs and services improvements are the work that gave way — and it is architectural work, which can't be done well on shifting ground. Drupal 11, the Drupal.org move, Drupal Gitlab infrastructure, stable releases: that’s the ground. Media in particular is tractable now in a way it just wasn’t 12 months ago.

Next goal: Making testing more accessible

There is one more vital piece of the jigsaw that I would like to figure out. And that is putting features in the hands of non-developers to test. Code on branches, Composer pulling the changes in, spinning up Dev. None of those things are easy and flowing. I am thinking about how we can reduce friction for developers and bring testing capability to a wider audience.

I want to be realistic that there is a learning curve to using the machinery of code contribution. It’s a pain point we are improving through the Drupal Ladder and the technical docs. At the time of writing, a major bottleneck is the code reviews from experienced Drupal developers. There are so many ways to get involved that whether the objective is to create a merge request or help improve our documentation, you will find a warm welcome. Every person that gets involved paves the way for the next person's journey to be a little smoother.

The LocalGov Drupal project is a beacon of human endeavour and shared purpose; the very antithesis of the self-service checkout dystopia that's unfolding around us. There is a lot more that we would like to achieve and we can accomplish more of it by asking, however big or small, what can we achieve today, this week, this month?