Issues/PRs moderation

[moul]

We require moderation, but the question remains: who should spearhead this effort? Who holds the authority and duty to moderate?

I offer my assistance, either in suggesting moderation strategies or in actively implementing them. Ideally, this should be a collaborative or rotating responsibility. It's crucial that we clearly communicate the rationale behind any decisions to close or merge, and provide clear guidelines for individuals to voice concerns if they believe a moderation decision was unjustified.

Additionally, we could enlist the assistance of others, or perhaps utilize tools like ChatGPT, to help identify areas with the most pressing need for moderation. See #24.

[giunatale]

oh yeah this is very much needed. I also offer to help to the best extent of my capacity and time I can allocate.

I am already trying to reply whenever I can but I am already falling behind on the amount of issues piling up.

[jaekwon]

On AI: https://github.com/atomone-hub/genesis/issues/39 I vote to not rely on AI for AtomOne core anything, even weekly meetings. But let's keep the poll/discussion in that issue #39.

We require moderation, but the question remains: who should spearhead this effort?

What kind of moderation? Once we get a problem we can consider how to address it. If it is about the issues and discussions, and less about the Founding Documents, then I think we can try some experiments more liberally.

It makes sense for AIB to start, with the goal to expand this beyond AIB by the time gensis happens.

The README.md has some about a technical steering committee, but maybe it also makes sense to have an independent operations committee, where the operations committee is not self-selecting but otherwise mostly self-governing and members are somehow elected (e.g. NO+NWV on 848 can vote new members into an operations committee) and they can decide how to handle this (using transparent methods, bylaws in this repo and later on chain etc). But for now it's just AIB and I can add you both give me a few days.

But let's specify the limitations of the operations committee.

As for the kind of moderation about the content of the files, like the founding documents and constitution, this requires more expertise to vet every change against the multidimensional concerns. Maybe there should be almost a subset of the technical steering committee that is the constitution steering committee. But this is tricky IMO we need more issues and PRs and debates before it's clear to me how best to expand this set. I like the idea of leveraging independent files/directories and github's CODEOWNER system to expand the list of maintainers.

(like the project "let's make it possible for no+nwv voters on 848 to vote off-chain" should be in its own file and referenced directly or indirectly from README.md. In general the more things move out of README.md the less contentious this will become over time)

Theoretically these discussions and the best ideas from them are what should be incorporated and hopefully we have enough alignment that we can complete much of the founding documents without contention. In the worst case, anyone can fork the atomone-hub repo and create a competing plan/proposal/partyhub that does better than what we're doing here. Until genesis AIB will hold onto any rights (if any) of "atomone" on behalf of the chain to be launched; so if there is big disagreement against AIB then the fork should be named something else other than "atomone". But we should cross-link our proposals so everyone can discover all the forks.

Maybe we have a "constitution convention" where everyone can share their forks of AtomOne (with various distinct names), then we can gauge interest and the potential likelihood of adoption of these forks, and probably one of these or some merger of ideas will naturally win.

If I see a better strategy for say, rules of membership to each steering committee or working group, and the strategy is well documented and discussed, then I will just adopt that strategy if it seems superior. If it seems that the strategy is open to manipulation or sybil attacks or generally will lead to a less favorable outcome then I will not, and in the worst case scenario a different fork with a different name than atomone will launch and gain the most adoption out of all of these. By "strategies" I basically mean bylaws written in a separate markdown file, each created along with discussions in issues and PRs here or anywhere.

Even if a fork gains more traction than this particular repo, if the fork is still aligned with everything I've written about AtomOne (e.g. since prop 82) AND the new fork in its system/bylaws etc is reasonably secure, then AIB will yield the name AtomOne to the chain that launches with that fork, but I hope everyone lets AIB ultimately determine what "AtomOne" means because it really is an AIB incubated brand.

[stevenoruzi]

If you require additional assistance with this issue, I am ready to offer my help within the limits of my capabilities and the time I have available.

[jaekwon]

For now I have added @moul and @giunatale as members of the atomone-hub repo because they have committed to and made significant contributions to this repo. But this isn't for write access to the repo files. Now every change to the repo must come from PRs with discussion, and I will still play the role of push master until there is a need for something else.

Also I'm still interested in setting up the CODEOWNER system so anyone who owns a file can push a commit themselves to that file. Is this possible?

[moul]

Also I'm still interested in setting up the CODEOWNER system so anyone who owns a file can push a commit themselves to that file. Is this possible?

CODEOWNERS automatically asks for PR reviews for specific files. You can set merge rules in 'Protected Branches' in repo settings, like needing 2 CODEOWNERS approvals (will make sense with more members IMO). But, you can't push directly without a PR and review using just CODEOWNERS.

Custom GitHub actions might work, maybe someone has a solution? I suggesting keep merging manually for now.

The real expected change: the community members should start approving or suggesting changes on PRs, to scale the moderation.

I'll set up CODEOWNERS to add file authors as reviewers for their PRs.

[jaekwon]

I think with the above, maybe we only need 1 codeowner review, so the codeowner can push and merge? Either way, practically it isn't a problem right now and might never be.

[moul]

Right, this is the setup I use for decentralizing authorship.

You should change the permission from 'triage' to 'write', as your screenshot already safeguards against direct, unreviewed pushes.

The limitation here is authors can't approve their own PRs and always need a second review. It's good to keep this extra review step. For each file you don't oversee, we should add at least two code owners in CODEOWNERS. Otherwise, a file's original author can only merge contributions from others, not their own updates.