Topic on Talk:Technical Collaboration Guidance/Community decisions

According to the Collaboration Guideline, the project team may decline any Community Consensus blocker they dislike.

If there is a Community Consensus that something is harmful to the encyclopedia and our mission, the community routinely uses various tools to block, change, override, or otherwise address the source of the problem. For purposes of this discussion, let us consider a multi-wiki Community Consensus representing a majority of the global editing community. (i.e. a Global Community Consensus.)

Clarification is needed on the next step, if the team declines a Global Community Consensus blocker, proceeds with deployment, and the community disabled/overrides/changes_default in a Good Faith effort to protect and preserve our mission.

There are basically two options:

1. If the WMF's next step is either acceptance or discussion of the issue with the community, then the guideline should to say a Blocker supported by Global Community Consensus is by definition as a critical issue. It needs to say a Global Community Consensus Blocker by definition goes to discuss rather than decline.
2. The alternative next step is to impose enforcement on block-declines. Either redeploying Superprotect, or returning to threats of at-will revocation against any Admin who follows consensus, or equivalent battleground-by-force tactics.

I am seriously scared of a potential repeat of #2. I am afraid a repeat could escalate into community consensus for something like {{RFC}} SOPAWMF. If that seven-letter RFC ever gets consensus then we're all screwed.

One way or the other, clarification is needed on the next step in the Collaboration Guideline. The last thing we want is to ignore that question until everyone is already in the middle of a stressful disagreement.

Yes, a recommendation for next steps in case of disagreement is needed. I propose to get the current draft about community decisions through one review, to assure that we agree on the regular process. Once the basics are agreed, then we will be in a better position to agree on the specific situation of a disagreement and its escalation path.

Whether or not the project team may disregard consensus here is a very important point. If the community is the one that actually decides whether something is a blocker, then it would be very important to make that completely clear, in order to reduce initial hostilities. These kinds of battles aren't fun, and don't result in helpful collaborative discussion and feedback.

@Yair rand the page flat out states the project team may disregard consensus.

I don't see much likelihood that the the WMF is about to reverse position. I see even less likelihood the community will have any respect for this page/process. In fact I expect this page will only inflame any dispute, if and when the WMF ever tries to cite it.