Somebody who was previously active on the kbin codeberg repo has left that to make a fork of kbin called mbin.
repo: https://github.com/MbinOrg/mbin
In the readme it says:
Important: Mbin is focused on what the community wants, pull requests can be merged by any repo member. Discussions take place on Matrix then consensus has to be reached by the community. If approved by the community, no additional reviews are required on the PR. It’s built entirely on trust.
As a person who hangs around in repos but isn’t a developer that sounds totally insane. Couldn’t someone easily slip malicious, or just bad, code in? Like you could just describe one cool feature but make a PR of something totally different. Obviously that could happen to any project at any time but my understanding of “code review” is to at least have some due diligence.
I don’t think I would want to use any kind of software with a dev structure like this. Is it a normal way of doing stuff?
Is there something I’m missing that explains how this is not wildly irresponsible?
As for “consensus” every generation must read the classic The Tyranny of Stuctureless. Written about the feminist movement but its wisdom applies to all movements with libertarian (in the positive sense) tendencies. Those who do not are condemned to a life of drama, not liberation.
I agree, this is a wild reactionary shift to the issues they’ve seen with kbin. Unless the community “consensus” includes people actually reviewing and testing this is just going to put the repo admins in a tough situation when they have to merge in some broken commit the community voted on.
It looks like they’re still working out what they want their process to be:
https://github.com/MbinOrg/mbin/pull/34
Seems like your concern is addressed there:
Pull Requests require at least one (1) other maintainer approval before the PR gets merged (built-in peer review process).
The mbin fork happened when kbin development was looking a lot less active. In any case, it’s not necessarily bad to have a diversity of approaches. Due to their differing organizational structures, mbin will likely tend to have more features and more rapid development, but also potentially more bugs, while kbin remains more stable.
I cant follow the convo to tell if this is the actual state of things or just something thst was being discussed but:
16 Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, © engaging with the Contributor on improving their patch quality.
What an idea.
From the PR comments:
Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, © engaging with the Contributor on improving their patch quality.
I asked around and asked in the C4 specification matrix room.
And the reason is actually simple. If you merge bad code, have a record of proof in git (pull requests aren’t forever it’s only a github/gitlab thing).So the idea is if you merge bad code you have proof in the git record that there is a bad actor. You can always revert the commit again or fix it. And the record can act as a proof in case the community want to get rid of bad actors.
I think it’s an interesting experiment. If it survives natural human tendency to mess with things, then it could be a good process discovery that is further refined and implemented elsewhere.
I don’t have any reason to believe it’ll be a success, but that shouldn’t stop people from at least trying.
If it’s any consolation, you likely won’t have to worry about using it, as its liable to be unusable.
Sounds like it’ll be a disaster