[wg/social] Restarting the Social Web Working Group #435
Comments
|
Notes:
|
|
@plehegar noting that at this time there have been two contributors to that document |
|
[[ |
|
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. |
|
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.) |
|
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. |
|
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. |
|
@melvincarvalho wrote:
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:
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
changed the title
|
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. |
|
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. |
|
The future group might want to consider adopting a staged approach to move proposals from CG to WG . |
The conclusion the Team is waiting for from the CG is a simple expression that a Group charter is needed. We can work out the details of the charter after that. |
|
From last year minutes. |
|
Can we turn the proposal into a charter? |
|
@github.com/plehegar I read that FedID CG/WG Proposal Stages proposal (@w3c-fedid/Administration/blob/main/proposals-CG-WG.md) and it makes a lot of sense to me as a thoughtful and rational methodology to incubate ideas and proposals in a CG through levels and when to uplift a proposal into the corresponding WG. I support it. I think this would work well for numerous technical proposals being discussed in the Social Web CG to help them evolve and advance iteratively, and provide a more explicit way to evaluate them (independent of their specific topic or technology) for taking up by a potential future Social Web WG. (Originally published at: https://tantek.com/2024/269/t1/) |
|
@github.com/plehegar regarding:
I think that proposal made good progress on some sections of a potential future Social Web WG charter as of meetings and discussions 6-12 months ago. However, given the CG/WG Proposal Stages you linked us to above, I think it would be worth splitting the large table of Deliverables into two tables for consideration:
Without objection, I can do the wiki-table editing to split up that draft table of deliverables so it matches better with the CG/WG Proposal Stages proposal. (Please thumbs-up as encouragement if you support this) (Originally published at: https://tantek.com/2024/269/t2/) |
|
ACTION: @plehegar to send advance notice to the AC. |
|
There are alternative initial proposals, to be discussed in CG: swicg/potential-charters#2 and |
plehegar
moved this from Evaluation
to Chartering
in Strategy Team's Incubation Pipeline (Funnel)
|
CG is still iterating on its own CG charter, as well as the 2 drafts for a WG Charter. See discussion on 2024-11-08. Aim is to have a CG Charter in December and we could expect the WG Charter will come after that. |
and others
New charter proposal, reviewers please take note.
Charter Review
Charter
(UPDATE 2024-09-27: there are alternative initial proposals. See in the comments below).
What kind of charter is this? Check the relevant box / remove irrelevant branches.
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 swicg/potential-charters
Anything else we should think about as we review?
The text was updated successfully, but these errors were encountered: