WG Scope

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