GOVERNANCE.md: Do we need a more specific consensus declaring role?

[miri64]

Currently the GOVERNANCE.md states

Having full consensus, or unanimity, would be ideal, but we don't
require it: Requiring full consensus allows a single intransigent
person who simply keeps saying "No!" to stop the process cold. We
only require rough consensus: If the chair of a working group
determines that a technical issue brought forward by an objector has
been truly considered by the working group, and the working group has
made an informed decision that the objection has been answered or is
not enough of a technical problem to prevent moving forward, the
chair can declare that there is rough consensus to go forward, the
objection notwithstanding.

Within the RIOT community, the duties of an IETF working group chair fall to maintainers
knowledgeable in the area of expertise. This knowledgability is determined by their own
contributions. On decisions regarding a release, the release manager(s) take this position.

Do we need a more specific rough consensus declaring role (cf. IETF chairs)? Currently this is decided by expertise or special roles such as the release manager(s). Is declaring expertise in documentation, strategy, or vision unclear?

Useful links

• https://github.com/RIOT-OS/RIOT/blob/master/GOVERNANCE.md#decision-making
• https://forum.riot-os.org/t/moving-from-community-processes-to-governance-md/4433/2
• https://forum.riot-os.org/t/moving-from-community-processes-to-governance-md/4433/9#p-16566-comment-16-12

[chrysn]

I've only ever observed one case of this here, but there I think something like this would have helped:

• Let Person A, B, C, X and Y be involved; A..C agree on something, X and Y oppose it.
• Person A claims that rough consensus has been reached, nominates person P as "moderator" (or any other term, see below) for the time of the PR/issue (where they expect X to agree)
• Any of X and Y confirms P as moderator.
  • Alternatively: X or Y proposes another moderator.
  • When it is not trivial to assess who is eligible as being overruled, it is up to P to self-confirm that P takes moderation.
  • X or Y continuing the discussion without acknowledging the need for a moderator count as acceptance -- there's no option "no we don't need a moderator", because if there's controversy over that then apparently we do need one.
• Moderator's only super-power is to assess whether rough concensus per RFCfoo has been reached.
  • Effectively that's the relevant subset of the chair role; don't care how we call it.
  • Challenging a moderator decision is an automatic ticket to delegating the question of "was rough consensus reached there" (not the topic itself, that'd burst the VMA) to the VMA.

Yes this can be gamed, worst case by A and C staging a side-controversy nominating B and all of a sudden B is moderator for the PR, but we're building rules for where humans can call bullshit -- and runs the risk of being overturned in a VMA.

[chrysn]

To clarify this in the context of the original question: I think we need to describe up to whom it is to declare consensus. I do not think we need an extra role in the project (like "member of the security team"), but we need a per-item role (like "VMA moderator") and a process to select someone into that role.

[jkarinkl]

I agree with @chrysn here.

Background on the discussion: to me it is now clear who is/are technically expert(s) on documentation, as described by @miri64 (tracked in GitHub repo). Nevertheless, regarding general documentation that exists for a long time already (readme -13 years; contributing doc - 11 years), I do not automatically and always expect these owners of the doc to take the 'chair role'. For that, it would be helpful to have a process like @chrysn described.

The same goes for vision and strategy.

[miri64]

I guess this also has precedence in the RIOT community (see, e.g., the decision for Murdock years ago).