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.
this post was submitted on 09 Nov 2023
12 points (100.0% liked)
Fediverse
287 readers
1 users here now
This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.
founded 1 year ago
If it's any consolation, you likely won't have to worry about using it, as its liable to be unusable.
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, (c) 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, (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.
Sounds like it'll be a disaster
Thanks for your feedback.
We do have code reviews in GitHub and discussions on Matrix. We updated the README that reflect our latest way of working. As stated in the comment section we are also working on it in PR: https://github.com/MbinOrg/mbin/pull/34. Feel free to comment on that.
As a person who hangs around in repos but isn't a developer that sounds totally insane.
Why do you hang around there then? So you can write articles like this in an attempt to stir the shit? What is there to gain from that, for the fediverse?
I'd also like to know how you hang out there then, as I can't seem to find a person called Density hanging around? I might not be looking in the right place, of course