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

Bengo,
Thank you so much for summarizing. Looking forward to the discussion!



On Fri, Oct 6, 2023 at 8: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.
> >
>
>