Do This

• Act professionally
• Treat others as friends and family
• Seek first to understand
• Respect other's opinions though they may differ from your own
• Admit when you're wrong
• Be honest, transparent, and constructive
• Use clear, concise language

Don't Do This

• Assume you always know what is best
• Use indecent or degrading language of any kind
• Hold hostage another's work for any ulterior motive
• Engage in bullying behaviors, including but not limited to:
  • Belittling others' opinions
  • Persistent teasing or sarcasm
  • Insulting, threatening, or yelling at someone
  • Accusing someone of being incompetent
  • Setting someone up to fail
  • Humiliating someone
  • Isolating someone from others
  • Withholding information to gain an advantage
  • Falsely accusing someone of errors
  • Sabotaging someone's work

Creating successful projects in your community is all about trust, perception, and allies

Why? Because you must create a shared context from which all members in the community can draw. There will still be plenty of disagreements, but everyone will be moving in the same general direction; everyone will be playing for the same team.

Just because something is technically possible doesn't mean it is necessarily a good idea.

I think most people are good people, but easily mislead by a few seeking power and gain. Other leaders seek only to inspire the best in us.

What kind of leader are you? I know what kind I want to be.

Good people can make bad decisions (and often do) simply because of misinformation. This is the oldest, dirtiest trick in relationships, politics, and sales.

If people start saying things just to save face, that's a sure sign that something in your community has gone horribly wrong.

If you find yourself rationalizing draconian policies, chances are your community is suffering from a deep lack of trust. The antidote? Humility.

Discussing things "in the open" is important. But it does not necessarily engender trust in a community, especially in the absence of cognizant moderation.

Unfortunately, open discussions can sometimes lead to a culture of distrust. This happens when individuals in power publicly humiliate, intimidate, or even bully others in the community. Often this happens unconsciously or as a result of a poor choice of words. Regardless of whether the intent is actual or perceived, the damage to the community is the same, and must be quickly dealt with before it festers into a culture of enmity.

As a community grows, so does the likelihood of miscommunication and the abuse of public forums. Therefore, it is only prudent to put in place mechanisms for moderating open discussions, such that they remain positive and constructive.

Community members must hold themselves and others accountable to a high standard of conduct.

Artificially restricting choice is more often detrimental than productive.

I love being part of a team where every voice is heard and valued, whether it be the voice of an application developer, a technical writer, a sys admin, an intern, a senior contributor, a quality engineer, or any other member of the community.

Any creative endeavor of significance is the product of an extraordinary number of ideas; if you want to create world-class products, you have to become incredibly efficient at farming those ideas and crafting them together into something that delights your audience.

The trouble with being innovative is that people want a faster horse, not a Model T. You have to work hard to convince them otherwise.

Martin Fowler and James Lewis share their thoughts on strict standardization in the context of microservice architectures:

One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer. We prefer using the right to tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn't that common.

Paving over a protocol, library, or language leaves a nice, smooth surface in the beginning, but it doesn't take long for cracks to form.

When asking for feedback from the community, be specific. The broader your question, the more tangents it will spawn in the ensuing discussion, and the lower your signal-to-noise ratio will be.

So, instead of "here is this big huge spec, go read it and let me know what you think", take one small section of that spec at a time, and ask 2-3 pointed questions about it.

Not only will you be more likely to get high-quality feedback using this approach, but you will also hear from more voices, since many people do not have the time to dedicate to reading and digesting a large proposal.

When farming ideas, encouraging more people to speak up with honest, on-topic feedback is exactly what you want.

When people describe a piece of code as "ugly", "convoluted", or "over engineered", what they are actually saying is the code isn't a natural solution to the problem it is trying to solve. Natural solutions don't fight against the problem; they work with the problem. Natural solutions are simultaneously simple and effective, with no wasted motion. This is the definition of elegant code.

A wise farmer understands that they can't fight against nature; they may cultivate the richest soil, water regularly, and ensure plenty of sunshine. However, if they don't invest in quality seeds, they know they will still end up with a lousy crop.

Software teams often forget that they are made up of people, and that people cannot be defined by their titles. Removing the mental and organizational silos around titles--allowing each person on your team to flow into where their talents and personalities naturally take them--unleashes creativity and dramatically improves the quality of what you are building together.

