Re: Split off ActivityPub CG or WG

pá 13. 10. 2023 v 16:15 odesílatel Pierre-Antoine Champin <
pierre-antoine@w3.org> napsal:

>
> 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.
>

This makes a lot of sense.  Changes of class 1-3 + test-suites.

The question is who determines what is class 1, 2 or 3.  A spec change
could be inadvertently put in the wrong bucket.

However, there is no workflow right now, which ensures that changes will
not inadvertently be put in the wrong bucket.

If an open source effort does this in parallel, then it's possible to
compare notes, and see how it compares with the test suites.

It will take a while for the test suite to have full coverage.  There's the
NLNet one and also evan's old one at as2.rocks.  Plus a few more.

Perhaps it's an idea to wait and see which test suite achieves the most
coverage in the next 6 months or so.

My slight question is what happens if test suites disagree?


>   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> <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> <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
>>
>>