We’ve got a bunch of “working groups” forming and so I’m wondering about a bit of meta.
This community forum space exists in part to support and enable collaboration. It isn’t prescriptive and you don’t have to use this space, but it is helpful for discovery and visibility, and provides a shared space for long form discussion.
A default working group set of features in Discourse looks like a Discourse group with ideally at least two leads (this is like a mini mailing list for private convos and notifications - and optionally permissions) and a Working Groups dedicated category.
These discussions are a way to attract others interested in a topic and have a bottoms up way of coming up with some common ways of interop with loose agreement and proof of concept implementations.
An anti pattern is coming up with a “standard” ahead of a need or an implementation.
And, none of this is “binding” in the sense that this space isn’t a standards body. The exception are some core protocol evolutions like permissioned data. Still not a standard, but community consensus.
I am also looking ahead to formation of an Atmosphere Co-Op. Working groups / circles are a common way of organizing co-ops - Operations, Finance, Comms being some example working groups.
Some common patterns
closed or open: we can support members only categories here, and then also have invite only or anyone can join groups
temporary or persistent group — a games working group is a community of interest that doesn’t need to finish, but is a gathering space for games topics over time
cadence for meetings or updates — maybe a synchronous call every two weeks or a monthly check in; or asynchronous updates via text as code or interop progresses
where and how to participate: this forum might just be background, pointers to resources and updates, and the activity is in a Discord or Signal channel, or in the issues of a Tangled repo
Any other comments on the role of working groups, desired features, or anything else Lee related very much welcome.
We started with regional groups but no reason to not actually surface communities of interest / standards interop work / etc
Right now the simple version would be to just PR the communities YAML file. But we do have open social “groups” on the site and so maybe we wait until that’s in place and encourage people to set things up.
The group description / setup could add links to the forum here if desired.
This would then expand the functionality to have on-protocol member lists, aggregated standard site posts, and aggregated events.
This is all pre-permissioned data but our intent is to migrate it all to be part of the groups / spaces work that evolves and compatible with what bsky social app ships.
Tagging @vicwalker.dev.br in particular to mention that this is the “beyond just devs” ideas.
Oooh I love the idea of mirroring the groups onto atmosphere.community. One thing I struggle with with Discourse is trying to wrap my head around the “current state” of a working group, what has already been discussed, when folks are meeting, etc. I think it would be helpful to have a tool (maybe on atmosphere.community) to sort of organize a working group to show a summary of “what has happened so far” and “what’s next” in a single spot.
I also have been debating writing up a post about using figjam as a collab tool for the Atmospheric Groups working group, because I think that has been a helpful pattern that could help other groups, too!
I think useful tools and ways of working is great to share! Probably the top level of Working Groups is a good spot (and I should move this thread there)
With login.atmosphere.community it would be helpful to continue to have SSO, and over time groups/spaces for permissioning.
Current state: yeah, including a process for archiving. The Working Groups > WG E2EE is effectively stale as one example (and sort of started at a time when WGs were maybe a different shape).
I think the rest of it is hard to do … “when was the last post or meeting” and sorting groups by activity are probably a good “automatic” sign.
This is my biggest Discourse struggle, too. This is a good shape for discussion, but bulletins or wrap-ups would be incredibly helpful, and could maybe be automated, at some point?
agreed!! I’ve wanted to do this for a while, and I’ve been thinking they may actually make sense as sub-communities of their own. It’d be interesting to map two separate type of sub-communities with different structure/needs to the same DID, and it’d stress test the flexibility of the system.
This is just “who can post to this group’s about/updates page” in another form, which is another thing I’ve been interested in prototyping. Or it’s like sharing a leaflet to a specific sub-community, if it’s more episodic.
My struggle with Discourse has been similar and part of the reason I was looking forward to making this “latest” view. I could easily repurpose that for specific tags/categories, and give every group its own page where you can go check that out and/or make a global overview. Maybe not the perfect form, but could at least be a start.
Yeh, I think by outsourcing all the actual app-functionality to designated atmo apps, atmosphere.community can create a management UX for working groups that approximates the likes of Basecamp project boards:
