/kbin meta

@Mnmalst Yeah, I am well aware of what you're talking about, and I am trying to maintain a balance. I knew that it could look like this at a certain stage, but I didn't expect it to happen so quickly ;) I assumed I would have a bit more time to prepare and acquire knowledge. Now I have to improvise. I make mistakes, but I try to fix them and always keep an eye on the big picture. That's all I can do. Working with pull requests is great, I enjoy learning new things from others, and it's also fun to discover bugs together. At least for now. ;-) But I always emphasize that my priorities are my milestones, which keep me afloat, so I care about organizing our collaboration as quickly and effectively as possible. However, we also need to get to know each other a little better.

I think it's important to not have a single person having to deal with those. But admittedly it's hard to get to that point. I've only significantly done established, commercial software dev, where you can just trust your coworkers. Random people on the internet are harder to trust. Anyone can play nice for a couple of days for a chance to slip in something malicious.

The project is not only rather new (so any contributors are gonna be new), but it's also hosted on an unfamiliar site (which is to say, it's not GitHub), so most people don't have an account with history either.

If possible what I've seen help very much is to have a second person join on as being the "ticket review guy." That person will act as a community manager and really won't do that much coding. Usually they'll have a technical background and will understand the code they're reading in pull requests, but for the most part they're there to allow the primary code writer to focus on writing big features and executing core vision while the community at large contributes fixes, tweaks, and features that hadn't been baked into the core vision