Membership needs a removal process
When you’re establishing governance for your project, you’re probably creating a contributor ladder of some sort. It may have several runs where people get increasing privileges as they make sustained quality contributions to the project. Or you may have elected or selected governing bodies that lead the project as a whole or individual areas within the project. One of the early steps you’ll take is to define the role and how someone gets it.
What you may neglect is to define how someone can be removed from a role. People need to be removed for a variety of reasons, and having planned ahead makes the process much easier.
Why include a removal process?
Nothing lasts forever. Contributors may move on to another project. They might lose interest. They might win the lottery or pass away. Or they might behave in such a way that you don’t want them associated with your project anymore. Removing privileges from accounts that don’t need them — for whatever reason — is a basic part of security hygiene.
Now I’m normally an advocate of not creating more policy than you need. Policy doesn’t need to be anticipatory in many cases. Time you spend writing policies that are never needed is time that could be spent on more productive activities. But in the case where you need to remove someone from a group, you’ll always wish you had the policy in place before you needed it. If you have to modify the rules to be able to remove someone before you remove them, it increase the drama by a factor of a whole frickin’ lot.
When to remove someone
Some conditions for removal are pretty straightforward and not likely to get much argument. For example, if the person says they’re stepping down from the role. Or if the role has a defined term (for example, a person is elected to the steering committee for a period of one year).
Other conditions are straightforward but can sometimes cause disagreement. For example, if you remove people after a period of inactivity. People typically get the benefit of this kind of policy, but they may be upset when it comes for them. If you clearly define in advance what counts as activity, then people know what is expected. They might not like it, but they’ll accept it.
The harder cases are when someone needs to be removed for bad activity. Of course, if they vandalize the repository or otherwise make an intentional mess of things, that’s usually a straightforward decision. But if they are a “brilliant jerk,” that can be more difficult. This is especially true if they’re a long-time contributor with many friends. That’s not to say that you can’t or shouldn’t remove them if they’re toxic, but it does become more politically difficult.
How to remove someone
For the straightforward cases, objective rules are enough. If you’ve clearly defined what inactivity means, for example, then you can remove anyone who matches the criteria. Except in cases where someone says “I resign!” or a defined term comes to an end, it’s a good idea to give a warning that you’ll remove them. This way they can choose whether or not to meet the requirements for staying.
For removal based on a judgement decision, the threshold needs to be high, but not too high. You want it to be high enough that merely being disliked by a group of people won’t be enough to get someone removed. That’s a recipe for a toxic community. On the other hand, you don’t want it to be so high that having one friend among voters is enough to keep a toxic person is a privileged position. There’s no simple rule here, and to some degree it depends on the size of the voting group. But in general, you’ll want to require at least 2/3 of the people who can vote on removal to be in favor before you remove someone.
This post’s featured photo by Tarik Haiga on Unsplash
