Rust OSS Governance and Sustainablility I

Recently I travelled all the way to Waterloo from Boston for Starcon. With a 9 hour drive I had a lot of time to think about things and so I spent a good majority of it thinking about OSS Governanace and Sustainability. What I came up with and thought of is the more concrete solutions to the problems I brought up in my Rust 2019 post. With the Rust All hands in Berlin only a few weeks away I wanted to get my thoughts in order by writing out some of the solutions to specific problems I came up with. Now, this doesn't mean they'll be accepted! We might even find better solutions! I just felt a need to articulate them as both a reference point and to make sure I've thought through them well. I'll be splitting them into a few posts so I can publish more faster, rather than write one long post that won't be published in time. With that in mind let's begin!

How does one join a team or a working group? What is and what isn't acceptable for a moderator to do let alone what they should do in certain situations? Now these are important questions, but they share a common fundamental flaw. They lack any kind of official policy. We've been going forward in an adhoc way with how we deal with these. It tends to be situational (in the case of moderation) or with teams it has usually been "someone has done enough stuff to earn their spot on the team". However, this approach is fundamentally flawed as we scale. Those who might want to join a team have no clear path to membership and those who moderate have no clear expectations for what they can and can not do in a situation.

We have built a language that empowers users to become systems programmers, but we have not built policy to empower those same users within our community.

It's not even with just the two examples I've provided, we lack policy in many places. We lack rules that allow us to govern ourselves in the absence of leadership. Policy provides clarity so that individuals can be empowered to do the right thing without others having to tell them. This is why we write things like a file in our repos, it tells people how to contribute, it keeps us held accountable to the same rules as everyone else, and it's there to answer questions when we can not.

I think going forward we'll need to spend some time sitting down and writing out policies for certain issues that keep coming up across multiple areas in the project such as, but not limited to:

  • What kinds of comments are not helping RFC discussions (that don't break the CoC) and should moderators be allowed to remove them or mark them off topic so that actual discussion can occur?
  • How does one join a team? Is the process different per team?
  • Where should official discussion occur (we have like 20 areas to talk about things) so that context doesn't fragment?
  • What powers does each team and working group have and who holds them?

Now I'm not saying we have to come up with every policy right away, but we should consider answering some big ones that will have a greater impact on the project (RFC moderation comes to mind). I think by providing policy we reduce emotional burdern on leadership in answering these kinds of questions over and over, they can just point to the policy document, and secondly empower users to act without needing approval. This increased autonomy will let the project run without being bottlenecked on leadership and let community members feel like they can do things they might be hesistant to without comfirmation first.

This was only the first of many proposals I have in mind. A lot of what I'm gonna propose I think should be tested out under an eRFC with the community so that we can refine our processes before commiting to any one thing. Like I said before, these are ideas, but hopefully some good ones to lead us to a better community overall.