Awesome! I suggest you paste the whole thing in to your post so we can quote the text. Discourse can handle tables.
How come it’s the ‘opensocial.community proposal’ and not the ‘atmospheric communities’ proposal?
Following that..
A note on naming
I know the working group has more circled around the term “group” for this thing. I find “group” to be a bit too loose/small, and I don’t feel it captures the nature of the concept as well as “community”.
More than 90% of the atmospheric member spaces created will be ~5 member groups, much like 99% of GitHub repos are single-maintainer. Community-scale groupings are an outlier.
The position of the community professionals who’ve been outspoken about this in the WG is that “community” is much too large a term for the majority of member spaces.
Especially in the context of OAuth login screens: “This app is requesting access to your
[X]”. I think “Open social communities” would read nicely there!
As in “this app is requesting access to your open social community”? I think “this app is requesting access to your group space” makes just as much sense, and to be clear I don’t expect ‘open social’ to appear as a default in any public-facing auth screens, since that’d be confusing in the context of private group spaces.
opensocial.group is available btw.
My argument in favor of groups as the more appropriately generic term for these containers is that it’s weird to preemptively force “community” upon arbitrary social groupings like a teacher-mandated study group, a handful of participants in a weekend course, an industry standards committee etc.
In short: community emerges, it can’t be prescribed.