Re: Split off ActivityPub CG or WG

On 13/10/2023 10:31, Melvin Carvalho wrote:
>
>
> út 10. 10. 2023 v 9:22 odesílatel Pierre-Antoine Champin 
> <pierre-antoine@w3.org> napsal:
>
>     Dear all,
>
>     may be a middle ground would be to
>
>     1- keep the SocialWeb CG as one umbrella group with a wide scope, and
>     2- create one (or several) more focused WGs
>
>     This is, for example, what happens with the Credentials CG
>     <https://www.w3.org/community/credentials/>,
>     that has spun off the Verifiable Credentials
>     <https://www.w3.org/2017/vc/WG/> and the Decentralized Identifiers
>     <https://www.w3.org/2019/did-wg/> WGs.
>
>     I also wanted to raise awareness about the notion of "maintenance WG":
>     a WG that is chartered to produce no new recommendation, but only
>     to maintain existing ones:
>     applying errata, making editorial and substantial improvements
>     (but not adding brand new features).
>
>     Would it make sense to start by creating an Activity Pub
>     Maintenance WG for maintaining AS2 and AP?
>     Nothing would prevent this group from requesting a rechartering at
>     some point to start working on ActivityPub2,
>     whenever they and the CG find it is timely.
>
>     Nothing would prevent, also, other WGs to emerge from the CG. The
>     CG would remain the place where the broad community incubates and
>     exchange new ideas. WGs, on the other hand, could focus on
>     delivering specs.
>
>
> Hi Pierre
>
> I thought about this for quite a bit more.  The question arises on how 
> to define "maintenance".

The term"maintenance group" is not explicitly mentioned in the W3C 
process, but we use this term to designate a group that has no new 
deliverable in its charter. Per the process, it means that all it can do 
is apply class 1 to class 3 changes [1] to those documents (anything but 
brand new features).

[1] https://www.w3.org/2023/Process-20230612/#correction-classes


Note that this also include updating (or creating) a test suite for the 
spec.

   best

> Perhaps the first step is to fix all of the editorial errors (e.g. 
> clear syntax errors, grammatical mistakes) in the docs.
>
> Some of the so-called "errata" are opinions on whether something 
> should go one way or another, rather than,  It's often the opinions of 
> 1-2 people on a given issue, without clear reasoning, or real world 
> stats to back it up.
>
> The goal of a maintenance update should be to provide a more robust 
> interoperable space:
>
> https://en.wikipedia.org/wiki/Robustness_principle

>
> However, there is interop and there is also "bug for bug" 
> compatibility.  We run the risk of introducing new bugs that get 
> institutionalized as technical debt.  It's hard at this point to 
> categorize what's a bug and what's a feature. We dont have criteria to 
> decide that right now, and we need to.
>
> Granted the open source maintenance effort is not much butte, but I 
> think an important step will be to improve tooling and processes.  For 
> example the test suite should be helpful.  And it should figure out 
> whether we have true interop or just bug for bug compatibility, and 
> give the network an opportunity to fix bugs and heal, in a backwards 
> compatible way.
>
> The process of correcting simple mistakes from opinionated errata 
> should be separate and we should do one before the other.  I think 
> that's already how things work?
>
> I think a proper robust maintenance update needs to include the whole 
> ecosystem, not just a few people making wiki edits.  Although Evan's 
> primer is going to be a very useful input, we need more docs like 
> this, and ability to compare notes.  And it's going to take 6 months 
> to 1 year to get the tooling in place, namely a test-suite.  And 
> possibly a FEP for the maintenance update in parallel.
>
> We can probably all agree that the tooling we have for this job will 
> be better than we have now, and so will the documentation.  I think a 
> maintenance WG is a good idea, but we shouldnt dive into it until we 
> are sure we are upgrading the network in a backwards-compatible, 
> testable, and bug-free way.  In preparation for this we can document 
> existing practices ( my effort is started here: 
> https://socialdocs.org/ ) in detail, and also codify them in the test 
> suite.
>
> That could give everyone what they want, Evan writes the primer, the 
> whole community go through and compare it with what's in production, 
> open source makes a maintenance FEP, and cross checks things with a 
> test-suite to see how that matches with what's in production.  When we 
> reach a point where the docs and the tooling, and the proposed 
> maintenance items are agreed upon by the whole ecosystem, that's 
> probably a good time to charter a WG and update to perhaps AP 1.1 and 
> AS 2.1.
>
> Thoughts?
>
>     my 2¢
>
>     On 04/10/2023 20:06, Christine Lemmer-Webber wrote:
>>     BTW, I agree with Evan: the CG *is* the home of ActivityPub currently.
>>
>>     I made the suggestion to make a separate CG or WG for ActivityPub is
>>     mainly to provide more focus within the standards process, and it was
>>     primarily a suggestion about if a WG was made in particular.  It could
>>     be that this is a *sub-group* or outgrowth of the SocialCG, but I am
>>     also okay with it not happening.  I appreciate the massive amount of
>>     work Evan is doing organizing and reviving the CG right now, by the way.
>>
>>     But I see the "official home" of the specification, and the authority of
>>     what constitutes ActivityPub, as the SocialCG at present.  I think
>>     SocialHub is an excellent place to coordinate, and works with the
>>     SocialCG.  But the SocialCG is where AP's editing authority resides, and
>>     I think that's good and appropriate and it was designed to be that way.
>>
>>       - Christine
>>
>>     Evan Prodromou<evan@prodromou.name>  <mailto:evan@prodromou.name>  writes:
>>
>>>     SocialHub is a great place for CG members to chat.
>>>
>>>     I think the FEP process is a great way to develop extensions.
>>>
>>>     The core ActivityPub and Activity Streams 2.0 specs are maintained by this CG.
>>>
>>>     Evan
>>>
>>>     On Oct 4, 2023 03:21, hellekin<hellekin@cepheide.org>  <mailto:hellekin@cepheide.org>  wrote:
>>>
>>>       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.
>>>
>>>       ==
>>>       hk
>