If you are a community leader, you will subconsciously try to shape the project in your own image. Only by becoming self-aware and bridling this instinct can you hope to farm enough ideas to make your project not just good—but great.

Politics are inescapable and necessary aspects of any community, but leaders must be vigilant to avoid inversions of priority. You don't want to get into a situation where technical excellence and serving the needs of users takes a back seat to political maneuverings.

If you find yourself forced into compromising on the quality and usefulness of your product in order to score political bonus points, your community is in trouble. Healthy communities do not force their members into playing a game of thrones in order to get anything done.

Remember why you are building what you are building, and who you are building it for. Don't mistake the game for the product.

Great leaders excel at farming ideas. They check their ego at the door, welcoming new voices and opinions that differ from their own. They facilitate constructive conversations. Great leaders help their community refine and vet their ideas until the proper solution becomes painfully obvious.

Be careful that you don't let "nobody else does that" become a crutch in your community. When applied judiciously, the phrase can be helpful. However, it can also be abused to cover up a lack of trust and open-mindedness in your group.

Alex Gaynor:

Programming languages are for people. If all the people think the feature is nonsense, the feature is nonsense.

What if every time someone shared an idea, they could do so without fear of backlash and bullying? What if people could raise their concerns without being summarily dismissed? What if “seeking first to understand” were a core value in the culture of your community?

We need open minds to build open communities.

Frank Zappa:

Without deviation from the norm, progress is not possible.

Contribution drives direction. If you want to influence the direction of a project, roll up your sleeves and contribute in a meaningful way. The more ways you contribute, the better. Strive for a mixture of hard (e.g., code, prototypes) and soft (e.g., reviews, designs, ideas) contributions.

Over time, people will come to value your opinion as you demonstrate your passion and knowledge. You will become a thought leader according to your ability to demonstrate good judgment and consistently get things done.

Seth Godin:

Too often, in our world, someone does something, something extraordinary, and we don't say, "how'd you do that?"

A healthy community has a culture of open-mindedness, by which I mean individuals are in the habit of looking at a problem through multiple lenses. The way you do this is by inviting feedback and moderating constructive discussions.

The ideal process goes something like this:

1. A problem is discovered and roughly defined.
2. The problem is discussed from different viewpoints (seek first to understand).
3. Multiple solutions are brainstormed, with an emphasis on quantity, not quality (i.e., avoid criticism)
4. Each solution is evaluated from different viewpoints and according to a set of fitness criteria, and the pool of possibilities is winnowed accordingly.
5. Once rough consensus has been achieved among the discussion group, an executive decision is made and implementation begins.

This process isn't necessarily linear; for complex problems, it is often helpful to circle back several times, reevaluating assumptions as needed, in order to avoid arriving at a local (vs. global) optimum.

If you have a very small community and/or don't have the luxury of being able to participate in realtime discussions, you may have to trick your subconscious into keeping an open mind, and not prematurely narrowing the field of possible solutions. One way to do this is to write down a defense for why you prefer one option over another. This forces you to get outside your own head and broaden your perspective, even if you don't immediately have the opportunity to share your defense with anyone else.

Let's get creative.

Based on my own experience as a developer and manager, coding standards are not necessarily evil (but they can be if taken to extremes). In your career you spend a lot more time reading code than writing it; the primary role of coding standards is to reduce context switching for your brain when reading other people’s code.

The second role of a coding style is to avoid common programming mistakes that happen just because of the way our brains work. It isn’t that we are “dumb”, it’s just that we aren’t perfect.

And, finally, the third role of a coding style is to avoid wasting time on religious wars about silly things, like tabs vs. spaces, and where the curly bracket starts. As a team you agree on something that makes the most sense according to what tools and platforms all the devs are using (e.g., tabs are no big deal for Windows devs, but suck for Linux devs, so just use spaces and/or configure your SCM to do the translation for you).

If you see a problem, and no solution, then create one. Just don't be a hypocrite and not allow others the same privilege.

Use the best tool for the job. Ostensibly identical feature sets can yield vastly different results depending on your personal style and the unique constraints of a given project.

When governing an open foundation or a large company, you must learn to balance the rights and needs of the "federal government" with that of the individual "states". Too much power concentrated at the top, and you squash innovation and productivity. Too little, and your organization wallows without vision and direction.