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, (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.
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
I do love Mbin, I just wish we had an area instead of Matrix to talk about things that we want and stuff.
I'm still not getting the point of mbin. I mean, options are nice, but what's the value it brings over kbin?
they don't use github issues?
They do but it would be nice to have a place to talk about it in a Magazine instead of having to go to external sites
Can't make a magazine? https://kbin.run/newMagazine
It's not that I can't make a magazine, it's just it won't be looked at or be used as an official one. So it would be worthless creating one
How do you know the future?
If you are correct, it is very strange. Why would people who are so passionate about creating a social media platform refuse to use it?
That is correct, we do not have an "official" instance or an "official" magazine. What follows now is MY OWN opinion, other community members might think differently.
Mbin is aiming for a federated and decentralized social network, I think the whole point of the fediverse is that there shouldn't be one main instance, right? Feel free to create a magazine where ever you want! Isn't that the beauty of activitypub? Maybe the idea takes some getting used to.
here we all are talking about it on fediverse@kbin.social which certainly isn't Official Fediverse comm.
kbin.social is the official instance of kbin ;)
Your community members ("I do love Mbin") are expressing that they are unhappy with the mediums available for discussion and feel excluded. What is done about it?
I feel a bit of negativity from you. This will be my last reply in this thread. She has resolved it herself by creating a magazine by herself on Mbin for Mbin: https://kbin.run/m/Mdev
It seems to automatically pull all changes from kbin anyway so I don't know about this consensus approach.
Hmm, that seems like not such a good look from Ernest. According to google translate:
I know, honestly it was on purpose. I noticed that forks sync changes immediately with /kbin. I wanted to check how they deal with this much-announced community-based qualitative code review. Answer: they can't cope. Quite an obvious bug was accepted in PR and domerged into the main branch :P It now works properly on the rifle ;)
Hopefully everyone can play nice and work together productively.
seems like you are saying ernest put thru an intentionally malicious PR to see what would happen? And what happened was exactly what is described? I mean, ya, thats what people will do.
It wasn't entirely intentional, it was actually my mistake. But I held off on pushing the hotfix for a while. It was a development branch, so these kinds of bugs were permissible - in this case, it just changed the order of related posts, nothing serious. It was quite easy to spot and fix. Slow and cautious acceptance of pull requests, something I spent a lot of time on, was the main accusation from the creators of forks. Hastily accepting them was a problem for me. I personally considered a consensus similar to that, but now I see it doesn't make sense. Someone needs to take responsibility. Personally, I believe that forks are the best thing that could have happened to the project.
In hindsight maybe we should have responded by saying we merged your mistake intentionally to see how you'd respond.
i am not being serious of course, as that's not our community's nature. Even though it's allowed to gather proof, we (I am quite sure I can speak on behalf of the community here) would never intentionally introduce bad code into software which is being actively used.
Ernest, you have seen me before, pleading for you to change your ways, on all fronts. This, sadly, degrades the faith I have in your project being suitable for being used in production, from a pragmatic point of view. Kbin may be reliable, but you are not.
Ernest said he didn't introduce bad code on purpose:
I assure you that I didn't intentionally push incorrect code into the repository. These were my first lines of code in a really long time. I simply got involved in other things that I wanted to finish first, and I noticed the edge case in the meantime, but it wasn't a priority.
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.
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.