4 ms·

Welcome to open source maintainership

• greglindahl 9y ago
  If you have new folks who aren't fully socialized to the project yet, having multiple reviewers is much worse than having a couple of people specifically individually coaching new would-be committers. I use a coaching approach for new hires at my startups.
  • aurbano 9y ago
    Could you describe your coaching approach? That sounds interesting, and is often a difficult problem to solve
    • greglindahl 9y ago
      Well, the basic idea for coaching a brand-new employee is that you hired a perfectly smart person for the job, but your company has a strong coding culture with a particular style that the new engineer isn't familiar with. So it's a big part of on-boarding to not only teach this smart engineer the crazy weirdnesses of your system, but also teach them (what they will perceive as) the oddities of your corporate coding style. It can be good to do this outside of the public eye, so the initial cycle of "wtf, why is this considered standard" followed by "well, it's not so much that this is the best way, but it's more likely that we'll be able to understand each other's code if we all do it one way" can be done in private. Once the engineer is well-versed in the system, they are unleashed to quietly subvert it, if that is their will :-)
• koolba 9y ago
  Maintaining a popular open source project is a great way to learn to politely say “fuck you this is crap”. It’s important to be consistent with your online voice though. If you’re always blunt and terse then, generally, people won’t take it badly. But if you slide between extraneous gestures and out right profanity then eventually someone will take it personally.