- From: Evan Prodromou <evan@prodromou.name>
- Date: Fri, 6 Jun 2025 16:29:30 -0400
- To: Benjamin Goering <ben@bengo.co>
- Cc: "public-swicg@w3c.org" <public-swicg@w3c.org>
I just realized I could drop a link to the mailing list archive, so I did that instead. Evan On 2025-06-06 4:26 p.m., Evan Prodromou wrote: > Your email came in just a few hours late, but I don't think we need to > stand on formality about it. A good chance to think about whether "14 > days" means "14 calendar days inclusive" or "336 hours exactly". I say > we err on the side of inclusivity! > > I'm going to leave the erratum in the proposed section, and leave the > ticket open. We'll come back to it at next week's issue triage. The > issue is 7 years old; it can percolate for another week or two. > > Ben, if you could, please drop your response as a comment on the issue > to make sure it's clear why we couldn't apply this erratum. I'll loop > back around at next week's session and take another shot. If I can put > together wording that makes sense and meets your criteria, I'll post > another CFC then. > > Evan > > On 2025-06-06 4:12 p.m., Benjamin Goering wrote: >> Hi Evan, >> >> Thank you for initiating the call for consensus as outlined in our >> charter's decision policy. I'm supportive of maintaining an erratum >> for this ambiguous `outbox` and `inbox` definitions to clarify that >> the original consensus was to allow the values of inbox and outbox to >> include a URI reference as a JSON string and/or an embedded JSON >> Object of type Collection. >> >> However, I need to raise a concern with the current proposal. I'm not >> able to support the CFC because it doesn't fulfill the W3C Process >> requirement to describe the error separately from the proposed >> correction, and the omission of an error description prevents me from >> understanding the intention of your proposal and CFC. Additionally, >> it's unclear whether your suggested text is a possible solution or a >> candidate correction - I'm not comfortable consenting to a candidate >> correction until we establish consensus (or at least a proposal) on >> the erratum error itself. With that caveat that there is no erratum >> description, so I may be misunderstanding, I also share some concerns >> and ideas below about the exact candidate correction you did include. >> >> Per W3C Process S6.2.4, erratum must have both the error description >> and affected spec text identified. The error description is >> particularly valuable for implementors e.g. testers - it provides >> context about why we consider this an error and helps avoid similar >> issues in the future, building institutional knowledge beyond just >> providing corrections. But I don’t see an error description in your >> proposal, only a possible amendment to the spec itself. >> >> Could you please update this proposal to satisfy the W3C Process >> erratum requirements (error description that explains the rationale >> for the erratum)? This separation helps ensure transparency and due >> process in our open standards >> <https://www.w3.org/2005/09/dd-osd.html> by first establishing what >> the error is, then creating space for community input on possible >> solutions. >> >> I also wonder if we should solicited input from the author of issue >> 289 before CFCing any candidate correction. Your proposal highlights >> that issue as context for the erratum, so I want to make sure I >> understand whether the goal of your proposed erratum is to address >> the error reported by author of issue 289, or is it to address some >> other error inspired by it? This also affects how to assess possible >> solutions to the erratum, i.e. whether the following suggestion >> visavis issue 289 is germane to your proposal >> >> I think your proposed amendment may work, but there also may be room >> for improvement. For example, issue 289 seems to focus on the OP >> being unsure whether `inbox` and `outbox` properties both allow >> values that are strings (interpreted as uri reference to the >> collection) AND allow values that are embedded JSON objects >> representing the collection. Your proposal to change the definition >> of inbox to this new text that doesn't mention URI References at all >> does not make it more obvious to me that inbox MAY be a URI >> reference. Without more context, it actually reads to me like it's >> trying to say the inbox will always be an embedded object and not a >> uri reference, which I don't think is your intention? However, I >> propose we focus on publishing the erratum with a description of the >> error before we can best decide how to craft text to address any >> particular erratum. >> >> Lastly, would you also please clarify whether your CFC is for >> consensus on an erratum with candidate correction, or an erratum >> without a candidate correction but with a description of a possible >> solution? See example erratum in WCAG 2.0 Errata >> <https://www.w3.org/WAI/WCAG20/errata/>. Note that these include more >> explanation about the original text, why it was an error, etc., >> informing but not constraining possible solutions and usually not >> including candidate corrections. >> >> Evan, is the you’re proposing is intended to be in line with this?: >>> the values of inbox and outbox properties may include a URI >>> reference as a JSON string and/or an embedded JSON Object >> I think so, right? If I’m understanding correctly, I suggest we either: >> 1. Don’t propose any candidate corrections right now. Agree to >> describe an erratum about ambiguity in the allowed values of both >> `inbox` and `outbox` due to their differing definitions >> 2. Do #1 and then agree on a candidate correction that updates both >> inbox and outbox definitions to both properties to clarify their >> values may include objects (e.g. Collections) or strings (i.e. URI >> References). >> >> In summary, my feedback is: >> * I have concern this proposed erratum does not describe the error in >> the text or explain it, and only includes a candidate description. >> * It’s not clear whether the CFC is for an erratum that includes a >> candidate correction, or one that does not include a candidate >> correction, but describes a possible solution to the (as yet >> described) erratum. >> * the proposed spec text does not address the original issues’ >> concern about whether inbox and outbox allow uri references, because >> the proposed spec text could reasonably be interpreted to not allow >> uri references as values. >> * instead spec text could update both definitions with clearer >> definitions about allowed values. My suggestion is that we postpone >> discussion of possible solutions until the required elements of the >> erratum have been articulated, which will inform the assessment of >> any possible solutions such as the one in this proposal. >> * if the goal of the proposed amendment is to address issue 289, >> let’s solicit feedback on the erratum (not necessarily any candidate >> solution) from the author of issue 289, if/when an erratum >> description is proposed. If the candidate correction is meant to >> address other than issue 289 or in addition to, please include that >> in the erratum description. >> >> Thanks again for the CFC. I think we can definitely get consensus on >> an erratum about issue 289 and the different definitions between >> inbox/outbox. >> Please consider amending it to describe the error in the spec and >> related rationale so the erratum can conform to w3c process. >> >>> On May 23, 2025, at 9:32 AM, Evan Prodromou <evan@prodromou.name> >>> wrote: >>> >>> Issue #289 of the ActivityPub GitHub repository notes the inexact >>> and asymmetrical language used for defining the `inbox` and `outbox` >>> collections: >>> >>> https://github.com/w3c/activitypub/issues/289 >>> To resolve this, there is a proposed erratum for Section 4.1 to >>> bring the definition of the `inbox` property closer to that of the >>> `outbox` property: >>> • In section 4.1 "Actor objects", the definition of "inbox" >>> should read, "An OrderedCollection comprised of all the messages >>> received by the actor; see 5.2 Inbox." >>> We usually handle approval of errata in our synchronous meetings, >>> which takes a lot of time and focus away from other topics that >>> require more immediate presence and conversation. In speaking with >>> the chairs and others in the issue triage meeting, we think that >>> handling this task through the CFC decision-making process will be >>> more efficient. >>> So, I am seeking consensus to add this erratum to our errata page >>> for ActivityPub. Please reply either to the GitHub issue or here on >>> the mailing within 14 days of this message. >>> Evan >>> >
Received on Friday, 6 June 2025 20:29:34 UTC