Regaining trust in local consensus

(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.

There is a need to trust local sysops with requesting configuration changes as a result of local consensus. This has failed to happen in some RfCs, as linked at this category. The reason stated was that the discussion and voting involved active editors and is not representative of the entire userbase such as weakly active editors and readers themselves. Such failure undermines a fundamental principle of the Wikimedia movement. Quoting Jimbo Wales from 2001 (!):

4. Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by the Wikimedia Foundation, in full consultation with the community consensus.

Local sysops refused to deem the RfC useless, and an edit war over common.js (where they disabled the software feature entirely using JavaScript) resulted in an edit war, and the WMF introduced superprotect for the purpose of overriding community consensus.

This was a hurried decision. No world would fall over, were the software to be disabled temporarily. In fact, the people (both local and the WMF) could have been smarter and programmed relevant API queries to only disable the software for logged out users, without rendering a user preference useless.

Hence we have a question:

How to regain trust in community consensus, so that WMF does not force software onto various wikis against their will?

This could be done by introducing better software for RfCs and tech awareness of community.
This could be done by engaging community in the software development process.
...