- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Tue, 17 Oct 2023 14:31:58 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: public-swicg@w3.org
- Message-ID: <abcb7ab4-6164-49fa-9edb-05e3fe1a4723@w3.org>
On 14/10/2023 11:50, Melvin Carvalho wrote: > > > 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. At different stages of its lifecycle, A REC-track document undergoes wide review. This is were this kind of problem would be caught. > > 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> <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 >>
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Tuesday, 17 October 2023 12:32:03 UTC