Re: WG Scope

Thanks! It'd be especially helpful to get feedback from Christine and 
Tantek on this.

I hope that it balances Tantek's expectation that the Indyweb stack 
recommendations would be in-scope for the WG, with Christine's concern 
for not overloading the WG with too much work at any one time.

One question for Philippe: is it acceptable to leave the scope open like 
this? That is, the WG will maintain all of the recommendations that came 
out of the (first) Social Web Working Group, but without a specific 
delivery date for the next version of each one?

Evan

On 2025-03-24 6:57 a.m., Bumblefudge wrote:
> Hey Evan:
>
> Thanks for pushing on this, I heartily agree that however the WG(s) 
> get scoped, it is crucial to stagger and manage parallel work openly 
> and publicly. I opened a PR that I hope speeds up discussion on this 
> kind of workflow mechanism, and will extend it to the other proposals 
> once I've gotten some feedback, approvals, and/or competing PRs! The 
> clock is ticking, though, so timely review would be appreciated from 
> the CG.
>
> Hastily,
> __juan
>
> On Fri, Mar 21, 2025 at 8:19 PM Evan Prodromou <evan@prodromou.name> 
> wrote:
>
>     I added an issue to the potential-charters repository with a
>     proposal for managing scope for the WG:
>
>     https://github.com/swicg/potential-charters/issues/83
>
>     I think we should consider /all/ the Social Web Working Group
>     recommendations as in-scope for the new WG, but let the new WG set
>     its own schedule and prioritisation for maintaining those documents.
>
>     I think this would balance the need to maintain all the existing
>     documents on the one hand against the limited time and attention
>     of the working group on the other.
>
>     As an example of how this could work (and /*not a proposal for an
>     actual work schedule, please do not at me*/), imagine that, almost
>     immediately, the workgroup starts with these document revisions:
>
>
>       * Activity Streams 2.1 (core and vocabulary) - incorporate
>         errata, improve clarity
>       * ActivityPub 1.1 - incorporate errata, expand media upload,
>         define replies maintenance, etc.
>
>     As this work winds down, and these documents move into the final
>     stages of recommendation, the WG might take on more work:
>
>       * WebSub 1.1 - errata and clarifications
>       * LOLA 1.0 - define LOLA
>
>     (Again, this is just an example schedule. I don't know if WebSub
>     needs a 1.1 update or if that's the highest priority change.) As
>     these were completed and moved into PR and TR stage, the group
>     might then take on additional streams of work:
>
>       * Activity Streams 2.2 (vocabulary) - expand vocabulary with new
>         terms
>       * ActivityPub E2EE Messaging - example of new functionality and
>         new document
>       * Micropub 1.1 - errata
>
>     In this example, the WG is keeping a healthy and productive 2-3
>     parallel document pace, but is still covering multiple documents
>     over the period.
>
>     The WG could set its own heuristics for initiating new work, such
>     as having N editors for each active document; having N chairs per
>     active document workstream; staging work initiated in the
>     SocialCG; community and implementer demand; and so on.
>
>     I think that as a more mature WG doing iterative updates to
>     existing work, with occasional extensions to that work, it would
>     not be under the same time pressure as the previous Social Web WG
>     was. If we want, we can set more healthy and realistic
>     expectations for deliverables, and still take responsibility for
>     all the docs published by the previous Social Web WG.
>
>     Evan
>