w3c / w3c/process

Are Statements fit for purpose?

Open
#712 20 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Proposed to close
Dominant language
HTML
Stars
262
Forks
194
PR merge metrics
No merged PRs in 30d

Description

Some folks say they're planning/hoping/assuming that documents (e.g., Ethical Web Principles, Vision) which don't come from the WG consensus process might become Statements, and thus represent W3C community consensus.

This makes me uncomfortable. Until now, W3C community consensus has been acheived by allowing any member of the community to participate in a process that is well-defined, with many guiderails to assure that voices are hard, power is not abused, etc. In a WG, I know that I can say my piece, and if I convince my peers, the chair (who is neutral) will instruct the editors to reflect consensus in the document. I know that if I disgree with a decision, there is a well-defined appeal pathway. I know that decisions can't be made without proper notice and transparency. And so forth.

A non-WG forum (for example, the AB or TAG) doesn't have these properties. I am aware and appreciative of efforts to be inclusive, listen to outsiders, consider all input, etc. However, they are not enough; decisions are left in the hands of those who run the body, and any 'consensus' determination they make cannot be challenged. It is not a community decision; it is a decision of that body's members, no matter how hard they strive to be open.

It is true that a Statement needs to be ratified by the AC first. However, this can't be equated to the ratification step in normal Recommendation processing, because it presents an all-or-nothing proposition to members; they had no formal opportunity to participate in the development of the document and negotiate consensus (with the protections discussed above) in the group; only an ex post up-or-down vote in the AC. Yes, of course they can informally participate in the open discussions of the documents being formed up as Statements; however, the fact is that the power structure in place in these non-WG fora fundamentally changes how people participate in them (or decide not to).

Compounding this is the limits on who can appeal the promotion of a Statement -- only an AC rep can. A member of the public or someone who can't convince their AC rep to make waves is out of luck. Thus, the overall community thus gets no role in approving what is supposed to represent it; only the AC (whose dysfunction is well-recognised).

In short, Statements feel like a shortcut -- it's too onerous to get community consensus in a WG, so we'll delegate the consensus process to a smaller group, and then give the community an (unlikely to be excercised) opportunity to reject the result. That doesn't seem like real consensus, especially when we're talking about fundamental issues like values and principles.

Understand -- this is not a complaint about how those groups are running their processes per se; they appear to have put monumental efforts into soliciting feedback, review, and input, and appear to be listenting intently.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the Process Document's linked definition of a Statement and the rules governing its development, ratification, and appeal. The issue does not specify a concrete edit or acceptance criteria; work would require reaching agreement on a revised consensus process and then identifying the affected Process Document sections.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.