LocalGov Drupal Beta Sprint 4 Notes

Sprint 4 was a slightly strange sprint for me as I was working remotely in Italy and took a few days off, returning at sprint review to find out what had been happening. It turns out quite a lot had been happening, maybe I'm not needed so much after all!

Project and research sprint goals

We decided to move the research and project goals to the start of the meeting, to allow Alex (Telltale Research) to duck out of the technical discussions to conduct an interview. It is good to have everyone present in planning, but lots of the technical discussion is lost on non-technical people and lots of the research and project discussion is perhaps of less interest to the technical folk, so there is certainly a balance to be found, perhaps we are starting to find that balance.

8. Prepare phase 2 interviews [wrong goal]

Alex is leading on the research work and was not able to attend the sprint 4 planning meeting, so we made assumptions and set a sprint goal that was perhaps a little off the mark. Work has not actually started on the phase 2 interviews yet (interviews with potential users new to LocalGov Drupal) as we are still very much in the middle of the phase 1 interviews with product owners and content designers already using LocalGov Drupal. So lots of great work done, but the defined sprint goal was wrong.

The interviews are going really well by all accounts with a good deal of positivity towards the project and the product. There has been lots of talk about how good LocalGov Drupal is over Drupal 7 for content management user experience, something that may just be attributable to Drupal 8 and Claro theme. The social element has also come up a lot, people are enjoying collaborating and learning from each other. Interestingly a number of people also mention the positive professional development that working with LocalGov Drupal and collaborating with other councils brings. So early days, but some interesting anecdotal feedback already and we're already seeing some evidence of big savings.

9. Send out the survey [GOAL!]

The survey is live and has been sent to as many councils and contacts as possible, but we need more. If you are reading this, you work with websites at a council (Drupal or not) and you have yet to complete our survey, STOP! Go to https://bit.ly/lgdsurvey and tell us everything! (... then come back).

We are also going to start chasing councils that we want to hear from, so if you have any contacts at councils that might be of use, please let us know. We're really keen to talk to councils who are not using Drupal and who perhaps haven't heard of the LocalGov Drupal project. 

10. Start working group facilitation [GOAL!]

As we've mentioned in previous posts, Sociocracy is a toolkit of processes and techniques for communicating and making decisions more efficiently. We've started a couple of working groups to help take decisions and define requirements. Each working group has at least a lead and a facilitator and a total of 5-8 members.

To help us improve our facilitation skills and learn the processes, Aaron has joined the team again to observe working groups and offer guidance on how to improve. His skills and experience will hopefully start to filter out through the working groups and help to empower more of our community to make effective and efficient decisions and drive positive change.

11. Procure a communications strategy person. [GOAL!]

The tender for a comms strategy went out rapidly and we received responses this week, hoping to award and get started next week. This is really exciting, we have so much learning to share and have a great story already, so finding a way to strategically shape the communications is paramount to reaching new councils with a clear, concise and attractive 'offer'. We certainly need a 'shop window' website that helps with this, but we also need explainers targetted at different audiences, like the 'convince your boss with these 12 slides' sort of thing.

12. Define documentation structure [GOAL!]

Documentation is an important foundation of any open source project, but it is often hard to write and maintain the quantity and quality of documentation that new users might like.

Maria and Dan have been making efforts to define a preferred documentation structure for each of the many features that LocalGov Drupal offers. Joeri Poesen suggested that we follow Drupal's suggested template for project README files which makes a lot of sense, espectially for the technical portion of the documentation.

Ben Hills-Jones shared the documentation for content designers at Croydon Council, which goes into some details about what each content type is intended for, how and when to use each content type and other nuances in content designer user experience. 

We've got some pull requests to review and approve, but the lovely Netlify setup on the localgov_docs repository builds a demo for each pull request, so we can see the new documentation structure in action

Product sprint goals

Meanwhile, back on the ranch.... the other developers were still hard at work.

