Some recommendations for the LocalGov Drupal community​​

crossposted on WAO

Over the last few months, we’ve been working with the LocalGov Drupal team to shore up support for the project and help the community scale. We’ve been looking at the ways the project can help more people to get involved in a way that is sustainable for the existing community. In Quick wins to improve your Open Source community’s Architecture of Participation, we talk about some tactics any project can implement quite quickly.

In this post, we continue using our Architecture of Participation, and present some strategies that will help this successful project. In one way or another, they all deal with developing empathy.

Clear mission

LocalGov Drupal has a fantastic mission. As the project grows, it’s important to ensure that the community stay on course with that mission:

The publishing platform created by councils, for councils.

This is expanded to explain that:

LocalGov Drupal is a publicly owned asset that delivers a better digital experience for citizens, improves service outcomes, and saves money.

In order for councils to continue creating the platform, there needs to be clarity around how it is publicly owned and operated. What mechanisms exist for the community to influence the direction of the project?

Recommendations

• Involve the community in decision making through defined workflows and roles.
• Share information and be transparent about financials (e.g. shortfalls in funding, investment opportunities) by creating a ‘funding’ circle that members can join.
• Use consent-based decision making within relevant Sociocratic circles to guide relationship establishment with partner organisations.

Invitation to participate

The advice in our blog post to take the time to personally invite people stands true, this is a game changer for participation. Another helpful way to ensure that you are inviting a diverse group of people is to establish some repeatable norms for the community.

At the beginning of meetings, invite people to check in by saying how they are arriving at that meeting. This gives people an opportunity to say how they are feeling, what might be bothering them or what they hope to get out of their participation.

In addition, create repeatable norms by inviting people to check out places they can get involved. Ask for feedback early and often, model pro-social behaviours around invitations that extend across the project.

Recommendations

• Get in the habit of using check–ins / checkouts in ALL meetings to make people feel welcome, bring their ‘full selves’, and be ready for participation. Sign-ins and written check-ins are great!
• Feed the #showyourwork channel by encouraging people to share what they’ve done, however small.
• Share v0.1 of your work for feedback (rather than v1.0) to get feedback around direction as well and not just the ‘final polish’.

Easy onboarding + modular approach

A successful open source project like LocalGov Drupal has A LOT of information to wrap your head around. There are a lot of ways into the project, different places communication is taking place and a variety of technical and social skills required to participate.

In order to make onboarding to a project or community easy for anyone, it can help to present information in several different ways. Thinking about (and documenting!) pathways people might be using to come into a project can help the community see where information could be tidier. This in turn can help the community identify places where a different view of the information might be helpful.

Recommendations

• Create a step-by-step checklist of onboarding and interview new community members regularly to help improve it.
• Develop and promote the documentation system (aka the wiki) to ensure that contribution guidelines are up-to-date.
• Ensure the full context of the LGD project isn’t just held in the heads of core team members by creating standing agenda items.
• Help prevent confusion for new community members by using (and updating) contribution pathways.
• Identify the “most used” resources and make sure they are accessible in multiple ways (e.g. record a screencast of the most popular slidedeck or write a blogpost about the most popular graphic)

Strong leadership + celebration of milestones

There are many different types of leadership. Strong leadership in an open source project is both distributed and diverse, marked by empathy, fair processes, and the establishment/encouragement of positive relationships.

The approach being experimented with by LocalGov Drupal, and which we have seen work extremely well within the co-operative movement is Sociocracy. LGD already has a product group, steering group, and technical group, however consent-based decision-making is not necessarily the norm within these groups’ meetings.

Governance is a work in progress and so we should celebrate both milestones in the project (e.g. technical development) but also milestones in the maturity of the organisation. Those with more mature governance are able to devolve decision-making to relevant circles, encouraging democratic processes and removing bottlenecks.

Recommendations

• Arrange a Sociocracy refresher workshop and invite everyone in the community. Document the content of the workshop and include it in the LGD knowledge base.
• Ensure that each circle has an established “lead” and ask that person to participate in creating standing agenda items together with the other leads.
• Celebrate milestones by issuing badges for everything from onboarding, to pro-social behaviours the LGD community wants to encourage, through to membership of groups/circles.
• Plan for a specific role around governance and operations to allow ‘business as usual’ to flourish as well as innovation work.
• Share progress around governance issues as well as technical development on the blog, newsletter, and in presentations about the project.

Ways of working open + backchannels

There are bits of information that need to be kept confidential for the good of the project, but as an open source community, you should default to the highest level of openness you can.

As you work openly, try not to make judgements about what’s “relevant” to the community. Community members will decide for themselves what is relevant and what isn’t. Just remember to add an appropriate license (e.g. Creative Commons) to help people know in what ways they can share and contribute.

In order for people to bring their full selves to the project and contribute in diverse ways, they need to be able to talk about things which may be slightly off-topic. These are opportunities to strengthen relationships between community members, much as people who work in the same office bond by sharing stories around the watercooler.

Positive, pro-social behaviours need to be modelled by those in leadership positions. This is why the habits of those leading meetings, giving presentations, and otherwise having responsibility within the LGD community are so important.

Recommendations

• Establish at least one #backchannel in Slack to enable community members to get to know one another without being disruptive in a work-related channel.
• Provide guidance on licences which relate to documentation of the project, over and above the code. For example, Creative Commons CC BY-SA.
• Make decisions about technology used for community interaction based on established processes and criteria.
• Revisit the Code of Conduct on at least an annual basis to ensure that nothing is standing in the way of diverse community contribution.
• Issue badges based on regular (monthly/quarterly) mini-workshops on what it means to work openly and model/encourage open behaviours.

Onwards!

Open source is about collaboration, not just code. Finding ways to help people feel welcome and seen is a good way to help your open source project be sustainable.