Governance structure & documentation

[hackergrrl]

Excited for this next iteration of Dat. 🎉

I wanted to start a conversation here around ownership and governance of this organization, and of the modules that make it up. I want to be really upfront that I'm not very versed in open source project governance, especially for something as big & important as the hyper* modules, so it'd be cool to try and figure this out together.

Some questions that come to my mind:

1. What is "Hypercore Protocol"? A closed group? An open consortium? Something else?
2. How is membership decided?
3. How are breaking protocol and storage changes decided & communicated?

I'm sure y'all have others. The hyper* stack has grown into a valuable piece of where the internet is going (my experience). My intention is to move us toward having a written documentation that clearly outlines who & how these wonderful modules are managed & governed, so it's clear how we can iterate on it with clarity together.

CC'ing some folx who may be interested in this convo: @mafintosh @pfrazee @cblgh @RangerMauve @okdistribute @substack @gmaclennan @Frando @martinheidegger @andrewosh @emilbayes @sammacbeth @ninabreznik @dan-mi-sun

[mafintosh]

Hi @noffle, thanks for bringing this up

First of all let me say, this is still very much a work in progress.
I can try and answer some of the questions

1. It's a technical working group for the Hyper* modules that I have been the core maintainer and dev of the last many years, combined with the work @andrewosh has been doing on the daemon and Hyperdrive for those. It also encapsulates the Hyperswarm ecosystem (although we are keeping that in its own organisation for simplicity). We added a community repo here as a centralised repo to kinda track these discussions and to have better "persistent" communication. The rest will just be the central deps of Hyperdrive/Hypercore to have them one place.

2. Hard to say what membership is in this regard, but there is a core dev team who's been maintaining and working on this stuff who's technically the admins of the org. As the core team grows/shrinks that team would grow/shrink with it. As mentioned above this org is for technical stewardship.

3. Communication, especially around breaking changes, is a key idea here. Having one place where we can discuss these and get a sense of the impact is super useful for us, as core dev, and obvs also helpful for people downstream of the modules. We signed up for Github discussion and are also setting up a Discord, for focused core dev talk to have clearer communication and community participation.

A big part of this, from my own POV is also just getting everything properly documented so we have clear specs and educational material on the tech side of things. (The website which is launching tmw has some of that early work on that)

For governance we are (slowly but steadily) trying to get everything clearly spec'ed out in the HYP repo to clearly define how everything is supposed to operate. Can't make any promises on how fast we'll get to that as we still have a lot of work today making everything better tech wise, but definitely something that will happen. The HYPs are only meant to cover the functionality of the core Hyper* modules. For more community oriented things (ie how do different Hypercore data structures look like?) we probably need a different process - at least that's not the purpose of the HYPs.

To govern the technical HYPs on Hypercore/Hyperdrive/Hyperswarm @pfrazee mentioned in his email that we'll run an open process but at the end of day I'll make the call on those. I'm sure not everyone agrees with that, but it's a start and it's how core dev has been running the last few years as well. As things stabilise and grow for "core", we'll definitely revisit that. In general I'm a reasonable person with a long history of hyper* work and I look forward to continuing all this work for as long as possible.

I hope we can get more things written down and make everything more clear and explicit.