3 May 2023

Some thoughts on open collaboration

Rust is an open source project. More than just the source code for the compiler being available, that means the project works in the open, inclusive of, and collaborating with, the wider community. That is sometimes difficult, especially when working on things which evoke strong feelings from a large group of people or where the work falls outside most people's scope of experience. Policy and governance work is both of those things, and doing open work on policy and governance is super-hard! This kind of work is difficult to begin with (especially when the folk doing it have a primarily technical background), doing it in an open way is really, really hard (I know, I've tried many times, and mostly not done well at it).

Recently, I think that the work on project governance and trademark policy has fallen short of the standards of open collaboration we expect from the Rust project. It's been frustrating for me to try and explain why exactly, while also participating in these processes (and I've fallen short of my own standards for kindness and empathy a few times along the way). So, I wanted to try to step back and write up how I think these processes should be done, and some ideas for how to make them successful. Talking the talk here is much easier than walking the walk, but even knowing what to aim for is difficult. I hope this post helps there. I think I've failed more than I've succeeded when I've tried to do this stuff, but hopefully you can learn from my mistakes.

Before we start

Doing the right thing here is hard! Developing policy in the open takes a lot of effort. More effort than if you were doing it privately. But you have to do it! If you don't you will get sub-optimal results and you will piss people off and the community will be worse off. It is part of the work, it is non-optional. Yes, it will take longer and it will be emotionally more difficult, but it will be better in the long run. Just like writing tests or docs, or brushing your teeth every morning, you have to do it!

And there are no shortcuts. If you work in private and just share more, you are doing it wrong. You have to communicate intentionally and you have to communicate well. In fact, you have to do more than communicate, you have to collaborate.

I often see people framing these processes as a dichotomy between 'working totally in the open', i.e., working in a public repo and the whole world is your working group, and working in private with occasional announcements or requests for limited feedback. The former does not work at scale and it is reasonable to avoid. It leads to chaos and is overwhelming. But the latter approach is also bad: it is not in the spirit of open work - it is the policy equivalent of coding in private, throwing it over the wall, and calling it 'open source'. The community cannot effectively contribute to the work and so it is not open.

I believe the right approach is to find the right amount of private to do the work, and involve the right amount of the community in a structured and intentional way at every stage of the work.

To start with, I'll cover a couple of useful concepts for thinking about this stuff and some principles which I believe are axiomatic.

WWIC?

"Why wasn't I consulted?".

Apparently, Paul Ford came up with this as the 'fundamental question of the web'. Aaron Turon (the linked talk is really good, you should watch it all) popularised it in the Rust project as a way of thinking about community collaboration in the Rust community, and I think it is a really important lens through which to consider this kind of work.

People want to feel empowered and that they are working together on development. They don't want to have a feeling that they are being ignored in favour of a select few. They don't want to be thinking 'why wasn't I consulted?'.

The philosophy behind this slogan gave rise to the RFC process and much of its early evolution, and more generally to the way in which Rust is developed in the open. It's not that everyone gets an equal vote, but that everyone feels that we're working together.

RACI

RACI is an acronym of responsible, accountable, consulted, informed. It is a framework for identifying and thinking about the groups who should be involved in a process. Like many helpful concepts, it can be over-done and become dogmatic and cringey. But when interpreted sensibly, I think it is really useful. (I'll describe it here, but I'm giving my interpretation which might not be exactly the same as they teach in business school or whatever). There are a bunch of variations too, if you're interested in this sort of thing.

The groups are:

responsible - the people doing the work and responsible for delivering it
accountable - the people (often a manager or exec in the corporate world) who makes sure the work gets done and that is the right work to do. Sometimes this is the leader of the R group or a subset of the R group, but I think it is better if they are not. The Rs and the As will work closely together, but the As should still have an 'outsider' perspective on the work.
consulted - people who are stakeholders in the work and can give useful input and feedback. This group should be relatively small so that they can be effectively consulted. Consultation means being significantly involved in the direction and details. I think it is an anti-patten to make the Cs your end users or customers; you might want input from these people but you don't want to collaborate with them.
informed - people who should be kept informed about the process. Note that this is not just informed about the result of the process, but about the process itself. In the corporate setting this might be peer teams or execs or the legal department, etc. (not the general public or even the whole company, who might only be informed at product launch or whatever). You don't explicitly seek feedback from this group, but if feedback happens, you should probably listen. You might occasionally seek a +1/-1 vote of confidence to check you're on the right track.

Some common mistakes are:

