Governance

[vmx]

I'd like to add some form of written down rules for governance/decision making, so that it is transparent who is allowed to merge what or if there are any disputes.

I've asked @mikeal for advice and he pointed me to the Node.js Community Contributing Guide 1.0 and the corresponding blog post he wrote, which explains in detail the reasons for every sentence in there.

I really like those guidelines for being short, easy to understand and actionable. I'd like to use those as a basis for discussions. I personally would adapt them as they are.

[dvc94ch]

yep, looks good and I think we're already doing most of that. Do we need to establish a TC? I'm not sure we have enough members for that...

[aphelionz]

Thanks for opening this issue, @vmx and thanks for commenting @dvc94ch.

We have the baseline for Contributing guidelines but it's nowhere near as fleshed out as the node.js one.

If I can make a good-faith attempt try to sum up the primary contentions that we've had in the past, it would probably be something like the tension between exploratory endeavors and trying to deliver according to deadlines / deliverables that are set by outside sources such as PL. I think people should be able to explore, but it becomes difficult to make things "official" aka merging to master without test coverage / benchmark, aka the data to prove the results.

All that said, I think this is fairly manageable and we can all work cordially together. That's my intention, anyway. We just need to figure out the best way to go about it :)

[aphelionz]

Do we need to establish a TC? I'm not sure we have enough members for that...

I'd agree, at least for now

[aphelionz]

Random thought: The benefit of having an official document for the "rules" shifts the framing from person-to-person conflict, to the people involved together looking at a third-party document and trying to solve an issue collaboratiely.

[vmx]

Do we need to establish a TC? I'm not sure we have enough members for that...

I'd agree, at least for now

Yes I also thought that we probably don't need a TC. Though we could change the language and make this the group that has admin rights on the GitHub org. I think it should be transparent who that is and how to get there.

[aphelionz]

Right, it's a decent balance now - one person from each "org" or interest group.

@dvc94ch as the originating author
@vmx representing PL
@aphelionz representing EQ

I admit I wouldn't know where to begin on "how to become an admin" without upsetting that balance, but I'm open to ideas.

[vmx]

I admit I wouldn't know where to begin on "how to become an admin" without upsetting that balance, but I'm open to ideas.

Just as you would add members to the TC, through consensus within the TC.

[aphelionz]

@vmx is there anything in particular you like about the Node.js guidelines that we should consider merging into ours? I'll go through it myself as well and see if there's anything I think would be useful.

[vmx]

is there anything in particular you like about the Node.js guidelines

All of it.

[vmx]

having a “way to do this” in one language

After a second thought. I think the TC part is important for us (whatever we will call it). That explains how to get into that level and there is always consensus seeking on decisions. Currently I don't see any problems we are hitting, but that could change in the future and we should have rules for that.

[mikeal]

Ya, it doesn’t matter what you call it, but having a separation between someone with “commit/review rights and responsibilities” and the “admin & big decision makers” is a good practice. It lets you reduce a lot of barriers to on-boarding new contributors since you’re not making them an admin and it clarifies how bigger decisions are made in the project.

[vmx]

merging into ours?

Do mean with "ours" the Contributing to Rust IPFS?

To me those are more specific to one project of the org. I suggest that we create a document (can be called CONTRIBUTING.md to make it work nicely with GitHub or something else live governance.md) in this repository, which also contains information about the TC. We would then link from the rust-ipfs CONTRIBUTING.md to this one.