I’m not getting too involved. So, you can ignore me. I’m here in the
background, peering vaguely, in the few moments I’m on top of my email
(not often these days). But, if you want my advice… and maybe you
don’t…
I think it’s time for ActivityPub to break off into its own CG or WG.
The SocialCG or WG, whatever happens, can be a thing that exists, and
ActivityPub people can be part of it, but my experience with the
SocialWG especially was that a lack of core agreement on what we were
working on really made life incredibly difficult. We got some good work
done, but… there’s enough to do without needing to have the
disagreements that come from not agreeing on fundamentals.
I think if a re-invigorated set of ActivityPub work is to happen, do it
in a new group devoted to that explicit purpose. You’ll retain a lot
more hair of everyone participating.
Now… regarding the CG or WG process… well, it’s been nice seeing
just how well WebAssembly is doing with their CG process. That’s given
me hope. So I think Ben’s suggestion is not bad. That said the
SocialWG worked pretty well BECAUSE it was full of invited experts. But
that was heavily frowned upon by the W3C at the time. If a WG were to
happen, get buy-in to that idea up front.
But yeah. ActivityPub CG/WG. Keep it focused. Let people get the hard
work done they need to when already agreeing on a core basis. Otherwise
else it’s gonna be just like last time. And that took a few years off
my lifespan.
As editor this opinion carries a huge amount of weight at the w3c. Basically editors of specs are the ones that do the lion’s share of the work. It was true in practice, in this case, too.
Some want a WG which is wide in scope, some want narrow, some want shallow, some want deep.
The issue with a WG is that there will be a big inclusion and diversity problem, and there’s no real way round that.
A potential solution is the 3 step process, where the W3C decide publish things in the fediverse that have sufficient maturity.
A working group publication is a full spec, normally 10ish years of work, and gets the tag “W3C Recommendation”. That is a valuable thing for a lot of people. But for a foss community an equally good solution might be to publish a “note” in our own group. That doesnt take much effort, just a few clicks.
The question is what group to use. It could be the SWICG which is a catch-all for all things social, but has a wide, sometimes competitive focus.
Or to reopen the ActivityPub CG with a narrow focus but also coordinate with other group.
I gave a +1 on the SWICG mailing list for a separate AP CG given the sheer amount of open issues to resolve just in the AS/AP space alone, which frankly kept the developer community discussing for years now without good resolutions. So enough to do, focus needed, without the added scope of a range of other Social Web protocols. My view would be like:
At the same time I consider the Fediverse to be the online space spun up by a range of Social Web protocols. AP currently merely the most popular one of them, but some others already established and many more potentially to come. Thus for a focused SWICG I see it as:
Social Web CG → Collaboration to increase alignment and interoperability of Social Web protocols.
This to me seems a good separation of concerns.
Having said that, it is important that this division of tasks is properly guaranteed, i.e. the ActivityPub CG if it were chartered must properly define the collaboration efforts to be part of their ongoing activities.
We do have an ActivityPub Community Group – a Special Interest Group actually, in the form of the SocialHub.
If Aaron Parecki thinks it’s good to keep the SocialCG and work with ActivityPub within a broader context of the Social Web protocols, then I see no reason to split again. We can continue ActivityPub ground work on the SocialHub, relay to the SocialCG and get the best of both worlds.
The SocialHub was created to give momentum to the ActivityPub community following the ActivityPub Conference held in Prague in 2019, and organized very generously by Sebastian Lasse. It was a great success and we anticipated much work to do that would become much noise for the SocialCG mailing-list, since this list was larger than just ActivityPub.
If now the people we wanted to avoid spamming are fine with getting the heat, I see no reason to move away and apart. On the contrary, I feel like we are in a situation where we have a real grassroots community that is grounded in free software and works on Codeberg and the SocialHub, and a standards-oriented community group who can relay and give body to already chewed on ground work. This is the best situation we can imagine, where the grassroots implementors lead the way and the standards-oriented people renders that body of work normative.
I am not a driving force in the specification process, so I’m happy whatever decision is made, but I want to underline both the grassroots effort that have been going on over the last four years around the SocialHub, as well as the renewed interests by the Chair to consolidate the normative form of ActivityPub and ActivityStreams. This is a great opportunity to engage more people with more confidence in the process, and not isolate other protocols that, if they are less visible, are no less important to our common success.
If we move to a 3 step process, with step one for new FEPs, step 2 maturing
FEPs, and step 3 is publishing things at the w3c, there will be a workflow.
Every CG has its own workflow, some with high friction and some with low
friction. So there is room for different work flows depending on the
thoughts of the FEP author. Community groups are the most casual of the
W3C groups and each determines its own rules. New groups are designed to
be lightweight and easy to form, requiring only 6 approvals and a chair.
Anyone can propose and start a group, and publish CG reports. It’s purely
a matter of taste.
WG are a much higher bar. We dont have a WG now, so we cant change any of
the previously published specs. That can take months or even years to
charter and complete. It’s high friction. However, the major issue with
Working Groups is that they lack inclusiveness and diversity. Therefore,
how the REC track specs evolve is distinct problem from maturations of FEPs.
Following from this it might be quite straight forward to have two tracks for FEP documentation at the w3c
FEP publishing CG, low friction, less review, a set of agreed rules for publishing
SWICG publishing, high friction, more review
The actual publishing part itself is quite easy. The advantage is that it is a permanent hosted documentation at a stable URL with change history. This is what community groups were designed to do.