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.
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.
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.
Are you blocking the individual users, or the domain? I've heard that domain blocking is buggy, so try unblocking any domains and see if it helps. It also isn't supposed to block instances, just posts that link to the blocked domain.
The same thing seems to be happening with [email protected] and [email protected]. The former hasn't had a post show up on kbin since July 13th, while the later doesn't appear to have any posts at all. Initially I was thinking maybe it was due to the lemmy bug that mistakenly marks some connected instances as inactive and stops sending them updates. It may be specifically because these are bot accounts, though.
I feel like the microblog feature would be more useful if we could get a separate feed/filter that doesn't include the tags of magazines that you're subscribed to. For example, I'm subscribed to /m/fediverse because I want to see the threads that people post here. I don't necessarily want to see every mastodon post tagged #fediverse, though.
It also looks like we can't subscribe to a tag by itself, without subscribing to a magazine that includes that tag. So yeah, some more separation there would be nice.
Yeah, basically like newcommunities/communitydiscoveries. I figure since new instances are less common, it would be feasible to maintain a master list there. Whereas newcommunities gets several posts per day.