including too many people (or everyone) in the Rs, meaning that work doesn't get done due to the overhead of involving everyone.
Not separating the Cs and Is meaning that you get too much noise in your feedback and/or you can't properly involve the people who should be Cs.
Making the Is too big, so conflating people who want to be well-informed about a project (who should be Is) with anyone who is vaguely interested (who should not, but should still get an occasional announcement or something).

Some other principles

Different people care about different things. People will say that they want to be "involved in the work" or that they should be "consulted" or "informed". But those words can mean a lot of different things.

Some people care about the details and process, not just the outcome (some people at least). Don't assume that people don't want to know the boring details, or that only the output of the process matters. People care that things are done in the right way.

Accountability matters and trust is earned. To be accountable in an open source project means that the people involved are known (pseudonymous is fine) and outsiders can know who argued for what, rather than just giving the opinion of the group once a decision is made. It means mistakes are acknowledged. It means being clear about who has authority and why.

Often, there will be people who want more than you should give. People will want to be more involved than they should be, or want to be consulted more often, or want to have a veto when they are just one voice of many. It is ok to push back and say 'no'. Open collaboration does not mean everyone gets to be as involved as they want to be. Be firm and explicit, and explain why (efficacy can be a fine reason, as long as it is not overused). People will default to wanting to be included more rather than less, this can be (somewhat) countered by building trust that they can be involved less and still have the input they want.

OK, so what should we actually do?

Communication is key! Do lots of intentional communication, both one-way and two-way. Some formats for communication in an open project:

announcements (in a blog post, forum post, mailing list, press release, etc.), good for getting the widest possible circulation of news and therefore ensuring work is widely known;
newsletters and release notes, good for formal high-level summaries for those who want to keep tabs on overall progress;
blog posts, good for giving extra context and for keeping people informed of possible solutions/random ideas/folks' thought processes;
meeting notes/minutes/recordings^[1], good for those who want to keep close track of a project and/or need detailed context in order to contribute, useful for demonstrating transparency and building trust;
working in public

The last item is doing the work in public. For code, this is the default for open source work. For policy and similar, this can often still be done. If you can do this, you still need to do other communication too (because not everyone wants to follow a repo, and even for those who do, they will not get an optimal picture of the work just by following commits and discussion). If you can't do this, then you need to do much more of the rest.

Early in the project you need to work out, precisely, what needs to be private vs what can be public. Work which concerns private information or secrets needs to be private (this might include a lot of financial and legal stuff if it overlaps with corporate policies, but not necessarily if it is financial or legal stuff which only concerns 'open' entities). Some sensitive work (moderation, mediation, some mentoring, etc.) should be done privately. Much other work might feel like it ought to be done mostly in private (e.g., governance work, legal policies), but it rarely actually does. While your lawyers won't want to make PRs, you can still do a lot of work in public. The friction from doing this is usually much less than you'd expect, especially if you are very clear and explicit about the interactions you want, communicating intentionally so that people feel safe to abstain, and if you are happy to moderate discussion. IMO, it is better to work in public and make liberal use of moderation tools than to work in private and have to make up for that some how. It is more emotional labour in the short term, but less stress in the long term and leads to better results.

Whether you're working in public or private, you still need to reach out to the wider community to consult on the work. This must happen at all stages. The biggest mistake I see people make is to only get input and then present a draft output for feedback. I.e., the development process is a black box with input and output. This is not open collaboration! To be open, the community must be able to help set the direction and goals of the work, influence the design, and contribute to the work, not just polish the output.

An allegory: you and a group of friends are going on a road trip. The group agrees that you will organise the trip and do the driving. Here's a good way for that to work:

you (on your own) look up a few destinations within a sensible driving distance and narrow that down to a shortlist based on the attractions at each,
you send a text message to the group letting them know the above,
you all meet up for a coffee, you tell them the short list of destinations, the cost for petrol, and the kind of things you can do at each, you have a bit of a chat and agree on a destination,
you fuel up the car and give a shopping list to Alice to pick up some essentials,
you send a text message to let everyone know you're ready to go,
you all meet up and start driving,
at some point you get a bit lost and ask Bob to check the map,
a bit later you're tired, so you ask Charlie to drive for a bit,
when you get to the destination, the camp site is closed, you find some alternatives and the group has a discussion about where to stay.

And here are some ways this process could be less good:

