larlet-fr-david-cache/cache/f86b54bf25411c04eb538befd6ebc856/index.md

title: The Minimally-nice Open Source Software Maintainer
url: https://brson.github.io/2017/04/05/minimally-nice-maintainer
hash_url: f86b54bf25411c04eb538befd6ebc856

<p>Being involved in open source software is rewarding, yeah? You start
off contributing to your favorite project, and it feels so
heartwarming when that project’s maintainers recognize your
effort. Then a few years later you somehow end up responsible for that
project, and maybe some satellite projects, and people are clamoring
for your attention, and your inbox is never empty, and it’s exhausting
and terrifying, and the skills necessary to cope with all the
personalities involved are entirely different from the skills you used
to get your foot in the door in the first place.</p>

<p>I love creating cool things, and releasing cool things, and receiving
praise for cool things. To create ever cooler things though one needs
to multiply their manpower, get help from others - to <em>collaborate</em>.
Ugh. For me communicating with others is frightening, stressful,
unpleasant, demoralizing, depressing. As the maintainer of a number of
projects related to the <a href="https://www.rust-lang.org">Rust programming language</a>, I want to see
my software grow and thrive, so must continually redouble my efforts
to productively engage with their users and contributors.</p>

<p>Any day where I am actively maintaining my software I might respond to
dozens of messages online. It’s so much effort. But amidst all that
work, it actually only takes a small amount of consistent effort to
nurture a cooperative environment, one that makes participants feel
appreciated, builds support from your userbase, encourages
contributions, and reinforces a positive culture. Still, even though
it’s quite simple to treat others right, it’s not simple to do it
consistently: it requires discipline to build good habits. For me it’s
a struggle.</p>

<p>Here I’m going to describe a few guidelines on how to respond to
people on bug reports, pull requests, and other forums. I don’t
consider myself to be good at this; I definitely don’t follow my own
advice consistently. But what I’ve scribbled down here reflects my
basic gameplan for dealing with people, and having a clear gameplan
makes it easier to rip through your responses to both the pleasant and
the horrifying, quickly and correctly. My understanding of this
subject is always evolving, but this is what’s near the top of my
mind as of mid-2017.</p>

<p>This simple advice might sound patronizing. And you might have
different opinions about what it means to be nice to people. That’s
fine. Perhaps consider whether you are following your own gameplan
consistently, and how you might improve it.</p>

<p>This is divided into two sections:</p>

<ul>
  <li><a href="#a-case-study">A case study</a>. My lamentations at being a heartless
jerkwad.</li>
  <li><a href="#the-techniques">The techniques</a>. Common techniques for dealing
with people, as applied to open source software.</li>
</ul>

<p>If you just want a TL;DR for seven techniques of the minimally-nice
open source software maintainer, then <a href="#summary">jump straight to the
summary</a>.</p>

<p><a name="a-case-study"/></p>
<h1 id="a-case-study">A case study</h1>

<p>The impetus for writing this was <a href="https://github.com/rust-lang/rfcs/pull/1644#issuecomment-224752975">a comment I made</a> on a recent
Rust RFC. As usual, this was one of many threads I responded to that
day. And as happens with some alarming frequency, I spent a large
portion of the night regretting some of the things I said, and
thinking about what I should have said differently. I’ll reproduce it
here so you don’t need to click the link:</p>

<blockquote>
  <p>I like the direction of this RFC generally.</p>
</blockquote>

<blockquote>
  <p><code class="highlighter-rouge">--explain</code> is a stable compiler interface. How can we change it? I
  agree that <code class="highlighter-rouge">--explain</code> is a sweet name for this functionality, but I
  think we need to use a different one.</p>
</blockquote>

<blockquote>
  <p>It’s not clear to me what the fate of error codes is here. My
  impression is that you are proposing to remove them, but your images
  contain the current –explain E0002. Can you make this more clear,
  and if you are removing error codes can you remove them from the
  graphics?</p>
</blockquote>

<blockquote>
  <blockquote>
    <p>“Famous programmers like John Carmack have praised the Elm error
    format.”</p>
  </blockquote>
</blockquote>

<blockquote>
  <p>John Carmack’s fame doesn’t really have any bearing on the validity
  of the proposal.</p>
