HOWTO: Create an Architecture of Participation for your Open Source project

I feel like this is a stumbling block for me, always. I’m a seer (in the mystical sense only because it is also very mundane). I see stuff. I see projects complete before I can explain to another person the first concepts.

I’m very good at finding shortcuts and strategy meetings. I’m not very good at building clear missions.

I applied these steps to the idea of a single talkgroup (talkgroup audit (2020) - #13 by maiki), so let’s zoom out and look at talkgroup.xyz as a platform-domain.

Ahem.


talkgroup exists because I see so much, including how everyone will screw us over unless someone sets up network services with the best intentions. I know how to set up lots of things, but am always struggling with resources. Literally: no monies. It means we have to be clever, and reuse as much infrastructure as possible.

talkgroup exists because it headlocks Discourse into serving as a bunch of mini-projects, so we’d have a tool to reuse for our projects that aren’t funded, or otherwise tied to capitalism.

talkgroup exists because every platform I use leaves someone out. talkgroup does too, and I’m working on it.

And that is the crux: I don’t have a clear mission because my mission is every other place is a fucking dumpster fire. But ya know, there it is. That’s my perspective, and the cap on what talkgroup becomes.

That said, it’s become a fabulously knowledge-heavy resource. It’s my primary way of interacting with the network. I’m happy.

So, let’s ask some questions:

  1. Is more participation something talkgroup benefits from? (Maybe not, maybe it’s the “correct” level for noise-to-signal ratio)
  2. If so, how do we move forward (and please answer in the form of a clear mission statment :slight_smile: )?