community-committee
community-committee copied to clipboard
nodejs
Lazy consensus with policies vs. people
In thinking about how we make decisions in the project, I realized that much of our discomfort with conflict in public spaces tends to be when we are discussing/voting on people vs. policies or content decisions. Even with a lazy consensus model, we rely on someone publicly objecting. That can be really tough to do if we're, say, voting on whether a person should be accepted as a member/collaborator/teammate in a repo.
When we are voting or objecting to policy, that's a very different feel than if we are publicly objecting to a person existing in our spaces. Should we create a policy that in cases of needing to vote on a person(election, member onboarding, moderation behavior), that we take advantage of blind voting? We used this method for the CommComm Chair elections and I should prob write that up officially anyway for future use.
+1 to this. I'd actually go a step further and say that a member can request any vote to be a blind vote - much like we did with the CommComm Chair election.
With this, if someone doesn't want to request the vote be blind publicly I believe they should be able to request it privately the CommComm Chair(s).
@hackygolucky having used civs before, I can't stop appreciating how well it works. +1 (*1000) to this
As a TODO for this: if https://github.com/nodejs/nodejs.org/pull/1465 lands prior to a decision on this, we'll need to update the proposed section there about the Consensus Seeking Model and lazy consensus 👍
In the last Community Committee meeting, it was also determined that a temporary hold on voting ability should be placed on returning emeritus members upon reinstatement, so as not to make it a revolving door of single issues being addressed. The arbitrary time for hold was mentioned as one month. I don't have an objection to this.
One of the strongest voices I've heard across the project over the past 6 months has been a desire to foster accountability. Blind voting seems counter to the general norms of this project. Consensus seeking is hard work. We value transparency.
Members of the TSC have shared that one of the big challenges they've face is the unsupported "No". It's essentially a veto with no justification and no feedback to the author of a patch. I've been doing a bunch of research for work on Node.js project governance. I find how Apache deals with -1 votes very interesting. They require -1s to be strongly supported or otherwise they're considered invalid and ignored. https://www.apache.org/foundation/voting.html
I think blind votes are appropriate for election and removal of people to roles. I don't think blind voting is appropriate for adding new members, for example. If someone objects to a member in good standing, those objections should be public and attributed.
[added link to Apache Voting]
I think blind votes are appropriate for election and removal of people to roles. I don't think blind voting is appropriate for adding new members, for example. If someone objects to a member in good standing, those objections should be public and attributed.
Being a member is a role for both the TSC and CommComm. It is an elevated role due to the responsibilities and voting attached to said membership. This is especially why if someone is being added or removed, it isn't taken lightly. Historically and up until recently, in our own project(not sure about Apache projects), we have had heightened community conflict attached to having votes re: people.
Also, what you've mentioned re: TSC challenges is exactly what I'm saying should not have blind votes: ideas. We're talking votes on people only here.
We value transparency.
Absolutely, as an organization and community, Node.js values transparency. It should not be at the cost of the humans contributing, and I think we have felt that this year. This is why the CommComm members chose to use http://civs.cs.cornell.edu/faq.html because it also allows for unique, blind voting. We publish the count after the voting wraps. It is only used for people-matters. In past CommComm deliberations about this topic, we concluded that there wasn't enough value in knowing the single voters who objected to a person, just that the objections happened. There is responsibility in preparing all who have voting ability to make sure they are very clear of what they are voting on, and the reasons why the vote is occurring.
With regard to this specific part:
One of the strongest voices I've heard across the project over the past 6 months has been a desire to foster accountability.
Voting a member onto a committee is something that the committee needs to be held accountable for, as a single entity. We, the (x) committee, are voting on this person to join the (x) committee - and we, the (x) committee, are accountable for that. Pointing to who voted yes/no on if this person can/should join is not helpful and isn't a needed data point for accountability.
With regard to blind votes being "appropriate for adding new members", let's use an example to model the concern I'm expressing: TSC Nomination: Daniel Bevenius. As of my writing this, lazy consensus is proceeding without objection. To help those who are just reading this post, Daniel is a Red Hat employee.
First, let's look at the positive case: we are getting great social proof that this is a successful nomination. Lazy consensus is working. Moreover, we can observe through a cursory audit that we have +1s from diverse representation of corporate interests. We following both the requirements and meeting stated expectations.
Now, where I'm trying to draw attention to a concern is in the negative case. Let's say I object to Daniel's nomination. There may be a good reason. The following is a fabricated example:
-1, Red Hat already has the maximum number of representatives allowed from one corporate entity per TSC Charter, Section 4.
I have provided a -1 with a strongly supported objection. Now everyone has shared context of why and how to address it.
If instead, I only submitted a -1 vote. Nobody has context. Social tension increases. Daniel will likely become frustrated with the project. I think this a poor outcome for all involved and should be avoided.
Let's say this vote was done as a blind vote. I could then vote against this individual for arbitrary or entirely subjective reasons. Perhaps I work at a competitor and don't want to see Red Hat increase the number of voting members on the body. Or maybe I'm just overly protective of being the only Daniel around. We don't know. There's no burden of proof to provide a sound objection.
Say this blind vote fails. Now the body, in this case the TSC, should provide some context to Daniel as to why this nomination was unsuccessful. Will they be able to try again? What will need to change to be accepted? A failed vote with no social proof and no justification is even worse than the simple -1 above. With it, we've created an arbitrary barrier to entry and can expect bias to fester.
I struggle in the use case of a new member nomination to see how a blind vote could be acceptable. In the case above, instead of a blind vote, I think calling a private vote would be a more appropriate way to address an objection that is not a straightforward matter of process. That way, along with the vote, the body (TSC) could work together to provide an explanation of any negative result and a recommended course of action.
If I may give my opinion on this...
I have to admit, while I love the idea of Condorcet voting (I actually wish it was used in more political elections), @dshaw makes a very valid point IMHO.
Nay-voting shouldn't go unexplained for admitting people. For removing people, when cases are clearly made and infractions duely recorded, blind voting can happen, there should not have the need for further explanation. But for admitting people, the voting can be private, but there should be explanations when voting against. At the very least because the candidate has a right to know why he's been rejected, and not just "because someone voted no".
tl;dr:
- Blind voting:
- for removals: yay
- for admissions: nay
- Private voting:
- for removals: no need
- for admissions: yay
I agree with @dshaw last comment that a private vote may be better in some cases. Having said that, there are cases (for example a vote on an existing member) where people have to work together after the vote and a blind vote may make that easier.
So I think we should be open to choosing the right option for a particular circumstance with the default preference being:
- public (default choice)
- private
- blind
I recently had to advocate for making the CommComm Chair vote private. It was a tough chicken and egg spot. People wanted a reason- but sacrificing confidentiality/privacy was needed to do so. The alternative was to abstain- which I think the system fails at that point.
Thank you @hackygolucky and everyone for considering this as a policy. I am definitely in favor of having private voting for "people matters" while "non-people matters" should be open.
I am open to some scenarios where "non-people matters" should be private- but I'd need a real world example to understand why. To avoid the chicken & egg problem, we might need to have a policy (as @bnb suggested) that allows any voting member call for a private vote. I suggest that call is done to the Chair in private and the Chair is responsible for confidentiality in that request and notifying the voting members.
But, I'd go even further. Like to see language in that policy SOMETHING like:
Private votes for "non-people matters" are intended to be rare since they sacrifice transparency. If there are more than 3 in a 1 year period. The CommComm must revisit this policy in a public discussion and publicly vote on whether to keep this provision of the policy or update in a manor that promotes transparency.
Some unorganized additional thoughts/points...
Different types of votes on people
- yes/no votes: This can be heavily fact based- but falls apart at SOME grey area. Examples: "Should we remove [person] from group", "Did [person] break this rule?"
- election: This is extremely opinion based.
AFA CommComm goes... I pushed to have a "follow this path and you're a member" process (no nominating or voting). This was the best way I could think of to ensure that no one felt prejudice/favoritism was involved. Inclusion is not subjective. We acknowledged this absolutely could have problems- but we decided to be optimistic and see what happens. I don't think we've seen any negative side so far.
Safety
I saved my biggest concern for last. We have a duty to balance transparency with safety. Both "transparent" and "safe" are debatable concepts... so the balancing act is hard.
But at the end of the day- I do not want someone to get harassed (or other bad things) for sharing their opinions here. I am OK with sacrificing a portion of transparency (private votes) to ensure that a diverse set of voices/opinions are heard and not excluded.
Some quick thoughts. Apologies in advance if I'm repeating stuff that's already been said elsewhere or if I'm veering off topic a bit.
-
We've had blind vote/secret ballot before and it did not end up going so well. I'm not saying they can't be deployed effectively. I'm just saying caution needs to be used. Specifically, when the TSC voted on removing a member due to a conduct complaint, the resulting blind vote/secret ballot just meant that there was speculation and suspicion from both sides about who was voting on the other side. It did not foster a healthy environment. It damaged trust.
-
That said, we do often have private discussions before engaging in lazy consensus. The TSC nomination that @dshaw cited above is an example. Before nominating, I sent the nomination around in email privately to the rest of the TSC knowing that if anyone had an objection, they might not want to air it publicly. A case could be made that this practice is actually worse than a secret ballot (although i'm not convinced at this time). Additionally, a secret ballot encourages "-1" with no explanation. I'd rather someone who doesn't want to come out publicly against something do it privately to the rest of the TSC or even just to one or two other TSC members that they trust, and provide an explanation in the process.
-
I would encourage everyone to not merely think of rules and procedures. I've noticed that we tend to change rules and procedures to address cultural problems like this. (This is a cultural problem from my perspective: People don't have the faith that there won't be negative repercussions to being a nay-saying minority opinion in some situations, especially around people issues.) What ends up happening is that people manage to skirt the rules (see the TSC rules about "automatically" removing a member, which have never removed anyone nor resulted in significantly more engagement on the TSC) or else the rules just get ignored (I'm proposing removing parts of the TSC Charter that fall into that category). Rules and procedures don't drive culture as much as culture drives procedures (and thus rules). It's a feedback loop and both sides need to be addressed. I have many more thoughts on this, but I'll spare everyone for now. :-D
Removing cc-agenda label for now - @hackygolucky when you PR please add the cc-agenda label so we can review! 👍
I've unarchived this repo so I can close all PRs and issues before re-archiving.