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.
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.
It is good to really see your true nature now. I’m also think the fork is the best thing that could have happened for the community. It’s a pity that you never started a conversation, but instead you still try to do mean things like this.
Oh c’mon, don’t be mad. It’s just a wrong sorting of posts, it’s in an edge case, and seriously it wasn’t intentional. I just wanted to check how such management looks in practice, how many merge accepts are needed, etc. I didn’t mean to do anything wrong that could cause harm. I even push the same code to my instance to facilitate your tests ;)
But you’re right - that’s just my nature. I approach PR with very limited trust, whether they’re mine or from others.
I know your approach on PRs. Hence the main reason of the fork. The community does believe in their people and the good in mankind. Only 1 approval is required from another maintainer for now. We are using C4 way of working.
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. I saw that you were syncing and I was hoping to benefit a bit from it once you fixed it. I didn’t expect the review to happen so quickly. By the way, I was genuinely curious about how this project management method works because, you know, I’ve always avoided such an approach. Merloy, you know how much I owe you, and I appreciate what you’ve done for the project, as well as the other Mbin contributors. Our overall visions haven’t always been the same, and I think it’s great that kbin has been forked. You see for yourself how my work looks until the release - there are many things I’ll be refining over time. That’s why I’ve put a hold on all other PRs, and now I want to focus on this.
@ernest @melroy
lol this whole conversation is a microcosm of the open source community. I agree with ernest that forks are great and would add that they show that the open source system is working as intended.
You are right. But was the whole debacle that lead to this fork being made worth it? Wouldn’t it have been much better if Ernest had just sorted out all himself and we’d all be working on the same project together now instead of introducing mistakes into forks too see what happens? What a complete waste of time, especially under the current circumstances.
“True nature” in this case appears to be slow and cautious. Shocking stuff!
Ow… it was 100% intentional. You said it yourself: “Wiem, szczerze mówiąc było to celowe. Zauważyłem, że forki synchronizują od razu zmiany z /kbin.”. https://karab.in/m/karabin/p/340377/Usterka-z-crosspostami-nie-zawsze-sa-przyporzadkowane-odpowiedniemu-watkowi-matce-at-ernest#post-comment-510980
@melroy I don’t think you can really be upset about anyone putting through bad code. According to the philosophy as I understand it, bad code (intentionally so or otherwise) is a useful contribution and you are basically soliciting it. You supposedly have some way other than code review to ensure nothing harmful gets through and it has to do with the reputation of the contributor. Since you already knew @ernest and clearly have a bad opinion of him, how did it happen?
I did not and could not review the PRs themselves. So I am just going on the information as presented here. Sounds like @ernest put through some code (either into kbin or mbin not clear on that) which he knew was not 100% highest quality but which error was not critical or devastating. And that it could easily be found and fixed. Partially he did this to learn more about this governance model. A model which has apparently been developed in direct opposition to his own. Is it approximately accurate?
If so, sounds a bit mischievous at the worst.
I really can’t recommend Tyranny of Structurelessness highly enough.
Well I don’t have a bad opinion about him (those are your assumptions), we just didn’t agree on how a community project would/can work.
If however he did introduce intentionally a bug in kbin, just because of Mbin that’s downright childish. The Mbin community does try to test all the incoming PRs (not just kbin sync PRs) on various instances apart from unit-tests, etc. We just do not want to depend on a single maintainer, hence a different way of working in the project.
He saying Mbin can’t handle the kbin changes that is just not true (Odpowiedź: nie radzą sobie), at least we try to keep in sync (eg. for API comparability for upcoming mobile clients). But I’ll leave it this, I’m not going to waste any more energy. I hope you understand.
Thanks for your recommendation.
Yep, in Polish we call it skrót myślowy.
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:
Ernest has said many things in the past and many times has not lived up to his promises. So I doubt this words now. Also he’s already contradicted himself on this matter.
Yeah, that’s true. Real-life stuff was kinda more important for me at the moment than managing the project.
For me, it’s straightforward: I pushed some dev code that wasn’t even a complete feature, and it got approved in your pull request. That’s why I was advocating for everyone to only merged their own PRs in the /kbin repository – so that each person could take responsibility for their own work. I won’t go on about this any further.
As it should be, always, for everybody, you won’t ever hear me judge you on that, so please don’t try to make me look bad by implicitly suggesting I am.
What you failed to do however is delegate, even temporarily, your responsibilities to people you trust. Instead you left people who trusted you dangling, only sporadically feeding them promises you would never fulfill. It seems keeping them on a leash was kinda more important to you than securing the future of kbin.
I hope I’ll never have to mention this again, so you’ll never have to. Which would imply that you’ll have come to terms and lived up to your promises, both recent ones and from the past.
Yes, I say this fully aware - there are many things that I have failed at. Much of what I said, I failed to achieve. However, I never wanted to keep people on a leash; I am more of a person who prefers to stay on the sidelines and engage in what brings me the greatest pleasure - coding, just like any other contributor.
Believe me, I tried to delegate tasks, had many private conversations and discussions. Perhaps it wasn’t visible from the outside. However, in that mental state, the last thing I wanted to do was resolve conflicts among adults, and it all started to boil down to that. As @BaldProphet mentioned - “microcosm of the open-source community.”
Moreover, there were too many different visions of the project, ignoring requests, etc. That’s precisely why I decided to temporarily halt development, to secure the future of kbin. It was my decision, and as I mentioned, forking turned out to be the best thing that could happen. As you can see, the differences are not that significant, but it will be easier for all of us - especially since we can always draw inspiration from each other, and I don’t think anyone has a problem with that.
However, I still maintain contact with many people, and sometimes they mention to me the attitude of certain individuals on mbin’s Matrix - it is at least puzzling. In any case, I want to stay away from that and focus on my work with contributors who understand and prefer my approach.
Despite the fork. I hope we can learn from each other indeed. That will only benefit both of us.
Although we merge into main it’s not a release, we use GitHub/Docker tags to mark releases. And use semantic versioning if needed for minor and patch releases.
Thank you for your in depth, genuine, reply
I am sorry but I’m having a hard time believing you when you say that you were seriously trying to delegate, as not a single soul ever said anything which would remotely confirm this. I believe you had conversations, but they ultimately didn’t result in anything in this context.
I am not sure how to interpret this as there were no conflicts that I’m aware of that needed resolving during your absence, everybody was just waiting
There’s nothing wrong with being like that, there are other people willing to do things like resolving issues. Like me. I realize I appeared out of nowhere. As a new instance owner it took a while for me to notice, but when the situation became clear to me I was ready to jump in and help, just like all the other people who had offered their help (before me).
You’ve basically just admitted that you were either incapable of or unwilling to engage in structural problem solving and management of the kbin project. That’s fine, but you should have reached out and informed the community as soon as you became aware of this.
Yes, forking can have positive side effects and perhaps having two versions in development synchronously can merit more than one. This however was not the proper way to achieve this and using it as an excuse to justify your behavior and inaction is unjust.
However, it is not too late. You can still do the right thing by starting delegation now, by clearly assigning multiple people to all essential tasks, and giving multiple people complete control of kbin.social, so that, should a similar situation occur in the future, you and the community will confidently know that the project will not grind to a halt again.
Then seek a constructive dialog with the mbin community and we can make the project, in it’s current for, work. Together.
If you feel uncomfortable with or are have trouble doing any of this, as you’ve clearly indicated you’d rather spend your time on coding, you are always welcome to ask me for advice.
Never hesitate to ask for help.
Now, you see, this is the part that I as an uninvolved observer who’s just now catching up on the happenings do not get. Promises that were never fullfilled?
How long has or hasn’t this actually been an issue? Because from what I can see looking at the codeberg commits, it seems like development stalled for how long, like a month or so?
I totally get not wanting to be left hanging and having some answers and pathway for how contributions can happen. But as you also agree on, I also get real life being more important and getting in the way sometimes. And in that sense, being out of it for a month or so does not exactly seem like an earth-shattering amount, even if it’s annoying when it happens to be the project lead and not much can happen.
I just can’t help but feel like all of this has been pretty impatient and premature, which also makes it hard for me to really understand the point of the fork, even if I can relate to the basic rationale behind it. But then again, I have no knowledge of the direct going ons and communications between the contributors and the events that led to this. So there might be a lot I’m just not getting.
@fr0g I am in substantial agreement with you after reading all this back n forth.
Possibly becausE - you kkkw, urgent real-life stuff got in the way