[wg/social] Social Web Working Group new charter

[plehegar]

New charter proposal, reviewers please take note.

Charter Review

Charter

diff from charter template

diff with charter proposed by CG

Expected end of charter refinement phase: June

If applicable:

diff from previous 1018 group charter

chair dashboard

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• New

• New WG

Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, and security. Also add a "card" for this issue to the Strategy Funnel.

Communities suggested for outreach:

Social Web CG.

Known or potential areas of concern:

lack of consensus within the Community on the scope of the charter.

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

Use w3c/charter-drafts

Anything else we should think about as we review?

Nope

[plehegar]

Notes:

• We may not need a Working Group
  • Are there any subtantive changes needed for the ActivityPub W3C Recommendations?
• Social Web WG or ActivityPub WG ?
• Maintenance-only or allow new features?
• Make it an umbrella WG around a CG?

[plehegar]

See also https://www.w3.org/wiki/SocialCG/WG_Charter_Discussion#Deliverables

[gobengo]

@plehegar noting that at this time there have been two contributors to that document

[plehegar]

[[
Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation. It can, however, informatively highlight problems and desirable changes using errata and candidate corrections and republish as described in the previous section.
]]
From 6.3.11.3. Revising a Recommendation: Substantive Changes

[AramZS]

There's a lot of activity around what used to be the Social WG's maintained recommendation, presumably that would indicate that there is interest in more active maintenance from a broad set of participants. The potential spec work listed is quite large and many of those could indeed use more active work.

[capjamesg]

I support the creation of a WG. There are several changes to be made to the ActivityPub specification that would require a WG. I thank @evanp for leading work as editor, and to the broader community -- particularly those involved with FEPs -- for helping to advance discussions on how ActivityPub can be improved.

There has also been interest in potentially working on jf2, Micropub, rel=me and IndieAuth. Any inclusion, however, would require an active editor (or, for larger specs, multiple editors) who have already worked on the specifications and can lend their expertise to the group.

I would prefer we have a single WG. I think we can work better as one group rather than managing cross-group communications, and we could have more social web experts in one place to support each other.

I have heard several concerns about new features in ActivityPub in particular but I don't know enough to have an opinion on whether AP should be allowed to have substantiative amendments in a prospective WG. With that said, a lot of work has been done on Micropub and IndieAuth that may introduce new functionality. If that is the case, I think denoting, by spec, whether the spec is in a "maintenance mode" or allows for larger changes would be beneficial. Thus, we could have ActivityPub in maintenance mode and IndieAuth, for example, in a more active editing mode.

I invite CG members (participation is free) to contribute to the prospective WG charter wiki page, where we are collating thoughts for a charter. This page has been sent for distribution across the mailing list, published on the w3.org website and mentioned in meetings. I would love to see more people help us advance these discussions! (The wiki page is a forum for brainstorming and does not represent any final position of the group.)

[melvincarvalho]

There's been a few objections to a WG on the grounds of diversity and inclusion.

Looking at the wiki page, the following document is mentioned: "Indieweb Living Standard"

https://indieauth.spec.indieweb.org/

Considering the significant shift of the fediverse towards the diverse open-source community, it seems prudent to adopt a living standard, supplemented by W3C snapshots that reflect the widely implemented practices.

[capjamesg]

The Living Standard process has worked well in the IndieWeb community. It was a great way for me to dip my toe in the water per se. I could participate in discussions about improving a standard without having to worry about what it meant to contribute to a standards body in terms of the stricter processes. My curiosity about implementing the standard was enough!

With that said, a Living Standard process is contingent upon there being active (existing) editors who are willing to triage feedback and weigh in on new ideas.

There is interest in propagating that the IndieWeb Living Standard work back up to the W3C. In the case of IndieAuth, there have been a few discussions on maturing the spec from the Living Standard to a full document intended for consideration as a W3C Recommendation per the Standards Track process.

[bumblefudge]

@melvincarvalho wrote:

Considering the significant shift of the fediverse towards the diverse open-source community, it seems prudent to adopt a living standard, supplemented by W3C snapshots that reflect the widely implemented practices.

I almost completely agree, in that I think preserving experimentation and extension "in the wild" should be a very high priority. I also recognize that understandably, hardening and refining details very carefully could facilitate the federation pipelines to scale up even more in the coming years and become core infrastructure of the web; Big Companies would like to see the refinements and iterations of AP and adjacent specs get to a point where they can Build Big and make it infrastructure. Those are two very hard priorities to balance. The balance of both priorities falls entirely on that mechanism whereby community consensus is achieved (or in the worst case, manufactured) for selecting features or use-cases steadily being adopted in the wild as candidates for inclusion in a future major-version of the specification. It's easy to imagine it working well on a happy path, but it brings its own failure modes like any human endeavor: collusion, horse-trading, bias, in-group influence, technocratic groupthink, lack of development-philosophy diversity.

More than any of those, I am more worried about scope creep, or the normative "laws" moving fast enough to break things many layers downstream. As Evan pointed out today in a blog post, some of those things are too important to risk breaking!

@capjamesg wrote:

I would prefer we have a single WG. I think we can work better as one group rather than managing cross-group communications, and we could have more social web experts in one place to support each other. [...] I have heard several concerns about new features in ActivityPub in particular but I don't know enough to have an opinion on whether AP should be allowed to have substantiative amendments in a prospective WG.

The failure-mode I'm most worried about isn't that a joint working group would be too collaborative or too dispersed in its focus. It's that the precarious balance of today's adoption would be harmed by the temptation to start mandating things or combining things, paving the cow path not into a road but into a superhighway. The growth we're seeing in AP adoption is, in my mind, happening because of how thin a layer AP specifies and how this protects Activity data from taking the shape of a "one-product API". I am adamant about protecting that "thin waist" of this nascent sociotechnology, which even 5 years ago could still be called a single "use case" and is now a whole swath of the web itself.

One strategy for keeping AP simple is to specify it in isolation, zooming in on a subset of the use-cases of the SWICG (which, I never tire of repeating, would be great to publish before scoping anything else or even deciding on the operating agreements of today's SWICG). If cross-pollination is preferred to focus, that would be great and bring lots of value, but also its own risks and failure modes. For instance, the small circle of people working halftime or more on these efforts could unwittingly bias the process towards this or that use-case, making this tradeoff or that tradeoff at the expense of flexibility and open-endedness. Collaborating closely could allow us to quickly advance profiles for how these disparate tools can work together, but without time to see how those adopt and affect market dynamics in the wild, bumping them too quickly form profiles to normative requirements fediverse-wide could have unforeseen consequences.

On today's call, the idea was floated of putting a "gating function" (echoed above in Melvin's comment) into the scope of AP changes, to protect against the scope of AP expanding and getting more opinionated in ways that favor short-term effectiveness over long-term open-endedness. I think this kind of "decision checkpoint" is a good direction to explore and thanks to @plehegar for listing it as one possible strategy for de-risking the charter.

Whether in one group or in more than one, whether in Working Group(s) and/or in Community Group(s), I want the work to advance carefully and transparently. I hope our iterations of all these specifications and technologies grows more, not less modular (or as the youngsters say these days, "composable") as we harden and iterate them, allowing more diverse architectures and form-factors to grow around the common language of Activity data.

And sorry for the verbose rant! Strong feelings over here.

[plehegar]

Update: the CG is still discussing this (somehow?). Until the CG reaches some conclusion, this won't move forward. Having said that, there doesn't seem to be urgency on this front.

[plehegar]

And, in case this wasn't clear before: in the absence of a WG, the W3C team will not republish the existing W3C Recommendations unless there is a decision from the CG to do so.