Re: SocialWeb CG Feb 7, 2025 call -- CG Charter vote!

Hi all,

I think we'd actually be better served by forming a few different community groups:
- one for ActivityPub / AS2 + the related specs 
- one for IndieWeb, so things like IndieAuth, webmention, etc
- and a third for ... I'm not sure what to call it, but like linked data notifications, JF2, etc

We could share all the charter documents, but I think this would give each CG a much clearer focus, folks can be chairs or involved in multiple CG's, so that should be fine. We can always do joint calls and collaborate on documents too, I'm sure, if need be.

I'm not sure we're best served by one big umbrella "Social Web CG", when there's some very specific needs for each group that are sometimes competing.

This is currently my main concern with the charter document and it's scope of work — I think we're unfocused there and it could lead to situations like what originally happened with the WG, which I think we'd possibly be best to avoid repeating?

That also solves the "who should be a chair" problem around voting and such that Melvin pointed at.

Thoughts?

— Emelia

> On 6 Feb 2025, at 12:08, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> 
> čt 6. 2. 2025 v 1:04 odesílatel Dmitri Zagidulin <dzagidulin@gmail.com <mailto:dzagidulin@gmail.com>> napsal:
>> Hi all,
>> 
>> Reminder that the February SocialWeb CG group call is coming up this coming Friday, Feb 7.
>> We hope to see you all there, as we'll be voting to adopt the Charter for our Community Group. (Which will kick off a Call for Consensus period of 2 weeks after Friday.)
>> 
>> Now's your chance to look through the proposed charter (rendered version at https://swicg.github.io/potential-charters/CGCharter-1727386911.html ), issue tracker at https://github.com/swicg/potential-charters and bring up any last minute concerns.
>> 
>> Calendar entry for the call: https://www.w3.org/events/meetings/5d831091-a1b8-4be3-bf1a-36e896a61332/20250207T130000/
> 
> I believe there is an issue with affiliation in the context of the social web and diversity—specifically, that it is not solely employer-based. People often represent a primary protocol ecosystem (for lack of a better term) they are actively working on.
> 
> In the WG, we had three broad groups: Solid, IndieWeb, and ActivityStreams, with significant overlap among them. In an extreme scenario, you could have 20 CG members from IndieWeb, each representing a single user, all voting for one another. This could potentially crowd out other areas of the social web that serve millions of users.
> 
> Affiliation needs to be broader to ensure representation across different ecosystems. For instance, we could have:
> 
> One chair from ActivityPub,
> One from IndieWeb,
> One from the broader social web (including W3C-linked data standards, etc.).
> Imagine someone introducing themselves on a call:
> 
> "Hi, my name is Joe, and I work on ActivityPub."
> 
> The boilerplate charters don’t align well with our use case, and there’s no clear way to codify this in a formal charter without risking it being gamed. However, we could informally agree on a more balanced approach:
> 
> One chair from ActivityPub/Mastodon/SocialHub (with a max of two),
> At most one from IndieWeb,
> At most one from the rest of the social web, including W3C-linked data standards.
> If I recall correctly, during the SWXG, we had three proposed chairs, but two were perceived as too RDF-heavy, leading to objections. One person stepped back to ensure better balance.
> 
> Ultimately, we are often more affiliated with the protocols we work on than with our employers (with exceptions like Bridgy). The challenge is that this balance is difficult to codify in a charter, but we could informally agree to maintain diverse leadership for better representation. 
> 
> Another way would be a two step process.  After elections, members reserve the right to object to the proposed chairs, if they are not diverse enough.  iirc this is what happened with the SWXG where we had two chairs that were perceived to be heavy RDF, and so one swapped out for another, which worked quite well.
> 
>> 
>> Thanks!