Beware of the “whatever” aproach.
Many years ago I was brought into a project where many variables where named after cars. Before I got there, if the team couldn’t agree on a name, they’d use a car and move on. There was also a module in the code call “bucket”. Didn’t have a logical place to put a function? Add it to the bucket.
I’m sure they saved a lot of time not discussing what to name things up front, but by the time there was enough turnover on the team to change the variables and rewrite, it took months to fix.
Another, more product approach is to ask the “variable naming guy” to write up a naming policy document that would result in the names he has been suggesting. If there is logic associated his side of the “argument” it should be easy to document.
Have everyone on the team discuss and approve the policy. Hopefully you never spend time in a meeting arguing about this again.
I’m not directly involved in either project beyond reporting bugs and suggesting features yet, but I follow both projects closely. My sense is that the Mbin community is prioritizing collaboration around UX improvements while Kbin is focusing on scaling/performance issues… which makes sense as kbin.social is more than 10x the size of fedia.io (https://fedidb.org/network/instance/kbin.social vs https://fedidb.org/network). I opened a bug about the UI for altering link images at https://codeberg.org/Kbin/kbin-core/issues/1365. When I tested the same steps in Mbin, the issue i was seeing in Kbin had already been solved in Mbin.
Kbin is a great PHP implementation of ActivityPub for reddit-like communities, but requiring all major changes to be made/reviewed by a single person is a real bottle neck.
It would be great if Kbin could figure out some form of goverance/delegation that would allow more contributors, but there doesn’t seem to be much interest in that type of change so for now we have 2 project with different priorities and governance models… and that isn’t necessarily a bad thing.