Re: A charter for the Social Web Working Group

> 1. Apply errata to ActivityPub and Activity Streams 2.0 recommendations.
>
> 2. Make backwards-compatible, clarifying text for ActivityPub and Activity
Streams 2.0. Not new features or functionality, but clearer explanations
for some of the terse and/or vague language in both sets of specs.

This seems fine to me, assuming that we have a clear demarcation or litmus
test for what is allowed and what is not. For example, consider cases where
the “author’s intent” was not sufficiently conveyed, but clarifying the
intent leads the stated requirements to change even slightly. How should
the clarification be made?

I think that any case where the stated requirements don't change at all is
fair game -- adding non-normative notes about how certain functionality
works or the implications of a certain requirement is fine. But anything
touching a requirement's normative language should probably be brought to
the CG for discussion.

A more specific example is the current ActivityPub errata --
https://www.w3.org/wiki/ActivityPub_errata has a list of them. The one
about removing `preferredUsername` from the non-normative note about
natural language support is uncontroversial, but more importantly, it
doesn't touch any normative language. But the others *do* touch normative
language, and are the kinds of changes I think shouldn't be made without
feedback from the CG. You mention below that:

> I think this WG could work with a limited membership -- ideally just the
editors of each document -- and work with consensus from this CG. So, no
independent meetings, decisions, etc. 🤞🏼

Obviously the CG shouldn't need to decide every single thing, and the WG
should have the authority to correct typos for example. But "consensus" and
"decisions" need to be carefully scoped, because they might be useful in
certain cases.

Aside from that,

> 3. Refine the recent CG report for ActivityPub + Webfinger into a
recommendation.
>
> 4. Refine the recent CG report for ActivityPub + HTTP Signature into a
recommendation, including an upgrade to RFC 9421, with backwards
compatibility as a fallback.
>
> 5. As other new CG reports, like E2EE and LOLA, are published and
implemented, refine the reports into recommendations.

I'm a little wary of what this might entail -- what does a "recommendation"
entail that a "report" doesn't? Or put another way, what is "insufficient"
about a report that justifies the need for a recommendation? It seems to me
like the current reports are fine as reports and I'm not sure what
promoting them to a recommendation is supposed to accomplish.