</blockquote>

<blockquote>
  <p><em>Also, I don’t think RFCs should be giving props to other
  contributors in the summary. When creating the RFC process we made
  an explicit decision not to include author information, to avoid
  making RFC authorship itself an incentive (I think). If authorship
  is something that should be included in RFCs then the process itself
  should be modified to include that metadata, including crediting the
  actual author, not just their collaborators. If giving credit in the
  RFC text is something we want to encourage, then I don’t know that
  the summary is the place for it. The summary is for summarizing the
  content of the RFC.</em></p>
</blockquote>

<p>I’ve emphasized the part that haunted me most.</p>

<p>I wrote this at the end of the day, in a hurry, between meetings. This
was a proposal that I had opinions about, and I wanted to make sure
they were heard. But it has to be done in the right way.</p>

<p>Really, this comment wasn’t horrible. You’ve seen much worse I
hope. But it bothered me. A lot. I didn’t follow my gameplan. I knew I
had made a mistake when the author of the RFC messaged me privately,
saying, more-or-less:</p>

<blockquote>
  <p>jonathandturner: :( why don’t you want to credit people for their
  work?</p>
</blockquote>

<p>My comment on the thread sounded like I wanted to deny the
contributors credit for the RFC. Is that really what I wanted? Well,
honestly I am an overflowing flagon of resentment and spite, so
perhaps this comment in the moment was a true reflection of my
blackened heart, but after some back and forth with @jonathandturner,
and some further reflection, I understood this was a dumb position to
hold - being extremely generous with credit is one of the easiest and
most powerful techniques for building community. Outright suggesting
we deny credit looks petty and hostile.</p>

<p>Let me go through my comment line by line and excoriate it.</p>

<blockquote>
  <p>I like the direction of this RFC generally.</p>
</blockquote>

<p>I’m relieved that I started the comment this way, considering how
negative the comment ended. This isn’t a fantastic opener, but at
least it’s positive. Showing others appreciation is one of the simplest
techniques for dealing with people. What I wrote here is just about
the minimum appreciation I can express. It’s saying I like what they
are thinking. It’s obviously setting the stage for less positive
feedback later, but we don’t need to worry too much about that - even
the slightest effort at showing appreciation tends to help soften
interactions, though there is a risk of being seen as patronizing,
particularly if all your praise is as curt as this.</p>

<p>So this could have been better in an obvious way, just by expanding on
what I liked about it. There were a lot of great facets to this RFC:
the beauty and clarity of the proposed error messages; showing images
of the proposed errors, etc. It’s a good RFC - I could dig out lots of
little things to say positively about it. But doing so takes time and
effort. I was in a hurry here to say the things I wanted to say, and
didn’t take the time, but perhaps I should have. The more negative
your main points are, the more worthwhile it is to soften them with
positivity. And it’s prudent to show that positivity sometimes to
avoid being a complete jerk.</p>

<p>Another simple thing I could have done is thanked him for his
work. When you work hard on something and then finally unveil it, it’s
super satisfying when somebody thanks you, recognizing that work. We
all long to feel appreciated. I might instead have opened with</p>

<blockquote>
  <p>Thanks @jonathandturner! I’m glad to see some movement in this
  area. This is a super important proposal, the design looks well
  thought out, and I love how well composed it is. It’s obvious you’ve
  put a lot of effort into it.</p>
</blockquote>

<blockquote>
  <p>I like the direction of this RFC generally. The error messages are a
  huge improvement over what we have today. The way you are using
  colors to emphasize the different focal points of the errors makes
  things a lot more readable. And good idea including the images of
  your proposed messages in the RFC - that makes it simple to
  evaluate.</p>
</blockquote>

<p>OK, that’s really loading up the praise. And it’s all true. The above
took me a few minutes to come up with, which is a fair bit of work
just to grease the wheels. One might do more or less depending on the
situation. Now that we’ve pumped him up we’re ready to crush his hopes -
er, offer gentle, constructive criticism.</p>

<p>So back in reality, I didn’t actually write all that - I wrote the
impulsive thing, then tossed and turned all night regretting it. To
make up for it the next day I posted <a href="https://github.com/rust-lang/rfcs/pull/1644#issuecomment-224968147">this followup</a>, reproduced
here:</p>

<blockquote>
  <p>@jonathandturner my comments could have been more constructive. Let
  me respond to myself.</p>
</blockquote>

<blockquote>
  <blockquote>
    <blockquote>
      <p>“Famous programmers like John Carmack have praised the Elm error
      format.”</p>
    </blockquote>
  </blockquote>
</blockquote>

<blockquote>
  <blockquote>
    <p>John Carmack’s fame doesn’t really have any bearing on the
    validity of the proposal.</p>
  </blockquote>
</blockquote>

<blockquote>
  <p>Maybe just change ‘fame’ to something more relevant, like
  ‘well-respected’, something that better indicates why his opinion is
  important.</p>
</blockquote>

<blockquote>
  <blockquote>
    <p>Also, I don’t think RFCs should be giving props to other
    contributors in the summary. When creating the RFC process we made
    an explicit decision not to include author information, to avoid
    making RFC authorship itself an incentive (I think). If authorship
    is something that should be included in RFCs then the process
    itself should be modified to include that metadata, including
    crediting the actual author, not just their collaborators. If
    giving credit in the RFC text is something we want to encourage,
    then I don’t know that the summary is the place for it. The
    summary is for summarizing the content of the RFC.</p>
  </blockquote>
</blockquote>

<blockquote>
  <p>I phrased this too strongly. I just had a sudden observation that
  we’ve developed ad-hoc ways to credit people that doesn’t fit into
  the process as implemented. I should have phrased this more like
  ‘maybe we should reconsider how to give credit in RFCs’. RFC process
  is organic so it may be perfectly fine to do it like this (author
  credit in the commit log, additional credits in the summary), but it
  is awkward. And I do believe we made an intentional decision not to
  credit people, and if that is changing it is important to
  acknowledge it.</p>
</blockquote>

<p>That was … ok, I’m still not particularly happy with it. It still
appears a bit defensive of my dumb position. I wish I could do it
again. I’ll never be happy. I’ll never, ever be happy.</p>

<p>But the point is that it’s best to admit your mistakes, to yourself
and others: Dale Carnegie recommends that “if you’re wrong, admit it
quickly and emphatically”. People love to be right, so if you can
admit that you are wrong and they are right, that can inspire great
cooperation. And it usually doesn’t require any sacrifice at all to
admit you are wrong besides getting over your own pride.</p>

<p><a name="the-techniques"/></p>
<h1 id="the-techniques">The techniques</h1>

<p>So this relatively minor episode caused me to reevaluate how I
communicate online. It’s not like I don’t know how to be nice. I
believe that I do, but sometimes I forget momentarily. So here, to
reinforce my own good behavior, and hopefully for your benefit, I’ve
traced through my basic gameplan for responding to people online.
When I stick to this plan things mostly go well, the people I
encounter feel good about Rust and their association with it, and I
feel relatively ok-ish about myself.</p>

<p>The techniques here apply to any open source venues, like pull
requests, issue trackers, mailing lists and forums.</p>

<p><a name="respond-quickly"/></p>
<h2 id="respond-quickly">Respond quickly</h2>

<p>Immediately after users and contributors reach out to you is when they
are most motivated to help you. Simply getting a quick response can
make a frustrated user’s day. As a maintainer I’ve frequently seen
expectant users express their appreciation: ‘thanks for the quick
response!’. We know that other people’s time is valuable because our
own time is valuable. By responding to an inquiry quickly we
demonstrate that we respect the time they put into e.g. filing a bug
report, and that we are sacrificing our time to help them. Even if I
can’t think about a particular issue right now, and particularly if I
<em>know</em> I’m not going to get to it any time soon, I will sometimes post
a quick acknowledgement and validation of their concerns, like “thanks
for the report. This does look troubling. I’m afraid I won’t be able
to look into this soon, but help is appreciated”, etc.</p>

<p>The longer you wait to respond to a contributor the less likely they
are to stay engaged: only the most hearty contributors will return to
the table after being ignored for a year. Sadly, it’s all too common
that I come across an issue where the most recent comment is from
someone seeking advice, long, long ago. Those contributors are lost
forever, and their potential contributions with them.</p>

<p>For me this is one of the hardest habits to maintain. The neverending
crush of issues and threads in Rust is entirely overwhelming. I’d much
rather I didn’t have to face other people’s problems constantly - I
have so many of my own. It’s impossible to follow everything going on
in Rust, so in practice I tend to restrict the threads I follow to
specific areas, and to those people who are pinging me directly. There
are long stretches where I just can’t face the endless tide of other
people needing assistance, where I will just willfully ignore my
inbox. I don’t recommend that. Better to be responsive.</p>

<p>How quick is quick enough? 3 days. How scientific is this number? It’s
not. You should respond as quick as you can, but reasonable people
will give you a weekend without getting bent about it.</p>

<p><a name="give-thanks"/></p>
<h2 id="give-thanks">Give thanks</h2>

<p>People like to feel appreciated. It’s a universal desire. And
appreciation is something it costs us little to give, to spread about
like parade candy. If you put just a moment’s thought to it, I know
you can see something good in every person and every situation.</p>

<p>The mere act of submitting a patch is awe-inspiring: another person
cares enough about our project that they took the time to understand
how it works, fix our problem, package it up, and submit their work
for public criticism. That’s amazing. Do you remember the first patch
you ever submitted upstream? I bet you were apprehensive. It’s a
crucial moment that can determine the future relationship between the
contributor and the project.</p>

<p>So the first thing to do before mounting a response is to dig deep
into your reserves of universal love, kindness, and compassion, and
seek something to be thankful for. The more specific you can be the
more it shows you care. Did they provide a reproducible test case in
the issue report? Damn, that took some effort! Did they write tests
for their patch?  Noway! Usually I have to ask for those! If you keep
thinking about it you’ll discover there’s a great deal to say thanks
for: “Thanks @AHumanWithFeelings! I’ve been wanting to fix this
issue for so long. I’m glad somebody finally stepped up to write a
patch. This looks lovely!”</p>

<p>Of course, not every encounter demands laying it on thick, but do say
“thanks”. Even trivial patches that can merge without any feedback
deserve some comment: just hit the merge button and write, “thanks!”,
and they’ll feel good about the small part they played in your
project’s ongoing success.</p>

<p><a name="pay-a-compliment"/></p>
<h2 id="pay-a-compliment">Pay a compliment</h2>

<p>One of the primary duties of a software maintainer is to review
others’ work. Every day, burning down the endless patch queue. And the
bigger the project the more gruelling the work. Review is where
everything comes together; it is the make-or-break point for
contributors, their work, and their motivation to keep coming back.</p>

<p>Under the exhausting crush of review responsibilities it’s easy to get
tunnel vision; to bee-line for the shortest route to the end, zeroing
in on the problems to be fixed, and moving on to the next patch.</p>

<p>When you do this though you risk discouraging your contributor. The
more work a patch needs the more the critiques pile up, and it can
easily, and unintentionally, result in an avalanche of
negativity. This is particularly likely to affect new contributors,
who are least likely to understand project norms, and most likely to
need guidance.</p>

<p>A well-known technique to soften the weight of criticism is to pair it
with praise. You’ve probably heard of the “compliment sandwich”:
surrounding the criticism - the meat of your response - with a soft
and squishy bun of praise. The compliment sandwich is considered so
delectable because it is simple and effective. Before you launch into
<em>what you really want to say</em>, try to look for something positive to
point out first.</p>

<p>When I review a patch I usually do it in two passes: first I skim
through it with an open mind, with no preconceptions of what I expect
to see. I’m trying to get in their head and see the solution from
their point of view; and in particular trying to find things to like
about their solution. Does the patch display good intuition even while
getting the details wrong? That’s a good starting point. Did they do
something clever that you hadn’t considered? Does their work
demonstrate they’ve read the project’s contribution guidelines in a
way most contributors don’t? You probably have a host of things you
look for to indicate quality, as specific to your project. Make note
of them as you read the patch, <em>and say them first thing in your
response</em>. Myself, I always appreciate when a contributor writes <em>any
tests at all</em>, and I adore contributors who write excellent tests. And
I say so. To take this technique to the next level, be on the lookout
for indicators of the contributor’s own values, and compliment them on
things they are likely to take special pride in.</p>

<p>By reading the whole text once I additionally reduce the chance of
coming to mistaken conclusions, or leaving comments based on
incomplete information. Often I’ve not considered a work as a whole
and left a comment, then moments later realized that comment was
mistaken and had to correct myself. Likewise, I find it frustrating
when reading inline comments about my own work based on incorrect
assumptions, and which I felt I had made clear if the respondent had
only read further.</p>

<p>So after I’ve done the first pass in a spirit of expansive generosity,
and begun composing my review with praise, then I go back for the
second pass and do the detailed review. Even here though I try to note
positive things as well as things that need to be changed, etc.</p>

<p>I’ve focused on reviews here, but the same applies to all
correspondence. Bug report includes a reduced test case?
Awesome. Forum post is well thought out and polite? Halleluja. Always
be looking out for nice things to say about your peers and their work.</p>

<p><a name="say-yes"/></p>
<h2 id="say-yes">Say “yes”</h2>

<p>In the midst of an internet argument it’s easy to lose sight of the
humanity of the individual on the other side of the computer
monitor. Your pulse quickens, your temperature rises, mind races. You
know you are right, technically, morally. Whatever, you are right;
they are wrong. Wrong, wrong, wrong, and you are going to prove it
right now.</p>

<p>But before you fly off the chain, prove your undeniable superiority,
and prove that <em>they are wrong</em>, let me suggest instead that you do
something better, that you do the opposite: that you <em>prove they are
right</em>.</p>

<p>Imagine the most exciting brainstorming session you ever had: you spit
out a brilliant idea - your partner loves it! They respond
enthusiastically by building on your idea. The conversation spirals
ever upward in joyous rapture. It’s an amazing feeling, being on the
same wavelength. By the end up the night you feel thrilled and
intoxicated. That’s the power of positivity.</p>

<p>It’s so rare. When it happens we want to capture that moment and save
its precious essence forever. That’s the kind of magic you want your
contributors to feel every time they file an issue.</p>

<p>The opposite though is far more common, and it’s the death of useful
discourse: “you’re wrong”, “that’s a bad idea”, “I call bs”, “meh”,
“false”, etc. They all amount to a big fat “no”, and they all make the
recipient feel disrespected and generate ill will. Bad vibes. This is
the worst way to open a productive conversation, and people do it all
the time. It’s shocking how tactless smart people can be. Such direct
negativity erects a brick wall fortified with turrets and kettles of
boiling oil in the middle of a conversation.</p>

<p>“No” is a cardinal sin of persuasive argumentation. Don’t do
it. Don’t do it. Don’t do it. No, no, no!</p>

<p>Instead, say “yes” as fast as you can, and in every way you
can. Literally just say “yes” first thing, then figure out what useful
affirmation you can follow with to support that “yes”. If “yes” is too
on-the-nose for your taste then there are a billion ways to
paraphrase. “Yeah” is a great casual option, and my favorite. Follow
that with a comma, “yeah, it’s true that …”, but there are so many
other more subtle ways to drop a huge positivity bomb at the outset of
your response: “totally”, “you’re right about …”, “indeed!”. If you
put your mind to it you can spend a whole paragraph just saying “yes”.</p>

<p>In the end, even if the solution is much different than their original
proposal, by chaining your good ideas to their good ideas, they will
feel successful. Per master thinker Blaise Pascal, “people are
generally better persuaded by the reasons which they have themselves
discovered than by those which have come into the mind of others.”</p>

<p>Affirmation: it’s the secret weapon against belligerent jerkwads.</p>

<p><a name="be-clear-about-what-you-expect"/></p>
<h2 id="be-clear-about-what-you-expect">Be clear about what you expect</h2>

<p>For contributors to stay engaged they need to know what’s next, what
is expected of them. This applies to every level of the project, from
bug reports to pull requests. If you want something, say so directly!
And if you don’t want something, suggest concrete and viable
alternatives. For the most part, if you are in a position of
authority, contributors are <em>desperate</em> for you to give them
direction. Leaving your desires ambiguous is one of the easiest ways
to destroy contributors’ motivation and lose their manpower.</p>

<p>This applies especially in two places: on the bug tracker, and during
reviews. In both cases there is frequently a critical moment when you
have the opportunity to provide clear direction, and though it
requires some effort, failing to do so leaves a vacuum, and thus
leaves potential precious manpower on the table.</p>

<p>Your issue tracker, if it’s like Rust’s, is filled with bugs and
feature requests that you would love to fulfill; but you will never,
ever get to them yourself, not even if you live forever. These
bugs frequently persist in a state of unknowing, where the solution
is unclear, for weeks, months, years, accumulating debate and
discussion about how to move forward. But eventually something clicks
into place, and an acceptable solution becomes known to you. For
simple bugs this moment can be immediately when it is filed; for more
nuanced bugs it can take a long time. But when it happens, you have
the opportunity to clear the way for contributors.</p>

<p>On any bug where there is an acceptable solution, make it crystal
clear what that solution is, and that <em>help is wanted</em>. Contributors
are sometimes just waiting for a signal indicating how they can
help. The more detail you can provide the better. Bugs with clear
direction have 100% better chance of drawing contributions than those
without. The larger your project, and the larger your contributor
base, the more important it is that you consistently provide
direction, and that contributors have a way to find the bugs that have
reached this inflection point.</p>

<p><a name="admit-your-mistakes"/></p>
<h2 id="admit-your-mistakes">Admit your mistakes</h2>

<p>Like variable bindings in a great many programming languages, our
reality is supremely mutable. Conditions change, facts change, and so
does our perception and understanding. Being wedded to past
understanding and past resolutions is dogma. On the other hand,
confronting change honestly and efficiently is a common trait of
successful individuals and organizations. The agility to let old
opinions go and steer a new course helps organizations stay relevant
in the face of shifting fortunes, and helps us navigate difficult
social situations in our daily lives.</p>

<p>Differences of opinion are the root of many arguments. People make up
their minds, assert themselves, refuse to listen to counterpoints,
become angry, develop personal animosity toward those that don’t
agree, and the conversation either reaches an ugly standstill, or
devolves into a passionate feud. It’s a common failure mode, and we
want to prevent it from happening as early as we can.</p>

<p>Just like we want to say “yes”, and acknowledge others’ great ideas,
it’s beneficial to look for situations where we can let go of our own
ideas, our own dogma. It’s a hard thing to do: it’s so tempting to
stick to what is comfortable; to force those difficult decisions that
have already been decided to stay in the past; to never let go of our
pride and admit we were wrong, or made mistakes.</p>

<p>But it gets easier with practice, and you might even come to find that
admitting your mistakes brings relief - it feels liberating to let
things go, to get that weight off your mind.</p>

<p>I find that there are very few designs and opinions that, when I look
closely, I am deeply wedded to, and most often when somebody is angry
at something I have done or some decision I have made, it is trivially
true that I’ve made a mistake. Sometimes these are technical mistakes,
and I can let them go by saying “yes, I see what you mean now. That
was the wrong call. Are you interested in submitting a patch to fix
it?”. Sometimes it’s more of a social or political mistake, that I
haven’t expressed my motivations or intentions clearly and the other
person is surprised and disappointed that some outcome is not what
they expected. In these situations I try to acknowledge that the
result has the downsides they’ve identified, and apologize that it
doesn’t suit them, and move on. Note though that it’s best to avoid
the sorts of backhanded non-apologies we often see from politicians
(e.g. “I’m sorry you are angry”). Everybody sees through bullshit, and
it’s more useful to focus on your own thoughts and feelings instead of
mindreading others’.</p>

<p><a name="be-effusive"/></p>
<h2 id="be-effusive">Be effusive</h2>

<p>This is another trick that is super-effective! A unique technique of
the internet age, I’ve only begun to acknowledge its power recently.</p>

<p>Don’t hesitate to go overboard with superlatives and punctuation:
exclamation marks where they shouldn’t be, over-the-top adjectives,
cute emoticon and emoji. I know that it took me a long time to come
around to this point of view. It’s just bad writing to throw in
exclamation marks and superfluous words, right? And emoji aren’t even
words…</p>

<p>“Oh, wow, thank you so much! 💖”</p>

<p>Truth is that on the internet this is not bad writing, at least for
one-on-one communication. It is effective writing. It’s well
understood that conveying tone on the internet is <em>hard</em>:</p>

<p>“Thanks.”</p>

<p>What does that period mean? It looks so gruff. Are they pissed at me?!
Are they having a bad day? On the internet the simple period can
appear sarcastic, or angry. It’s so neutral that people will project
whatever emotions they want on it. One must go out of their way to not
only get their meaning across but also the tone - and for our purposes
the tone we want is almost always one of abundant positivity and
enthusiasm.</p>

<p>To help you kickstart this habit, here’s a list of some of my
favorite superlatives, emoticon, and emoji, when applied to
technical communication in open source software communities:</p>

<ul>
  <li>”!” (exclamation mark)</li>
  <li>“super-“</li>
  <li>“totally”</li>
  <li>“amazing”</li>
  <li>“awesome”</li>
  <li>“really”</li>
  <li>&lt;3 (heart)</li>
  <li>&lt;3 &lt;3 &lt;3 (triple-heart!)</li>
  <li>:-D (big-ol’ grin)</li>
  <li>😁 (grinning face with smiling eyes)</li>
  <li>😍 (smiling face with heart-shaped eyes)</li>
  <li>💖 (sparkling heart)</li>
</ul>

<p>These are just the ones in my own toolbag. There are so many others,
and there’s lots of room for creative expression here. The younger you
are the more of these weapons you probably have in your arsenal, what
with all the texting and instagramming and tweeting. Deploy them
without hesitation.</p>

<p>There are limits to good taste here, but you probably have to decide
them for yourself. Personally, I never use more than one exclamation
point; two exclamation points is the epitome of tackiness 😜. And as a
child of the 90’s I’m consistently tempted to sneak in a few
“radical”s and “bodacious”es, to embody my life-long wish to become a
Ninja Turtle, but sadly those adjectives seem to be out of style for
the present moment. The time will come though.</p>

<p>Just as a big smile can brighten someone’s day in the physical world,
a little bit of 😍 goes a long way in the virtual world.</p>

<p><a name="summary"/></p>
<h1 id="summary">Summary</h1>

<p>So that’s all you need to make everybody happy, and make everybody
love you! Now you know the secret and you will never fail again.</p>

<p>Ha, ha, no. No, not really. Not everything goes smoothly just by being
nice. Some people are deeply broken. So many messed up people (maybe
I’m one of them - maybe you are too). Typical social wheel-greasing
doesn’t always work with them; they are hell-bent on sowing chaos,
even if they don’t know it. The guidelines here are still applicable
to these cases, because at least other, more reasonable, people will
see that you are doing your best, but truly dealing with them
effectively is a complex and uncertain matter. For another day.</p>

<p>Some of what I’ve said here may have sounded sarcastic, I know. That’s
me. I’m a deeply cynical individual, but I’m working on it. Effective
communication though needs to be genuine, empathetic, and respectful.
Everybody sees right through bullshit. Work on your empathy, work on
being genuinely nice, but until then, fake it ‘till you make it. If I
practice good communication habits consistently, presumably at some
point I will become a good person. That’s how it works, right? I so
want to be a good person.</p>

<p>In summary, do these things if you want to <em>appear to be</em> nice, and
also if you want to <em>actually be</em> an effective open source software
maintainer:</p>

<ul>
  <li><a href="#respond-quickly">Respond quickly</a></li>
  <li><a href="#give-thanks">Give thanks</a></li>
  <li><a href="#pay-a-compliment">Pay a compliment</a></li>
  <li><a href="#say-yes">Say “yes”</a></li>
  <li><a href="#be-clear-about-what-you-expect">Be clear about what you expect</a></li>
  <li><a href="#admit-your-mistakes">Admit your mistakes</a></li>
  <li><a href="#be-effusive">Be effusive</a></li>
</ul>

<p>By consistently exhibiting a few simple behaviors, one can at least
look like a kind and decent person. Maybe someday we all actually will
be.</p>

<p><em>With respects to Dale Carnegie’s <a href="https://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People">How to Win Friends and Influence
People</a>. Read that.</em></p>