the group tell you the kind of things they want, you choose a destination but don't tell anyone where you're going, everyone buys the things they think they'll need and you set off. One mile from the destination you tell everyone where you're going and ask people if they'd like to ski or snowboard. Some people have brought beach gear to a ski mountain. You have brought along a meat feast barbecue even though half the group are vegetarian because you asked about activities but not diets.
You start off by having a meeting to choose a destination. You sit around with a world atlas and wikipedia, the whole group suggest destinations with no idea how to get there or how much it might cost. Strangers keep walking past your open window and yelling about destinations which are too far away or which nobody in the group wants to go to, but which are apparently better.
You each take your own car, spend a bunch more money, and end up at different destinations.
You make all the decisions yourself. You send beautifully crafted text messages to the group and spend the road trip giving well-thought out justifications for the choice of destination. On arrival, you hand out a schedule to everyone which plans for their time down to the minute, who will hang out with who, and when they're allowed toilet breaks. Every meal is planned, the dietary choices are correct and the food is delicious, but nobody gets to choose anything for the whole trip. You hand-picked wine to match each meal; when one of the group says they'd rather have a beer that evening you break down in tears and kick them off the trip.

OK, sorry, that was a bit of a digression. Back to concrete stuff you should do.

A timeline

Pre-start

At the start of the project, announce what you want to do and why you want to do it. State your ideas around goals and scope. Depending on your position within the community and the kind of work you want to do, such an announcement might be official or unofficial. It is likely that the announcement should be public but directed to established contributors and maintainers, not the whole world. Ask for feedback to ensure that the work is worth doing, and that the goals and general direction are correct.

Ask for volunteers. Who does the work and how you recruit these people is critically important. If you only invite people rather than ask for contribution, you will perpetuate nepotism and sacrifice diversity. Your work will be less open and it will feel less open to the community. Unless it is obvious, you should also ask for volunteers to be in the C and I groups (though often these groups are obvious, the I group in particular is often the whole community).

Just because you are asking for volunteers does not mean that everyone who is asked or everyone who replies is suitable for the work. You should make your ask explicit about the requirements for volunteers and about the work. In particular, what the work will entail (the kind of work, the expected time commitment, etc.), the number of people you want to work with, the skills and experience required, and if volunteers must have some level of trust within the project. Be clear that you might say 'no thanks' to volunteers. Be clear that being part of the R group is not the only way to be involved and about how the C group will be consulted (to avoid a fear of missing out).

The start

Once you have a group of people ready to do the work and have got the required official blessings (which will involve identifying the A group), then you should announce that the work is starting. This announcement is informational (you're not asking for feedback here) and is an anchor to link back to when you need to talk about the project. You should state the goals and scope of the project. Either these are settled after previous discussion, or they might need some iteration as the project starts up. Be clear which; if the former, let folk know how they can contribute to the ongoing discussion.

You should announce the RACI groups (especially the R group who are tasked to do the work), not necessarily using the RACI terminology. You should be clear about how the I group (which may well be open) can follow along and when (and how) the C group will be consulted. It is important to be explicit about when folk will be consulted or have other opportunity for feedback.

You should describe how the R group will work. In particular which aspects of the work will be done publicly and privately (and why).

Ongoing

When you're heads down working with few natural milestones, it can be hard to pause and communicate. But this is essential for open collaboration. The work is a process, not just a result, so if you want real open-ness you must share the process, not just the result. Even if you don't think there is anything interesting happening, share it anyway! It might be interesting to somebody, and the demonstrated absence of interesting things can be interesting in itself.

Your group should set milestones. These should be small and regular to make your work as iterative as possible. These should be real milestones for the work, not just artificial dates for communication (to keep work and communication congruent). Like software releases, these can be either time-based or feature-based, but not both. At each milestone you should give an update on work and request feedback as appropriate. Include any changes to the timeline or personnel, state when and what the next milestone will be, announce any changes in goals or scope, and announce any opportunities for participation. The primary goal here is keeping people informed; it's also a good time to check-in that you are consulting the right people in an ongoing way.

You should communicate outside of milestones. Informal blog posts by group members giving their current thinking and what they're working on are great for this. The Rust project has been great at these for technical topics, but not so much for non-technical ones. It is ok to over-communicate and have overlap between communications. You might end up saying the same thing in a personal blog post, an official blog post, a newsletter, and meeting minutes. That's fine! Different people like things in different formats and with different levels of detail.

You should actively share drafts of output documents as they're ready. Share them when they're rougher than you'd like and be clear how much iteration you expect to come after. Make sure you're asking the right people (your C group) for feedback. That means asking in the right way in the right places. Every time you share work, you should re-state the goals and scope of the work, why it is being done, and why (and how) this shared artefact contributes to the eventual goal. It might also be worth stating what other artefacts will come later so people don't expect the current one to do everything. It can feel a bit obvious, but that's because you're doing the work. People might be seeing this for the first time (even if the group you're talking to is not new, individuals might have newly joined the group). People are (on aggregate) very lazy, they won't even click a link for context a lot of the time, so you have to keep re-stating this stuff.

