Re: Say charter one more time

Hey Sarven:

Thanks for your thoughts here, I would love to hear from more of the group
"on the record" (by which I mean the mailing list and/or github repo
threads) because there is a natural tendency to think things like WG scope
are "W3C concerns" decided by "insiders" while, in practice, anyone
following this list and watching from a distance (including
non-implementers and non-professionals and even non-W3C members!) should
feel they have a voice, *particularly *if they would consider making a
long-term commitment to contributing to normative work items (whether as a
full member or as an Invited Expert).

> I would even say that this should be an understanding before joining the
group. The group
should think about rechartering for new deliverables or unfinished
business to close the gaps mentioned above and aim to build more bridges
with other work and initiatives in the standards community.

Well, on the one hand, I know we have a "recharter along the way" option
but having witnessed recharters (with their own "insider/passenger"
dynamics) in other WGs, I'm not inclined to make that Plan A.  I think
scope-creep (or even worse, distracting and oxygen-sucking ongoing
conversations about scope that compete with the in-scope work itself for
mindshare and calltime!) is something best avoided by having, if not a
pre-defined list of deliverables, at least a relatively explicit and
trustworthy and deliberative method for constraining the list of work items
over time to "upgrades" or further reviews/hardening of CG work items being
promoted to "normative scope" by CG consensus and deliberation.

In any case, I would strongly encourage us all to have a very good CG
Charter BEFORE deciding on WG scope(s), and really think through
corner-cases and failure modes of the CG-to-WG pipeline doc, if that will
be the mechanism by which WG scope can grow over time...

Thanks,
__bf

On Wed, Oct 23, 2024 at 6:27 PM Sarven Capadisli <info@csarven.ca> wrote:

> tl;dr? I suggest PROPOSAL 2.
>
> Regarding the two charters under consideration:
>
> If the charters focus on the maintenance of prior and ongoing work of
> this CG, then needless to say, the CG needs to reach consensus. This of
> course doesn't prevent a proposal from being independently proposed
> (most likely observing the same criteria from
> https://www.w3.org/Guide/standards-track/#criteria ).
>
> Some PROPOSALs involving work on x and y:
>
> PROPOSAL 1: The CG proposes one charter involving x.
>
> PROPOSAL 2: The CG proposes one charter involving x and y.
>
> PROPOSAL 3: The CG proposes two charters, one involving x, and the other
> involving x and y.
>
> PROPOSAL 4: The CG proposes two charters with non-overlapping content.
>
> I suspect that getting unanimous support for any proposal will be
> difficult, if not hypothetical. So, it may be fruitful for the group to
> approach this with considerations along the following lines. This is not
> intended to be exhaustive, and I'm sure others can come up with several
> dozen more.
>
> * Which proposal will face the least objections? This may require
> refinements if some proposals have roughly equal support. What can most
> people live with?
>
> * This may be a bit high-level, but it's always a worthwhile exercise:
> Let's put the tech aside for a minute. Since we can never be certain
> about the future, which proposal(s) may be most useful for individuals
> and communities in the "social web" ecosystem in the short term? How
> about society in the long term? What do we need to urgently get out
> there with the least amount of friction?
>
> * Which of the proposals are we most confident that 1) W3C members will
> support, and 2) the WG will deliver?
>
> * What might be the ramifications if x or y are left behind? How and
> when can the CG pursue whatever is left behind? What assurances is the
> CG willing to put in place to ensure that it actually happens?
>
>
> Personal opinion:
>
> I believe the maintenance charters are only part of the story, and
> undoubtedly, we, the (social) web community, need to go beyond that. It
> is hard to argue or show, even by just taking the specs (e.g., the
> output of the Social Web WG) at face value, that a fully interoperable
> system can be demonstrated. There are gaps in specs, knowledge, and
> implementation. I'd be happy to be proven wrong, but taking any set of
> classes of products across the Social Web specs, I don't see how any two
> or more implementations can be guaranteed to interoperate end to end.
> This is not a criticism, but rather an acknowledgment that there are
> open problems (and they are hard) and exciting work still ahead.
>
> So, I thought about all of this and had to put my personal tech
> preferences and what I generally use aside to help me think of the big
> picture and maintain my sense of fairness and balance.
>
> Ultimately, it is about moving forward with maintenance - whether people
> want things to stay relevant, need to polish things, or reflect on
> lessons from the real world, or whatever.
>
> I suspect that PROPOSALs 3 and 4 are relatively more expensive and
> complicated than PROPOSALs 1 and 2. And 3 and 4 may come across less
> coherent - we are talking about perceptions of Members and beyond here -
> than 1 and 2. Maintenance on PROPOSALs 1 or 2 can be carried out just
> fine without resorting to 3 or 4.
>
> I can live with either PROPOSAL 1 or 2.
>
> I'm not sure if PROPOSAL 1 is completely adequate or representative of
> this group, but I don't mean faulty. PROPOSAL 2 seems more closely
> aligned with the complexities of the work on social web tech, and some
> synergy across. Let's face it, all of this is still very much an attempt
> to turn the tide from the evil tech (tm) to our open standards-driven
> tech. Have we honestly scratched the surface? I don't know. But if we
> can continue to migrate more people (devs, individuals, communities),
> that's a win for everyone. Hopefully, they stick around after the first
> week :)
>
> The WG can set up task forces to keep focus and carry out the work by
> making the best use of time and everyone's bandwidth. I would even say
> that this should be an understanding before joining the group. The group
> should think about rechartering for new deliverables or unfinished
> business to close the gaps mentioned above and aim to build more bridges
> with other work and initiatives in the standards community.
>
> So, I suggest PROPOSAL 2.
>
> -Sarven
> https://csarven.ca/#i