Paul W. Frields

Hi Bryan. Like you I was overwhelmed at my first open source conference, which was probably around 2005. After going to many of these, I would recommend trying to reserve 25-50% of your session attendance for topics that are really new to you. In other words, try some topics outside your comfort zone. For instance, I'm sitting in Jason Hibbets' presentation on the making of an open source city, and saw some ideas that really resonated with me, such as the story of <a href="http://walkyourcity.org/">Walk [Your City]</a>. You might be surprised at the interesting lessons you can bring back to the areas where you spend more time in open source. You may not necessarily get a "wow" moment out of every session you attend, but at the very least you'll have an even more well-rounded appreciation for how people are applying open source in disparate areas of technology and life.

I've seen bad actors called many things, by myself, and more importantly others -- negative, poisonous, haters, and some <a href="http://www.slideshare.net/dberkholz/assholes-are-killing-your-project">unprintable terms too</a> (quasi-NSFW for terminology only, no ugly images). Regardless of what you call them, community leaders need to be attentive to the tone of communication that each new contributor brings to the team to avoid accumulating or encouraging bad actors.

In my experience, new contributors whose attitude toward teammates is positive, humble, and willing to learn and teach tend to blossom into great contributors, and often leaders in their own right. Those who come off as brash, argumentative, and demanding tend not only to stay that way (or become more so) but also drive away other contributors who can't stomach that type of culture. While ambition and initiative are still important virtues for an open source team to thrive, these must be tempered with the ability to encourage and cultivate the best in others. (This shouldn't be surprising since these are also leadership skills, and in an ideal open source team every contributor has the ability to lead toward the shared goal.)

I've seen the big part of the battle often won simply by being attentive to new contributors. A bit of one-on-one mentorship, if possible, can set a new team member on a path to success, giving them a smooth orientation to the team and its culture. If the team's already afflicted by bad actors, though, this process can be difficult, especially if through neglect the bad actors have become part of the teaching process. New contributors then have a much higher chance of either turning away (from a reasonable, negative reaction to the bad actor), or taking on the same negativity because they believe it's acceptable, or even the norm.

How do you share enforcement of that culture? If everyone on the team has an equal understanding of the norms, it's simple to have consensus when a bad actor needs to be approached -- quietly and privately at first, to give them the chance to improve, escalating only if needed. If the team is not tightly bound in that way, a written conduct code might be necessary. We see these in many open source teams and projects, and they can be simple ("Don't be a jerk") or can rely on a sizable document that details what's acceptable and what's verboten. In either case, though, the goal is to treat each other well as a ground rule while pursuing the team's objectives.

Or in short: It's important not to confuse a culture that's capable of accepting anyone with a culture that's willing to accept anything.