I'm not sure what goes wrong, assuming kbin.social didn't block fedia, then I suspect some kind of issue at fedia.io. I believe we need to debug this issue on the server-side. Hopefully @jerry can have a look at his logs when trying to execute the search query above and maybe find the root-cause that way.
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
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.
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.
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.
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.
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.
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.
I was also trying to prevent a fork, but I didn't saw any way out. Hence the fork by the community, for the community. I hope so as well, the idea is that we work as a real team and active contributors have GitHub owner rights. We peer-review each other code and are allowed to merge pull requests. There is no single maintainer, we are all maintainers.