1. LocalGov News - Reviewed by Cumbria Council [GOAL!]

The LocalGov news feature is being tested by Cumbria Council, kicking the tyres to see if any air comes out. This raises a question about formalising the testing process for new discrete features. When will the localgov_news feature be good enough to ship with the default installation? Who tests and approves? What timescale to we allow for this? For now, the Cumbria Council team seem happy with the functionality, which was the intention of the sprint goal.

2. Localgov_base theme - complete first peer review (following documented branching conventions) [GOAL!]

The base theme working group has been meeting weekly and the 'front-end gang' have been peer reviewing work that has mostly been produced by Mark Conroy. As this was a new project on GitHub with just Mark committing code at first, the natural inclination was to dive in, code and commit, without branching or generating pull requests. This is fine up to a point, but can make it hard for others to review portions of work, so we've now moved to a 1.x branch with feature branches and pull requests. The main purpose of this is to make it easier to peer review new features. For me I think this approach also encourages a bit of developer discipline, helping me to focus on completing the specific feature or issue at hand, rather than doing a little bit of everything.

So since this change, there's been a lot of theme review happening, you can see the closed pull requests on the GitHub project. One thing we are not doing yet on the localgov_base theme is requiring peer approval of pull requests before merging. Once we reach a stable release, we will probably want to implement this to enforce a bit more peer review of non trivial commits, but for now we do not want to introduce too much friction in the workflow. 

3. Directories: Open referral data structure implementation [Ongoing]

Ekes has been getting his head into the Open Referral API and has made great progress, but we've not got something releasable just yet. We have good work in progress, including:

  1. a /services end point that complies with the standard.
  2. a whole load of documentation on the OpenReferral UK site

4. Directories: Open referral expose API [Ongoing]

Tightly coupled with sprint goal 3 above, so still a work in progress. Would like to get the organisation end point and the taxonomy end point built out in the next sprint.

5. Directory areas: technical discovery / proof of concept [GOAL!]

The ability to place polygons on a map in directories is ready for test and is up on the test site for further testing. Ekes demonstrated this mid sprint, a neat implementation of entity browser with file upload for kml / gpx files. There is still a small bug on the user interface where the map location fails to update after uploading a new polygon, but it should be easy enough to resolve.

When released, this will be hugely valuable to councils who want to publish areas on maps, such as conservation areas, postcode areas and catchment areas. 

Polygon areas on a map in LocalGov Drupal
Polygon areas can be uploaded to a directory item location and displayed on a map.

6. Directory keywords: analytics / data collection

See https://github.com/localgovdrupal/localgov_directories/issues/98

No progress on this one. You can't score them all!

Reflections

We're still making good progress and are building momentum on the research strand, the front end refactoring and expanding the information architecture of the directories to better align with the Open Referral UK standard. We also have some more detailed functional requirements lined up for the content workflow in the next sprint thanks to the great work of the content lifecycle working group.

Our retrospective threw up a good suggestions for our stand-ups, to look directly at the GitHub kanban board rather than making notes. We have tended to take notes on what people have been and will be doing, but the board can then get forgotten. Focussing on the board might help us to keep it up to date and remind us of other issues that need our attention. We also noted that Maria would like to do more front end development work rather than become documentation guru, I would like to check in on the Theory of Change, that we need a mission patch design and a reminder to check in on the MHCLG needs for gathering evidence as we line up our sprint goals.

Sprint break

We're just going into sprint 5, then sprint 6, after which we will stop for 2 sprints to allow for holidays and other commitments and hopefully allow some of the working groups to build up some specification for the forms, directories and multisite work that we want to start on in sprint 7. Sprint 6 is due to finish on 20/07/2021, sprint 7 will start on 18/08/2021.

As always, if you've read this far and have any questions or suggestions, please get in touch on Twitter @localgovdrupal / @agilecollective / @finnlewis or by email on hello@localgovdrupal.org.

Back to blog