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.
Hi, good to see you here :) I honestly have no idea what the pronunciation is. It's a reference to the Linux /sbin, a container for things that are important to you. This is intentional, I want /kbin to be perceived as each individual instance. Each instance is different. Each community is different. That's what's cool about the Fediverse.
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
This early in a project, figuring out how to manage it effectively is a big part of the work, I think. There's no inevitability to either project failing or succeeding. I hope both projects do something cool, and if one fails I hope there are a few forks of it ready to carry on with the best parts of it.
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.
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 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.
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.
Unrelated username commentary: Your leet/hex username had me wondering if it resolved as an IP address too. Turns out you belong to the US Department of Defense. Unsure if you knew that already.
For obvious reasons, I decided not to try to actually visit that IP.
I don’t think pitching #ActivityPub to existing social media makes sense. Adding federation to a non-federated social media service isn’t a net win.
You have to spend the time and money to implement it. Then you have to spend the time and money to maintain it. Most of the time, ActivityPub support is implemented as mastodon compatibility, not true AP support. This means having to constantly make sure you keep up with masto changes and constantly fielding issues with other implementations because you didn’t fully implement AP.
And after implementation, you don’t just gain access to a ton of new users, you have to take on the burden of moderating all of it (which is a persistent ant recurring time and money cost). And since the #fediverse has a ton of opinions on moderation, you’re always pissing somebody off.
And after all that, what you’ve enabled is an easy way for your users to recreate their social graph without your service. The idea of an interconnected social web is cool, and hopefully it’ll be the futrue, but it doesn’t make sense for profit-driven businesses.
Mate I think people are just kinda lazy and don't really care that much about privacy relative to ease of use and the presence of people they're interested in.
@BraveSirZaphod In that case, both of your hunches are right, no matter the Curb-Stomp Battle we indeed are facing in the name of the Internet's future path.
fediverse
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.