Re: CFC: a policy for calls for consensus on SWICG group decisions - Summary After 1 Week

-1 so far.

I don't wish to adopt this proposal as-is.  The length and weight of the
process covering EVERY decision of any kind is, in my experience, going to
make work go slow.  It will also be hard for all but the most heavily
involved process-native people to participate in.

To make a more positive suggestion, it's been my experience that working
group processes should allow for chair discretion about what decisions are
big and contentious enough to need to have a unique call for consensus
(though people can certainly ask chairs to do those calls ) and that
consensus calls are generally held later on more final work only, not on
all "decisions". (To unpack that even more, not all decisions are
equivalent.  We can make a decision "Let's try this approach and see how
that will look in a draft with examples so people can consider that idea"
-- and that is in no sense final work and should not be called for
consensus.

Lisa

On Fri, Oct 6, 2023 at 7:40 AM Benjamin Goering <ben@bengo.co> wrote:

> I want to summarize my understanding of where we're at on this proposal,
> which is on the agenda for tomorrow's meeting. The proposal is earlier in
> the thread, but also attached again unmodified for completeness.
>
> The good news is there is a handful of supporters (4) and only 1 person
> who dissents. The challenge is there are a lot (6) of separate
> views/objections by that dissenter that took time to address accurately
> because most were provided without rationale. But I have sought to consider
> each of them below.
>
> ## Support
>
> lisarein@lisarein.com:
>
> > I also appreciate that I will be able to better understand what’s going
> on by watching the list for CFC without having to take time away from my
> work to attend meetings.
>
> > +1
>
> dzagidulin@gmail.com (SocialCG Chair):
>
> > I love it, +1 from me on this proposal.
>
> melvincarvalho@gmail.com:
>
> > +1
>
> Juan Caballero <virtualofficehours@gmail.com>: seems supportive to me and
> raising no concerns
>
> ## No objection
>
> hellekin <how@zoethical.com>:
>
> > it would be "nice to have" to mention (Cc) and CFC discussion to the
> SocialHub so that we can consolidate the decision making process there as
> well.
>
> Noted. If you share an email address to cc that will notify
> socialhub.activitypub.rocks, it'll help me and others fulfill this nice to
> have.
>
> > Delegitimating the SocialHub should not be on the agenda.
>
> +1. Nothing in my proposal here is meant to do that or conflict with this
> group's past resolution (
> https://www.w3.org/2021/01/09-social-minutes.html#r02):
>
> > Resolution: The SocialCG should support the FEP (Fediverse Enhancement
> Proposal) process as a way of documenting extensions to the fediverse and
> encourage bringing FEP proposals for discussion to the SocialCG.
>
> ## Dissent
>
> There is one dissenter, Evan, and I will consider each view raised in a
> way that is consistent with W3C Process 5.2. I have labeled the views
> presented within the objection to make them easier to reference, and listed
> the ones where I think we agree first.
>
> Each view has a 'consideration tl;dr' and some have an easy to search
> 'Question for Evan'
>
> They are summarized briefly here and then there is an extensive rationale
> for the summary linked to below and attached:
>
> * Dissent View 1 - desire to see a SWIP process defined
>         * consideration tl;dr - I didn't create a SWIP process for this
> proposal, I just used 'SWIP' in a document title, so a request to define it
> separately should not block this proposal. Not actionable.
>
> * Dissent View 2 - recommendation to keep discussions on list
>         * consideration tl;dr: We agree. not actionable
>
> * Dissent View 3 - recommendation that chairs have new final decisions
>         * consideration tl;dr: this is an opinonated recommendation that
> may not be compatible with CG Process so it shouldn't block the proposal to
> establish an async work mode.
>
> * Dissent View 4 - recommendation that objections or agreement be labeled
> with numbers
>         * consideration tl;dr - this is a separate proposed recommendation
> that is not germane to the goal of this proposal, and not found in other
> W3C decision policies like the rest of my proposal. The dissenter should
> propose it separately.
>
> * Dissent View 5 - recommendation to explicitly constrain population of
> SocialCG decision-makers
>         * consideration tl;dr - this is an opinion that is incompatible
> with W3C Process and requirements, so it shouldn't block this proposal
> which *is* compatible with W3C Process and uses language shared with many
> other W3C Groups.
>
> * Dissent View 6 - thoughts on what the current rules are
>         * consideration tl;dr - this is based on a procedural claim that
> is not backed by evidence despite my asks. that is inconsistent with CG
> Process and SocialCG records, and so this should not block the proposal.
>
> Extensive consideration of each of these dissenting views can be read in
> HTML at: https://hedgedoc.socialweb.coop/s/PDuy5742O# and also is
> attached as markdown.
>
>
> > On Sep 29, 2023, at 6:53 AM, Evan Prodromou <evan@prodromou.name> wrote:
> >
> > Let's let people who don't want to use the mailing list make their own
> objections. We can't guess what they'd want.
> >
> > I think it's not fair to the chairs or other members in the group to
> have to chase down conversations to track and resolve objections on every
> Matrix, Discord, Discourse, or hashtag on the fediverse used by members.
> >
> > Evan
> >
> > On Sept 29, 2023 05:28, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
> >
> >
> > pá 29. 9. 2023 v 5:08 odesílatel Evan Prodromou <evan@prodromou.name>
> napsal:
> > -1
> > Thanks for doing this, Ben. In general, I like it, but I have some
> details I’d like to see tightened up before I can support it.
> >     • It should be made clear that only members of the SocialCG should
> be involved in decision-making processes. The passive language like “if no
> sustained objections are raised” makes it sound like non-members could
> object.
> >     • Objections or agreement should be clearly labelled as such, with
> +1/0/-1 voting. Questions or observations are not objections.
> >     • Splitting the conversation across different communications forms
> would make for a lot of missed messages and duplication. Instead, we should
> keep any discussions requiring consensus here, on the email list. Off-list
> discussions are fine, of course, but it’s not a “real" objection/agreement
> unless it happens here.
> >     • The Chairs should have the final decision if consensus has been
> reached.
> >     • I like this SWIP process, which you created for this proposal.
> It’s reasonable, but I’d like to see it defined separately from the
> consensus proposal. I think it would be a great test of this consensus
> process!
> >     • To adopt this policy, I think we need to adopt it under the
> current rules, such as they are, which is by proposal and plus-voting in an
> in-person meeting. I think we have one planned for next Friday.
> > Thanks again,
> >
> > Thanks for the additional comments Evan.  I agree with the point about
> use of the maling list.  However we saw in the last WG there was a large
> contingent that refused to participate in the mailing list, and we
> potentially have a repeat of that.  How do we solve that?
> >
> > I think the weakness in this set of clarifications is that it gives the
> chairs too much power to:  push through controversial items, to override
> objections, to fail to take into account diverse viewpoints.  I do see a
> step in the right direction here, but IMHO there remain underlying
> weaknesses in the consensus method.
> >
> > Evan
> > On 2023-09-28 8:00 p.m., Benjamin Goering wrote:
> > SWIP-37f2: a policy for calls for consensus on SWICG group decisions
> Introduction
> > The Social Web Incubation Community Group is missing an explicit
> decision-making policy, which essentially all other W3C community groups
> have to ensure asynchronous and healthy consensus mechanisms across
> timezones and participatory modes.
> > Proposal
> > W3C SWICG will seek to make decisions through consensus and due process,
> per the W3C Process Document, §5.2.1 Consensus.
> > To afford asynchronous decisions and organizational deliberation, any
> resolution (including publication decisions) taken in a face-to-face
> meeting or teleconference will be considered provisional.
> > A call for consensus (CFC) will be issued for all resolutions via email
> to public-swicg@w3.org (archives). The presence of formal resolutions
> will be indicated by a "CFC" prefix in the subject line of the email.
> Additional outreach to community venues for more affirmative consent is
> strongly encouraged. There will be a response period of 14 days. If no
> sustained objections are raised by the end of the response period, the
> resolution will be considered to have consensus as a resolution of the
> Community Group, i.e. a group decision.
> > All decisions made by the group should be considered resolved unless and
> until new information becomes available or unless reopened at the
> discretion of the Chairs or the Director.
> > This policy is an operational agreement per the W3C Community and
> Business Group Process.
> > Context W3C Groups with Similar Decision Policies
> > These community groups and working groups have similar decision policies
> with tentative meeting resolutions and confirmation of calls for consensus
> via email:
> >     • WebAssembly Community Group Charter
> >     • Credentials Community Group Charter (see section "Transparency")
> >     • Web Extensions Community Group Charter
> >     • Web of Things Interest Group Charter
> >     • HTML Working Group Charter
> >     • Web Platform Working Group Charter
> >     • Web Applications Working Group Charter
> >     • Media Working Group Charter
> >     • Web Performance Working Group Charter
> >     • Service Workers Working Group Charter
> >     • Verifiable Credentials Working Group Charter
> >     • JSON-LD Working Group Charter
> >     • WebAssembly Working Group Charter
> >     • Web Authentication Working Group Charter
> >     • Immersive Web Working Group Charter
> >     • Web Payments Working Group Charter
> >     • Devices and Sensors Working Group Charter
> >     • Distributed Tracing Working Group Charter
> >     • Web Editing Working Group Charter
> >     • Internationalization Working Group Charter
> >     • Publishing Maintenance Working Group Charter
> >     • Solid Community Group Charter (see section "Decision Policy")
> >     • Decentralized Identifier Working Group Charter
> > Proposal processes on SWICG Forum with identical response period:
> >     • FEP-a4ed: The Fediverse Enhancement Proposal Process
> > W3C Community Group Process
> > W3C SWICG is a W3C Community Group (CG).
> > CGs are described in their process document as follows (excerpted for
> concision):
> > This document defines W3C Community Groups, where anyone may develop
> Specifications, hold discussions, develop tests, and so on, with no
> participation fee. …
> > Community Groups that develop specifications do so under policies
> designed to strike a balance between ease of participation and safety for
> implementers and patent holders …
> > A Community Group may adopt operational agreements… that establish the
> group’s scope of work, decision-making processes, communications
> preferences, and other operations. …
> > The following rules govern Community Group operational agreements:
> >     • They must be publicly documented.
> >     • They must be fair and must not unreasonably favor or discriminate
> against any group participant or their employer.
> >     • They must not conflict with or modify this Community and Business
> Group Process, the Community Contributor License Agreement (CLA), or the
> Final Specification Agreement. …
> > the Chair determines the means by which the group adopts and modifies
> operational agreements. The Chair must give actual notice to the
> participants of any material changes to the agreements. Participants may
> resign from the group if they do not wish to participate under the new
> agreements. …
> > Note: W3C encourages groups adopt decision-making policies that promote
> consensus. …
> > Each Community Group must have at least one Chair who is responsible for
> ensuring the group fulfills the requirements of this document as well as
> the group’s operational agreements.
> > Related Reading
> >     • IETF RFC7282 On Consensus and Humming in the IETF
> >     • Doty, Nick, and Deirdre K. Mulligan. 2013. "Internet
> Multistakeholder Processes and Techno-Policy Standards: Initial Reflections
> on Privacy at the World Wide Web Consortium" Journal on Telecommunications
> and High Technology Law 11.
> >     • Harmonization (standards), en.wikipedia.org
> > Editorial Notes
> > The title of this proposal was generated in line with norms established
> by Content addressed vocabulary for extensionsand FEP-a4ed: The Fediverse
> Enhancement Proposal Process.
> > ⚡ P='a policy for calls for consensus on SWICG group decisions'
> > ⚡ echo "SWIP-$(echo -n "$P" | sha256sum | cut -c-4): $P"
> > SWIP-37f2: a policy for calls for consensus on group decisions
> >
> > The 'SW' in 'SWIP' stands for 'Social Web'.
> > This proposal was initially published at:
> >     •
> https://socialweb.coop/SWIP/37f2/a-policy-for-calls-for-consensus-on-swicg-group-decisions/
> > Copyright
> > CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
> > To the extent possible under law, the authors of this Proposal have
> waived all copyright and related or neighboring rights to this work.
> >
>
>