Today, I'd like to share a bit more how we work inside the Funkwhale collective. I believe this can be interesting for people willing to have a better understanding of the work we do for Funkwhale and how we do it, and maybe give you some ideas for your own projects and communities!
This post won't focus on Funkwhale as a software, and deal more with the tools, processes and workflows we use to manage Funkwhale as a community project.
Please note most if not all of the tools we use are already listed on our website. However, today's about the big picture and how the pieces of the puzzle fits together.
On Funkwhale's organization and constraints
Within the project, there are different people, groups, tasks and needs, which has concrete implications on how we organize and communicate. In particular, the people working on Funkwhale:
- are living in different countries and timezones
- speak different languages
- have varying skillsets, and aren't necessarily tech-savvy
- have varying schedules and amount of time they can dedicate to the project
- are involved for varying durations, ranging from days to months or years
In that context, we are looking for tools and workflows that are flexible enough to accommodate this diversity, as much as possible. That's why we tend to favour:
- asynchronous communication over synchronous communication and meetings
- text-based communication over voice/video based communication
- english as our working language
- structured communication over loosely structured communication
- public or semi-public discussions over private discussions
Our core toolbox
I'll dive into the details, but basically, our main set of tools is made of:
- Matrix, a chat system, for day-to-day discussions and coordination, in public or private working groups
- Loomio, a forum, for long-form discussions and communication with the community
- CodiMD, a note taking software, for collaboration on documents before publication
Case studies
Instead of theoretical stuff, I'm going to describe a few concrete examples on how we used these tools during important milestones of the project to:
- Organize our first general assembly
- Agree on our roadmap
- Design and implement the podcasts/channels feature
Organize our first general assembly
Back in early 2019, Funkwhale was not a formal collective, and we wanted to change that. As part of this process, we decided to build a French Association to back the project, and drafted our statutes.
As per our statutes, the last step to incorporate the collective was to have our first general assembly, approve the statutes, and a few other important decisions.
The statutes were drafted with CodiMD over the course of a few months, with several rounds of review. Once we were confident enough, we made several public threads on Loomio:
- A call for candidates willing to take part in the life and administration of the collective
- An organizational topic to agree on the logistics and details of the assembly: date, time slot, agenda, place, etc.
Both topics were publicly accessible, and remained open for several weeks, at least. In the second one, we used the voting features of Loomio to reach consensus regarding:
- The date/time of the assembly
- Appoint a moderator/coordinator for the assembly
- Find someone willing to take notes during the assembly
Both topics feature several of the principles I described earlier, in particular:
- asynchronous communication: discussions were opened and active for weeks to leave time for everyone to participate
- text-based, structured communication, with lots of summaries, to ensure the discussion was accessible to newcomers
- public forum threads, to ensure as many people as possible could know what was going on and get involved if they wished to
After we agreed on the date and logistics for the assembly, we setup another topic for the assembly itself: this one was dedicated to keep a track of the decisions and agenda of the assembly, for archiving and communication purposes.
On the day of the assembly, we had a synchronous discussion on Mumble, an audio/text chat server. We discussed all the items listed in the agenda, had the corresponding votes on the Loomio topic, and the notes were included at the end of the topic after the meeting.
While we could have used Matrix/Riot for the synchronous discussion, instead of Mumble, we didn't because Mumble was our tool of choice for this kind of discussions at the time. We'd probably do this on Matrix today.
As you can see, thanks to the advanced collaboration features of CodiMD, and the voting/organization features of Loomio, we were able to draft, review, discuss, reach consensus and vote on complex documents and issues, without too much hassle.
And almost one year later, anyone can still go through these topics to understand, in context, what was going on, what we decided, how, and why, which I find quite exciting!
Agree on our roadmap
As part of our effort to transition to a community project, we wanted to agree collectively on a roadmap, instead of letting the developers work only on what they wanted.
The entire process was asynchronous, and relied on Loomio and CodiMD. All the discussions happened in a dedicated forum topic
At first, we had an open consultation, for several weeks, during which we asked people to submit ideas for the roadmap. Unfortunately, we were in the process of migrating to Loomio at the time, and this part of the discussion was lost, so I cannot share it here.
Once the consultation was over, I collected the ideas, detailed them, and setup a public dot vote to identify priorities. A dote vote is a type of vote where each voter get the same amount of points and can dispatch these as they want between the available options. For example, if you had 10 points, and 5 options, you could give 5 points to option 1, 3 to option 2, 2 to option 3 and 0 to option 4 and 5.
This kind of vote works extremely well when you want to identify priorities, because it allows you to give more weight to options you consider important, without forcing you to completely ignore other, less important, but still relevant options.
After the vote itself, we collected the priorities, and put them in a new, public CodiMD document.
Since then, we followed a similar process for the 0.20 and 0.21 roadmaps. Each time, we included the new priorities/items into the CodiMD document, to reflect our new goals and priorities.
As you can see, here again, Loomio and CodiMD makes a potentially complex concertation rather easy. Also, we really benefit for the diversity of voting systems included in loomio.
Design and implement the podcasts/channels feature
The case I'm about to describe is slightly different, and still ongoing! Let me tell you how we're using Loomio, CodiMD and Matrix to gather a working group, design and implement the podcasts/channels feature that will land in Funkwhale 0.21. Slightly different because, this time, it spans on both project management and software development.
With our Funkwhale 0.21 roadmap, we had to start implementing the new features. We expected one of them, the podcasts/channels feature, to prove especially complex and difficult.
As a result, in november 2019, we opened a dedicated, public Matrix room, and invited as many interested people as we could. People willing to help design the feature, test it, or just willing to follow the discussions and share some feedback from time to time.
With this working group in place, we had our first synchronous meeting, in the same Matrix room, to agree on our organization. Before having the meeting, we followed a now proven recipe to agree on the date/time and agenda:
- Open a public forum thread
- Suggest several time slots and vote on the best one
- Publish meeting notes on the thread, after the meeting
To help manage the complexity, we also setup a CodiMD pad prior to the meeting to gather links, notes and tasks related to this new feature.
Since this initial meeting, we've met roughly every week on the Matrix room for a synchronous text discussion. During this occasion, we talk about feature design, potential blockers, share progress and, more generally, spend 30-60 minutes together to appreciate the work we're doing.
Asynchronous discussions continue during the week in the same room, and we also publish progress updates on the forum:
Overall, it's been working for us, and really helped to progress on the feature. However, there are a few pain points:
- The Matrix room generates quite some noise, meaning some people have a hard time following it and loose energy/motivation
- We've accumulated a lot of different pads/forum threads over time, and I feel like we should reduce this to reduce fragmentation of information
- The weekly meeting is sometimes empty, or with too few people to have a productive discussion
I'm not especially worried, given it's our first attempt at building such a working group. We will probably do better next time, and I'm thinking about sending an anonymous form the participant to gather more feedback about what should be changed or updated in the way we worked.
Involving the community
I'd like to talk about another missing piece of the puzzle: how do we reach out to the community? How do we ensure the discussions we have on Matrix or Loomio reach their audience? How do we build a working group, get people to vote on the roadmap or attend an assembly?
You probably won't be surprised if I say posting on Loomio or Matrix isn't enough. When we want to involve more people, we usually have to actively communicate in other space about what we are doing.
Within Funkwhale, this is accomplished by:
- Writing bi-weekly blog posts about what's going on: what are we doing? Where do we need help? For instance, this is the blog post where we talked about the first general assembly
- Communicate on the fediverse, via our @funkwhale account. We do this whenever we need feedback on something, like for the roadmap.
- Communicate in the Funkwhale Matrix room. We only do this for critical announcements, like the general assembly, as it tends to generate a lot of noise
- Shed some light on who we are, and how we work. This is what we do with blog posts like this one, or our monthly interviews. While this doesn't help immediatly, if we want other people to join us, we're convinced it's important on the long-term to show that we're not cogs in a machine, but humans willingly working on this project and doing our best
This is another moment where favoring structured communication tools and formats comes in handy, because it means we can include links to these discussions and posts, and ensure people from social media can get all the context they need.
Ideally, we would also communicate on other platforms, such as Twitter or Reddit but this is not always possible due to our limited resources.
That's pretty much it, I hope you enjoyed this blog post, and I'd be happy to answer your questions if you have any ;)