Re: Tracking errata for ActivityPub, Activity Streams core and Activity Vocabulary

I agree, Melvin, that we need to explicitly scope any fast tracking, but
critically Evan has listed two things here:

 - spelling errors
 - "syntax errors in examples", which are indeed non-normative and distinct
from syntax errors in specification language.

Both of these are definitionally class 2 changes per W3C process:
https://www.w3.org/policies/process/#class-2

So Evan is proposing something that is already scoped for us by the W3C,
and imo entirely appropriate.

Of course even class 2 changes will and should be visible for review, and
if anyone notices a class 3 or 4 change slipping in under the guise of a
class 2 change I encourage them to raise a flag to the group! But I expect
that to be rare if we stick to strict W3C change class definitions.

-Darius


On Tue, Apr 14, 2026, 1:57 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> pá 3. 4. 2026 v 18:52 odesílatel Evan Prodromou <
> evanp@socialwebfoundation.org> napsal:
>
>> For the last few years, the CG has tracked incoming issues for the
>> ActivityPub and Activity Streams 2.0 specifications, and when errors are
>> noted, we have maintained a list of errata.
>>
>> During our joint discussion today, we proposed adopting the versions of
>> these docs with errata corrections applied as the basis of the next version
>> of the documents.
>>
>> It seems to me that this is a good point to stop tracking errata for
>> these documents, and start making those changes directly to the new drafts.
>> For example, spelling errors or syntax errors in the examples.
>>
>
> One concern is defining “spelling errors or syntax errors” as a class of
> changes. In practice, once a fast-track category exists, there can be
> disagreement over whether a change fits that class.
>
> At W3C this often becomes a classification question, where proponents view
> changes as minor but reviewers may not. When in doubt, these typically need
> to be treated as the higher class.
>
> It may help to define a lightweight mechanism for resolving classification
> disputes, or to explicitly scope this path to clearly non-normative changes
> only.
>
>
>>
>> Does this reflect everyone else's understanding of the state of the
>> documents? Is there a reason I don't see clearly to keep tracking errata
>> separately?
>>
>> In this case, I'd like to refocus the work on issue triage to triage of
>> proposed changes to the drafts of the WG, rather than as a pipeline to
>> errata updates.
>>
>> Evan
>>
>