Mbin: A kbin fork that promises to never review PRs before merging them ( kbin.social )

cacheson , 7 months ago

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.

density OP , 7 months ago

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, (c) engaging with the Contributor on improving their patch quality.

What an idea.

cacheson , 7 months ago

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, (c) 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.