Be clear about the kind of feedback you want: sometimes a +1/-1 is enough, sometimes you want detail. If people are frustrated by this (i.e., they want to give a different kind of feedback) then you might not have a shared understanding of which group they are in (e.g., C vs I) or of the context of the work, or they might just be wrong.

Before sharing stuff, it is worth having someone outside the R group look over the 'package' being shared to make sure it reads well to an outsider. An A person might be good for this, or just ask a friend or colleague who you trust. Note that if you keep using the same person for this, then they will stop having an outsider's perspective, so you need to ask new people.

Delivery

Ideally, getting towards the end of the process is not a big deal. You've been working iteratively and openly and so there is no big step in terms of more people being involved in the process. When delivering the final outputs, the only people who haven't seen the work are outside the community or legitimately only have a passing interest. Enough eyes have been on the process that the end result is good and everyone feels consulted.

You cannot have a release of work in an open collaboration process (that is a release to collaborators; obviously you can release to customers/users, but make sure your have a shared understanding with your community on exactly who is a collaborator and who is a customer. If a person thinks they are a collaborator but you think they're just a user, that is a recipe for disaster). You cannot develop a 'draft' privately and hope to be so collaborative in gathering feedback that people feel consulted and involved. That is doomed to failure.

If you find that you are working towards a release and holding off till then to get feedback. Stop! You must iterate and collaborate instead.

If the end of the process is a decision, then you need a small group of trusted people to make that decision (and it might need to be done in private). Importantly the development process must be complete before a decision is made. You can't combine development and decision making in an open process. This is the 'no new rationale' principle of Rust's RFC process. If decision making can be made open and iterative, then you should do that.

I think that one thing to avoid is 'growing circles' of feedback. If somebody's feedback is worth hearing at the end of a process, then it is worth hearing at the beginning too when it can actually make a difference. I don't believe you can accurately match the size of the circle to the magnitude of the changes required to address feedback. In other words, useful contribution comes from surprising places. It's better to identify groups of people to be consulted and consult them from the start, keeping a larger group informed. Otherwise, the group of people who are properly consulted is too small, but the effort of consulting is still large.

One more way to make delivery easier/more effective is to be clear about how things will evolve after delivery/be maintained/get to v2.0. By advertising that open collaboration will continue, there is less pressure to reach perfection and to continue iterating. This works best if you've built trust in your open-ness during the previous phases of development.

Conclusion

That's a lot. And again, this is hard to do; much harder to do than it is to talk about. But hopefully some of it was helpful.

To be specific to the Rust project, I think it is important to move towards the ethos of the RFC process for non-technical work (not the procedural details necessarily, but the spirit of open collaboration). Policy and governance work is not so different from technical work. Much of the time when we want to be less open, it is not for necessary legal or privacy reasons, but because it feels easier; and that is often just because we are less familiar and confident with this kind of work.

To try and summarise the important points from the post, I think that open collaboration works best when:

the community is considered as a partner to work with, not a customer to work for,
work, communication, and feedback are iterative,
feedback is sought from appropriate people from the very start of the work, in particular on the goals and scope of the work,
communication happens a lot and via many different mediums,
groups to consult and inform are explicitly identified,
the group doing the work is transparent: rather than being a black box which takes community input and produces results, the community has visibility into the process of doing the work. The community can see the 'messy bits' of the work being done as well as the polished output. Individual members of the group are accountable because their opinions are known and they communicate as individuals, rather than only as a group.

Some people resist publishing meeting recordings or transcripts because they feel it means they can't talk freely or they don't like sharing their image or voice online. I find these poor arguments. Being open in this way is excellent accountability and transparency. You should have confidence in your own words and faith in your audience that they won't be misinterpreted. Part of being a leader (and if you're in meetings where decisions are made, then you are being a leader) is embracing discomfort for the sake of better results and a better process. A few people have genuine safety concerns or severe anxiety around voice dysphoria, but for many, resistance to meeting recordings is just nerd security theatre. ↩︎