Modeling Governance & Community

[xynydev]

With a new project with an existing, thinking of and setting up sustainable governance models is something we probably want to work out before anything too big happens. We could probably take the model from ublue, retaining the lazy concensus bazaar approach. Write-protecting repos (so requiring reviews) is probably a good idea, but for the initial growth period we should probably keep it pretty fast-paced and open.

[gmpinder]

Agreed here. So long as we can keep voting times long enough for people to have a chance to vote.

I'm down with the fast-paced to start as that's how I work best for initial implementations.

[fiftydinar]

I also agree

[bayou-brogrammer]

With voting, what is the timeframe for rapid development?

[xynydev]

I have added in the https://www.contributor-covenant.org/ (used by ublue too) to the community page in the WIP website. There's still stuff that ublue has and we don't: Mission, Scope, Values, Contributing/Lazy Concensus.

[xynydev]

I think the code owner system will work for us for the time being, so I'm closing this discussion. If issues arise, we can just create a new one.

[xynydev]

I'm just now thinking that the codeowner system kind of makes me the BDFL for repos I am the sole codeowner of. I of course wish to review most PRs to those reposbat least to evaluate their broader implications in the project and analyze their code so that I understand how they work, but there might be weeks where I am too busy to do any reviews.

It would be best to set up some sort of approver system or ruleset to make other org members able to approve PRs to key repos, and have this standardized accross the whole org. Code owners in each repo would still be the designated maintainers and take on most of the work of maintaining, but a certain amount (one or two) of other org members approves should still be enough for a merge when required.

[bayou-brogrammer]

You can setup merge queue to do various things. I have seen them mostly used to block merging pull request until a certain set of conditionals are met. You can then have your CI system auto merge the PR after approval of a maintainer

[xynydev]

I have now added some rudimentary branch protection rules to the repos still lacking them.

Still need to look into rulesets and merge queues. Would be nice to have a set amount of any approves be able to merge a PR lacking a codeowner approve. Still should add a second codeowner for some repos, like modules.

@fiftydinar you wanna be codeowner for modules? Your code is pretty good. I'd wish to review all docs, though.

[fiftydinar]

@xynydev let's do it!

[gmpinder]

@xynydev if you need any help with the rulesets I'm available to help. I've got that setup for the CLI repo right now that makes it so that it requires at least 1 code owner to sign off and that certain workflow jobs pass before allowing merging. (As an admin you can override that if you really need to)

[xynydev]

I think what we currently have already does that, requiring a codeowner review and workflows to pass. What would be nice is if a codeowner review wouldn't be required incase there are two approving reviews from other org members.