A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.md 33KB

4 yıl önce
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667
  1. title: The Minimally-nice Open Source Software Maintainer
  2. url: https://brson.github.io/2017/04/05/minimally-nice-maintainer
  3. hash_url: f86b54bf25411c04eb538befd6ebc856
  4. <p>Being involved in open source software is rewarding, yeah? You start
  5. off contributing to your favorite project, and it feels so
  6. heartwarming when that project’s maintainers recognize your
  7. effort. Then a few years later you somehow end up responsible for that
  8. project, and maybe some satellite projects, and people are clamoring
  9. for your attention, and your inbox is never empty, and it’s exhausting
  10. and terrifying, and the skills necessary to cope with all the
  11. personalities involved are entirely different from the skills you used
  12. to get your foot in the door in the first place.</p>
  13. <p>I love creating cool things, and releasing cool things, and receiving
  14. praise for cool things. To create ever cooler things though one needs
  15. to multiply their manpower, get help from others - to <em>collaborate</em>.
  16. Ugh. For me communicating with others is frightening, stressful,
  17. unpleasant, demoralizing, depressing. As the maintainer of a number of
  18. projects related to the <a href="https://www.rust-lang.org">Rust programming language</a>, I want to see
  19. my software grow and thrive, so must continually redouble my efforts
  20. to productively engage with their users and contributors.</p>
  21. <p>Any day where I am actively maintaining my software I might respond to
  22. dozens of messages online. It’s so much effort. But amidst all that
  23. work, it actually only takes a small amount of consistent effort to
  24. nurture a cooperative environment, one that makes participants feel
  25. appreciated, builds support from your userbase, encourages
  26. contributions, and reinforces a positive culture. Still, even though
  27. it’s quite simple to treat others right, it’s not simple to do it
  28. consistently: it requires discipline to build good habits. For me it’s
  29. a struggle.</p>
  30. <p>Here I’m going to describe a few guidelines on how to respond to
  31. people on bug reports, pull requests, and other forums. I don’t
  32. consider myself to be good at this; I definitely don’t follow my own
  33. advice consistently. But what I’ve scribbled down here reflects my
  34. basic gameplan for dealing with people, and having a clear gameplan
  35. makes it easier to rip through your responses to both the pleasant and
  36. the horrifying, quickly and correctly. My understanding of this
  37. subject is always evolving, but this is what’s near the top of my
  38. mind as of mid-2017.</p>
  39. <p>This simple advice might sound patronizing. And you might have
  40. different opinions about what it means to be nice to people. That’s
  41. fine. Perhaps consider whether you are following your own gameplan
  42. consistently, and how you might improve it.</p>
  43. <p>This is divided into two sections:</p>
  44. <ul>
  45. <li><a href="#a-case-study">A case study</a>. My lamentations at being a heartless
  46. jerkwad.</li>
  47. <li><a href="#the-techniques">The techniques</a>. Common techniques for dealing
  48. with people, as applied to open source software.</li>
  49. </ul>
  50. <p>If you just want a TL;DR for seven techniques of the minimally-nice
  51. open source software maintainer, then <a href="#summary">jump straight to the
  52. summary</a>.</p>
  53. <p><a name="a-case-study"/></p>
  54. <h1 id="a-case-study">A case study</h1>
  55. <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
  56. Rust RFC. As usual, this was one of many threads I responded to that
  57. day. And as happens with some alarming frequency, I spent a large
  58. portion of the night regretting some of the things I said, and
  59. thinking about what I should have said differently. I’ll reproduce it
  60. here so you don’t need to click the link:</p>
  61. <blockquote>
  62. <p>I like the direction of this RFC generally.</p>
  63. </blockquote>
  64. <blockquote>
  65. <p><code class="highlighter-rouge">--explain</code> is a stable compiler interface. How can we change it? I
  66. agree that <code class="highlighter-rouge">--explain</code> is a sweet name for this functionality, but I
  67. think we need to use a different one.</p>
  68. </blockquote>
  69. <blockquote>
  70. <p>It’s not clear to me what the fate of error codes is here. My
  71. impression is that you are proposing to remove them, but your images
  72. contain the current –explain E0002. Can you make this more clear,
  73. and if you are removing error codes can you remove them from the
  74. graphics?</p>
  75. </blockquote>
  76. <blockquote>
  77. <blockquote>
  78. <p>“Famous programmers like John Carmack have praised the Elm error
  79. format.”</p>
  80. </blockquote>
  81. </blockquote>
  82. <blockquote>
  83. <p>John Carmack’s fame doesn’t really have any bearing on the validity
  84. of the proposal.</p>
  85. </blockquote>
  86. <blockquote>
  87. <p><em>Also, I don’t think RFCs should be giving props to other
  88. contributors in the summary. When creating the RFC process we made
  89. an explicit decision not to include author information, to avoid
  90. making RFC authorship itself an incentive (I think). If authorship
  91. is something that should be included in RFCs then the process itself
  92. should be modified to include that metadata, including crediting the
  93. actual author, not just their collaborators. If giving credit in the
  94. RFC text is something we want to encourage, then I don’t know that
  95. the summary is the place for it. The summary is for summarizing the
  96. content of the RFC.</em></p>
  97. </blockquote>
  98. <p>I’ve emphasized the part that haunted me most.</p>
  99. <p>I wrote this at the end of the day, in a hurry, between meetings. This
  100. was a proposal that I had opinions about, and I wanted to make sure
  101. they were heard. But it has to be done in the right way.</p>
  102. <p>Really, this comment wasn’t horrible. You’ve seen much worse I
  103. hope. But it bothered me. A lot. I didn’t follow my gameplan. I knew I
  104. had made a mistake when the author of the RFC messaged me privately,
  105. saying, more-or-less:</p>
  106. <blockquote>
  107. <p>jonathandturner: :( why don’t you want to credit people for their
  108. work?</p>
  109. </blockquote>
  110. <p>My comment on the thread sounded like I wanted to deny the
  111. contributors credit for the RFC. Is that really what I wanted? Well,
  112. honestly I am an overflowing flagon of resentment and spite, so
  113. perhaps this comment in the moment was a true reflection of my
  114. blackened heart, but after some back and forth with @jonathandturner,
  115. and some further reflection, I understood this was a dumb position to
  116. hold - being extremely generous with credit is one of the easiest and
  117. most powerful techniques for building community. Outright suggesting
  118. we deny credit looks petty and hostile.</p>
  119. <p>Let me go through my comment line by line and excoriate it.</p>
  120. <blockquote>
  121. <p>I like the direction of this RFC generally.</p>
  122. </blockquote>
  123. <p>I’m relieved that I started the comment this way, considering how
  124. negative the comment ended. This isn’t a fantastic opener, but at
  125. least it’s positive. Showing others appreciation is one of the simplest
  126. techniques for dealing with people. What I wrote here is just about
  127. the minimum appreciation I can express. It’s saying I like what they
  128. are thinking. It’s obviously setting the stage for less positive
  129. feedback later, but we don’t need to worry too much about that - even
  130. the slightest effort at showing appreciation tends to help soften
  131. interactions, though there is a risk of being seen as patronizing,
  132. particularly if all your praise is as curt as this.</p>
  133. <p>So this could have been better in an obvious way, just by expanding on
  134. what I liked about it. There were a lot of great facets to this RFC:
  135. the beauty and clarity of the proposed error messages; showing images
  136. of the proposed errors, etc. It’s a good RFC - I could dig out lots of
  137. little things to say positively about it. But doing so takes time and
  138. effort. I was in a hurry here to say the things I wanted to say, and
  139. didn’t take the time, but perhaps I should have. The more negative
  140. your main points are, the more worthwhile it is to soften them with
  141. positivity. And it’s prudent to show that positivity sometimes to
  142. avoid being a complete jerk.</p>
  143. <p>Another simple thing I could have done is thanked him for his
  144. work. When you work hard on something and then finally unveil it, it’s
  145. super satisfying when somebody thanks you, recognizing that work. We
  146. all long to feel appreciated. I might instead have opened with</p>
  147. <blockquote>
  148. <p>Thanks @jonathandturner! I’m glad to see some movement in this
  149. area. This is a super important proposal, the design looks well
  150. thought out, and I love how well composed it is. It’s obvious you’ve
  151. put a lot of effort into it.</p>
  152. </blockquote>
  153. <blockquote>
  154. <p>I like the direction of this RFC generally. The error messages are a
  155. huge improvement over what we have today. The way you are using
  156. colors to emphasize the different focal points of the errors makes
  157. things a lot more readable. And good idea including the images of
  158. your proposed messages in the RFC - that makes it simple to
  159. evaluate.</p>
  160. </blockquote>
  161. <p>OK, that’s really loading up the praise. And it’s all true. The above
  162. took me a few minutes to come up with, which is a fair bit of work
  163. just to grease the wheels. One might do more or less depending on the
  164. situation. Now that we’ve pumped him up we’re ready to crush his hopes -
  165. er, offer gentle, constructive criticism.</p>
  166. <p>So back in reality, I didn’t actually write all that - I wrote the
  167. impulsive thing, then tossed and turned all night regretting it. To
  168. 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
  169. here:</p>
  170. <blockquote>
  171. <p>@jonathandturner my comments could have been more constructive. Let
  172. me respond to myself.</p>
  173. </blockquote>
  174. <blockquote>
  175. <blockquote>
  176. <blockquote>
  177. <p>“Famous programmers like John Carmack have praised the Elm error
  178. format.”</p>
  179. </blockquote>
  180. </blockquote>
  181. </blockquote>
  182. <blockquote>
  183. <blockquote>
  184. <p>John Carmack’s fame doesn’t really have any bearing on the
  185. validity of the proposal.</p>
  186. </blockquote>
  187. </blockquote>
  188. <blockquote>
  189. <p>Maybe just change ‘fame’ to something more relevant, like
  190. ‘well-respected’, something that better indicates why his opinion is
  191. important.</p>
  192. </blockquote>
  193. <blockquote>
  194. <blockquote>
  195. <p>Also, I don’t think RFCs should be giving props to other
  196. contributors in the summary. When creating the RFC process we made
  197. an explicit decision not to include author information, to avoid
  198. making RFC authorship itself an incentive (I think). If authorship
  199. is something that should be included in RFCs then the process
  200. itself should be modified to include that metadata, including
  201. crediting the actual author, not just their collaborators. If
  202. giving credit in the RFC text is something we want to encourage,
  203. then I don’t know that the summary is the place for it. The
  204. summary is for summarizing the content of the RFC.</p>
  205. </blockquote>
  206. </blockquote>
  207. <blockquote>
  208. <p>I phrased this too strongly. I just had a sudden observation that
  209. we’ve developed ad-hoc ways to credit people that doesn’t fit into
  210. the process as implemented. I should have phrased this more like
  211. ‘maybe we should reconsider how to give credit in RFCs’. RFC process
  212. is organic so it may be perfectly fine to do it like this (author
  213. credit in the commit log, additional credits in the summary), but it
  214. is awkward. And I do believe we made an intentional decision not to
  215. credit people, and if that is changing it is important to
  216. acknowledge it.</p>
  217. </blockquote>
  218. <p>That was … ok, I’m still not particularly happy with it. It still
  219. appears a bit defensive of my dumb position. I wish I could do it
  220. again. I’ll never be happy. I’ll never, ever be happy.</p>
  221. <p>But the point is that it’s best to admit your mistakes, to yourself
  222. and others: Dale Carnegie recommends that “if you’re wrong, admit it
  223. quickly and emphatically”. People love to be right, so if you can
  224. admit that you are wrong and they are right, that can inspire great
  225. cooperation. And it usually doesn’t require any sacrifice at all to
  226. admit you are wrong besides getting over your own pride.</p>
  227. <p><a name="the-techniques"/></p>
  228. <h1 id="the-techniques">The techniques</h1>
  229. <p>So this relatively minor episode caused me to reevaluate how I
  230. communicate online. It’s not like I don’t know how to be nice. I
  231. believe that I do, but sometimes I forget momentarily. So here, to
  232. reinforce my own good behavior, and hopefully for your benefit, I’ve
  233. traced through my basic gameplan for responding to people online.
  234. When I stick to this plan things mostly go well, the people I
  235. encounter feel good about Rust and their association with it, and I
  236. feel relatively ok-ish about myself.</p>
  237. <p>The techniques here apply to any open source venues, like pull
  238. requests, issue trackers, mailing lists and forums.</p>
  239. <p><a name="respond-quickly"/></p>
  240. <h2 id="respond-quickly">Respond quickly</h2>
  241. <p>Immediately after users and contributors reach out to you is when they
  242. are most motivated to help you. Simply getting a quick response can
  243. make a frustrated user’s day. As a maintainer I’ve frequently seen
  244. expectant users express their appreciation: ‘thanks for the quick
  245. response!’. We know that other people’s time is valuable because our
  246. own time is valuable. By responding to an inquiry quickly we
  247. demonstrate that we respect the time they put into e.g. filing a bug
  248. report, and that we are sacrificing our time to help them. Even if I
  249. can’t think about a particular issue right now, and particularly if I
  250. <em>know</em> I’m not going to get to it any time soon, I will sometimes post
  251. a quick acknowledgement and validation of their concerns, like “thanks
  252. for the report. This does look troubling. I’m afraid I won’t be able
  253. to look into this soon, but help is appreciated”, etc.</p>
  254. <p>The longer you wait to respond to a contributor the less likely they
  255. are to stay engaged: only the most hearty contributors will return to
  256. the table after being ignored for a year. Sadly, it’s all too common
  257. that I come across an issue where the most recent comment is from
  258. someone seeking advice, long, long ago. Those contributors are lost
  259. forever, and their potential contributions with them.</p>
  260. <p>For me this is one of the hardest habits to maintain. The neverending
  261. crush of issues and threads in Rust is entirely overwhelming. I’d much
  262. rather I didn’t have to face other people’s problems constantly - I
  263. have so many of my own. It’s impossible to follow everything going on
  264. in Rust, so in practice I tend to restrict the threads I follow to
  265. specific areas, and to those people who are pinging me directly. There
  266. are long stretches where I just can’t face the endless tide of other
  267. people needing assistance, where I will just willfully ignore my
  268. inbox. I don’t recommend that. Better to be responsive.</p>
  269. <p>How quick is quick enough? 3 days. How scientific is this number? It’s
  270. not. You should respond as quick as you can, but reasonable people
  271. will give you a weekend without getting bent about it.</p>
  272. <p><a name="give-thanks"/></p>
  273. <h2 id="give-thanks">Give thanks</h2>
  274. <p>People like to feel appreciated. It’s a universal desire. And
  275. appreciation is something it costs us little to give, to spread about
  276. like parade candy. If you put just a moment’s thought to it, I know
  277. you can see something good in every person and every situation.</p>
  278. <p>The mere act of submitting a patch is awe-inspiring: another person
  279. cares enough about our project that they took the time to understand
  280. how it works, fix our problem, package it up, and submit their work
  281. for public criticism. That’s amazing. Do you remember the first patch
  282. you ever submitted upstream? I bet you were apprehensive. It’s a
  283. crucial moment that can determine the future relationship between the
  284. contributor and the project.</p>
  285. <p>So the first thing to do before mounting a response is to dig deep
  286. into your reserves of universal love, kindness, and compassion, and
  287. seek something to be thankful for. The more specific you can be the
  288. more it shows you care. Did they provide a reproducible test case in
  289. the issue report? Damn, that took some effort! Did they write tests
  290. for their patch? Noway! Usually I have to ask for those! If you keep
  291. thinking about it you’ll discover there’s a great deal to say thanks
  292. for: “Thanks @AHumanWithFeelings! I’ve been wanting to fix this
  293. issue for so long. I’m glad somebody finally stepped up to write a
  294. patch. This looks lovely!”</p>
  295. <p>Of course, not every encounter demands laying it on thick, but do say
  296. “thanks”. Even trivial patches that can merge without any feedback
  297. deserve some comment: just hit the merge button and write, “thanks!”,
  298. and they’ll feel good about the small part they played in your
  299. project’s ongoing success.</p>
  300. <p><a name="pay-a-compliment"/></p>
  301. <h2 id="pay-a-compliment">Pay a compliment</h2>
  302. <p>One of the primary duties of a software maintainer is to review
  303. others’ work. Every day, burning down the endless patch queue. And the
  304. bigger the project the more gruelling the work. Review is where
  305. everything comes together; it is the make-or-break point for
  306. contributors, their work, and their motivation to keep coming back.</p>
  307. <p>Under the exhausting crush of review responsibilities it’s easy to get
  308. tunnel vision; to bee-line for the shortest route to the end, zeroing
  309. in on the problems to be fixed, and moving on to the next patch.</p>
  310. <p>When you do this though you risk discouraging your contributor. The
  311. more work a patch needs the more the critiques pile up, and it can
  312. easily, and unintentionally, result in an avalanche of
  313. negativity. This is particularly likely to affect new contributors,
  314. who are least likely to understand project norms, and most likely to
  315. need guidance.</p>
  316. <p>A well-known technique to soften the weight of criticism is to pair it
  317. with praise. You’ve probably heard of the “compliment sandwich”:
  318. surrounding the criticism - the meat of your response - with a soft
  319. and squishy bun of praise. The compliment sandwich is considered so
  320. delectable because it is simple and effective. Before you launch into
  321. <em>what you really want to say</em>, try to look for something positive to
  322. point out first.</p>
  323. <p>When I review a patch I usually do it in two passes: first I skim
  324. through it with an open mind, with no preconceptions of what I expect
  325. to see. I’m trying to get in their head and see the solution from
  326. their point of view; and in particular trying to find things to like
  327. about their solution. Does the patch display good intuition even while
  328. getting the details wrong? That’s a good starting point. Did they do
  329. something clever that you hadn’t considered? Does their work
  330. demonstrate they’ve read the project’s contribution guidelines in a
  331. way most contributors don’t? You probably have a host of things you
  332. look for to indicate quality, as specific to your project. Make note
  333. of them as you read the patch, <em>and say them first thing in your
  334. response</em>. Myself, I always appreciate when a contributor writes <em>any
  335. tests at all</em>, and I adore contributors who write excellent tests. And
  336. I say so. To take this technique to the next level, be on the lookout
  337. for indicators of the contributor’s own values, and compliment them on
  338. things they are likely to take special pride in.</p>
  339. <p>By reading the whole text once I additionally reduce the chance of
  340. coming to mistaken conclusions, or leaving comments based on
  341. incomplete information. Often I’ve not considered a work as a whole
  342. and left a comment, then moments later realized that comment was
  343. mistaken and had to correct myself. Likewise, I find it frustrating
  344. when reading inline comments about my own work based on incorrect
  345. assumptions, and which I felt I had made clear if the respondent had
  346. only read further.</p>
  347. <p>So after I’ve done the first pass in a spirit of expansive generosity,
  348. and begun composing my review with praise, then I go back for the
  349. second pass and do the detailed review. Even here though I try to note
  350. positive things as well as things that need to be changed, etc.</p>
  351. <p>I’ve focused on reviews here, but the same applies to all
  352. correspondence. Bug report includes a reduced test case?
  353. Awesome. Forum post is well thought out and polite? Halleluja. Always
  354. be looking out for nice things to say about your peers and their work.</p>
  355. <p><a name="say-yes"/></p>
  356. <h2 id="say-yes">Say “yes”</h2>
  357. <p>In the midst of an internet argument it’s easy to lose sight of the
  358. humanity of the individual on the other side of the computer
  359. monitor. Your pulse quickens, your temperature rises, mind races. You
  360. know you are right, technically, morally. Whatever, you are right;
  361. they are wrong. Wrong, wrong, wrong, and you are going to prove it
  362. right now.</p>
  363. <p>But before you fly off the chain, prove your undeniable superiority,
  364. and prove that <em>they are wrong</em>, let me suggest instead that you do
  365. something better, that you do the opposite: that you <em>prove they are
  366. right</em>.</p>
  367. <p>Imagine the most exciting brainstorming session you ever had: you spit
  368. out a brilliant idea - your partner loves it! They respond
  369. enthusiastically by building on your idea. The conversation spirals
  370. ever upward in joyous rapture. It’s an amazing feeling, being on the
  371. same wavelength. By the end up the night you feel thrilled and
  372. intoxicated. That’s the power of positivity.</p>
  373. <p>It’s so rare. When it happens we want to capture that moment and save
  374. its precious essence forever. That’s the kind of magic you want your
  375. contributors to feel every time they file an issue.</p>
  376. <p>The opposite though is far more common, and it’s the death of useful
  377. discourse: “you’re wrong”, “that’s a bad idea”, “I call bs”, “meh”,
  378. “false”, etc. They all amount to a big fat “no”, and they all make the
  379. recipient feel disrespected and generate ill will. Bad vibes. This is
  380. the worst way to open a productive conversation, and people do it all
  381. the time. It’s shocking how tactless smart people can be. Such direct
  382. negativity erects a brick wall fortified with turrets and kettles of
  383. boiling oil in the middle of a conversation.</p>
  384. <p>“No” is a cardinal sin of persuasive argumentation. Don’t do
  385. it. Don’t do it. Don’t do it. No, no, no!</p>
  386. <p>Instead, say “yes” as fast as you can, and in every way you
  387. can. Literally just say “yes” first thing, then figure out what useful
  388. affirmation you can follow with to support that “yes”. If “yes” is too
  389. on-the-nose for your taste then there are a billion ways to
  390. paraphrase. “Yeah” is a great casual option, and my favorite. Follow
  391. that with a comma, “yeah, it’s true that …”, but there are so many
  392. other more subtle ways to drop a huge positivity bomb at the outset of
  393. your response: “totally”, “you’re right about …”, “indeed!”. If you
  394. put your mind to it you can spend a whole paragraph just saying “yes”.</p>
  395. <p>In the end, even if the solution is much different than their original
  396. proposal, by chaining your good ideas to their good ideas, they will
  397. feel successful. Per master thinker Blaise Pascal, “people are
  398. generally better persuaded by the reasons which they have themselves
  399. discovered than by those which have come into the mind of others.”</p>
  400. <p>Affirmation: it’s the secret weapon against belligerent jerkwads.</p>
  401. <p><a name="be-clear-about-what-you-expect"/></p>
  402. <h2 id="be-clear-about-what-you-expect">Be clear about what you expect</h2>
  403. <p>For contributors to stay engaged they need to know what’s next, what
  404. is expected of them. This applies to every level of the project, from
  405. bug reports to pull requests. If you want something, say so directly!
  406. And if you don’t want something, suggest concrete and viable
  407. alternatives. For the most part, if you are in a position of
  408. authority, contributors are <em>desperate</em> for you to give them
  409. direction. Leaving your desires ambiguous is one of the easiest ways
  410. to destroy contributors’ motivation and lose their manpower.</p>
  411. <p>This applies especially in two places: on the bug tracker, and during
  412. reviews. In both cases there is frequently a critical moment when you
  413. have the opportunity to provide clear direction, and though it
  414. requires some effort, failing to do so leaves a vacuum, and thus
  415. leaves potential precious manpower on the table.</p>
  416. <p>Your issue tracker, if it’s like Rust’s, is filled with bugs and
  417. feature requests that you would love to fulfill; but you will never,
  418. ever get to them yourself, not even if you live forever. These
  419. bugs frequently persist in a state of unknowing, where the solution
  420. is unclear, for weeks, months, years, accumulating debate and
  421. discussion about how to move forward. But eventually something clicks
  422. into place, and an acceptable solution becomes known to you. For
  423. simple bugs this moment can be immediately when it is filed; for more
  424. nuanced bugs it can take a long time. But when it happens, you have
  425. the opportunity to clear the way for contributors.</p>
  426. <p>On any bug where there is an acceptable solution, make it crystal
  427. clear what that solution is, and that <em>help is wanted</em>. Contributors
  428. are sometimes just waiting for a signal indicating how they can
  429. help. The more detail you can provide the better. Bugs with clear
  430. direction have 100% better chance of drawing contributions than those
  431. without. The larger your project, and the larger your contributor
  432. base, the more important it is that you consistently provide
  433. direction, and that contributors have a way to find the bugs that have
  434. reached this inflection point.</p>
  435. <p><a name="admit-your-mistakes"/></p>
  436. <h2 id="admit-your-mistakes">Admit your mistakes</h2>
  437. <p>Like variable bindings in a great many programming languages, our
  438. reality is supremely mutable. Conditions change, facts change, and so
  439. does our perception and understanding. Being wedded to past
  440. understanding and past resolutions is dogma. On the other hand,
  441. confronting change honestly and efficiently is a common trait of
  442. successful individuals and organizations. The agility to let old
  443. opinions go and steer a new course helps organizations stay relevant
  444. in the face of shifting fortunes, and helps us navigate difficult
  445. social situations in our daily lives.</p>
  446. <p>Differences of opinion are the root of many arguments. People make up
  447. their minds, assert themselves, refuse to listen to counterpoints,
  448. become angry, develop personal animosity toward those that don’t
  449. agree, and the conversation either reaches an ugly standstill, or
  450. devolves into a passionate feud. It’s a common failure mode, and we
  451. want to prevent it from happening as early as we can.</p>
  452. <p>Just like we want to say “yes”, and acknowledge others’ great ideas,
  453. it’s beneficial to look for situations where we can let go of our own
  454. ideas, our own dogma. It’s a hard thing to do: it’s so tempting to
  455. stick to what is comfortable; to force those difficult decisions that
  456. have already been decided to stay in the past; to never let go of our
  457. pride and admit we were wrong, or made mistakes.</p>
  458. <p>But it gets easier with practice, and you might even come to find that
  459. admitting your mistakes brings relief - it feels liberating to let
  460. things go, to get that weight off your mind.</p>
  461. <p>I find that there are very few designs and opinions that, when I look
  462. closely, I am deeply wedded to, and most often when somebody is angry
  463. at something I have done or some decision I have made, it is trivially
  464. true that I’ve made a mistake. Sometimes these are technical mistakes,
  465. and I can let them go by saying “yes, I see what you mean now. That
  466. was the wrong call. Are you interested in submitting a patch to fix
  467. it?”. Sometimes it’s more of a social or political mistake, that I
  468. haven’t expressed my motivations or intentions clearly and the other
  469. person is surprised and disappointed that some outcome is not what
  470. they expected. In these situations I try to acknowledge that the
  471. result has the downsides they’ve identified, and apologize that it
  472. doesn’t suit them, and move on. Note though that it’s best to avoid
  473. the sorts of backhanded non-apologies we often see from politicians
  474. (e.g. “I’m sorry you are angry”). Everybody sees through bullshit, and
  475. it’s more useful to focus on your own thoughts and feelings instead of
  476. mindreading others’.</p>
  477. <p><a name="be-effusive"/></p>
  478. <h2 id="be-effusive">Be effusive</h2>
  479. <p>This is another trick that is super-effective! A unique technique of
  480. the internet age, I’ve only begun to acknowledge its power recently.</p>
  481. <p>Don’t hesitate to go overboard with superlatives and punctuation:
  482. exclamation marks where they shouldn’t be, over-the-top adjectives,
  483. cute emoticon and emoji. I know that it took me a long time to come
  484. around to this point of view. It’s just bad writing to throw in
  485. exclamation marks and superfluous words, right? And emoji aren’t even
  486. words…</p>
  487. <p>“Oh, wow, thank you so much! 💖”</p>
  488. <p>Truth is that on the internet this is not bad writing, at least for
  489. one-on-one communication. It is effective writing. It’s well
  490. understood that conveying tone on the internet is <em>hard</em>:</p>
  491. <p>“Thanks.”</p>
  492. <p>What does that period mean? It looks so gruff. Are they pissed at me?!
  493. Are they having a bad day? On the internet the simple period can
  494. appear sarcastic, or angry. It’s so neutral that people will project
  495. whatever emotions they want on it. One must go out of their way to not
  496. only get their meaning across but also the tone - and for our purposes
  497. the tone we want is almost always one of abundant positivity and
  498. enthusiasm.</p>
  499. <p>To help you kickstart this habit, here’s a list of some of my
  500. favorite superlatives, emoticon, and emoji, when applied to
  501. technical communication in open source software communities:</p>
  502. <ul>
  503. <li>”!” (exclamation mark)</li>
  504. <li>“super-“</li>
  505. <li>“totally”</li>
  506. <li>“amazing”</li>
  507. <li>“awesome”</li>
  508. <li>“really”</li>
  509. <li>&lt;3 (heart)</li>
  510. <li>&lt;3 &lt;3 &lt;3 (triple-heart!)</li>
  511. <li>:-D (big-ol’ grin)</li>
  512. <li>😁 (grinning face with smiling eyes)</li>
  513. <li>😍 (smiling face with heart-shaped eyes)</li>
  514. <li>💖 (sparkling heart)</li>
  515. </ul>
  516. <p>These are just the ones in my own toolbag. There are so many others,
  517. and there’s lots of room for creative expression here. The younger you
  518. are the more of these weapons you probably have in your arsenal, what
  519. with all the texting and instagramming and tweeting. Deploy them
  520. without hesitation.</p>
  521. <p>There are limits to good taste here, but you probably have to decide
  522. them for yourself. Personally, I never use more than one exclamation
  523. point; two exclamation points is the epitome of tackiness 😜. And as a
  524. child of the 90’s I’m consistently tempted to sneak in a few
  525. “radical”s and “bodacious”es, to embody my life-long wish to become a
  526. Ninja Turtle, but sadly those adjectives seem to be out of style for
  527. the present moment. The time will come though.</p>
  528. <p>Just as a big smile can brighten someone’s day in the physical world,
  529. a little bit of 😍 goes a long way in the virtual world.</p>
  530. <p><a name="summary"/></p>
  531. <h1 id="summary">Summary</h1>
  532. <p>So that’s all you need to make everybody happy, and make everybody
  533. love you! Now you know the secret and you will never fail again.</p>
  534. <p>Ha, ha, no. No, not really. Not everything goes smoothly just by being
  535. nice. Some people are deeply broken. So many messed up people (maybe
  536. I’m one of them - maybe you are too). Typical social wheel-greasing
  537. doesn’t always work with them; they are hell-bent on sowing chaos,
  538. even if they don’t know it. The guidelines here are still applicable
  539. to these cases, because at least other, more reasonable, people will
  540. see that you are doing your best, but truly dealing with them
  541. effectively is a complex and uncertain matter. For another day.</p>
  542. <p>Some of what I’ve said here may have sounded sarcastic, I know. That’s
  543. me. I’m a deeply cynical individual, but I’m working on it. Effective
  544. communication though needs to be genuine, empathetic, and respectful.
  545. Everybody sees right through bullshit. Work on your empathy, work on
  546. being genuinely nice, but until then, fake it ‘till you make it. If I
  547. practice good communication habits consistently, presumably at some
  548. point I will become a good person. That’s how it works, right? I so
  549. want to be a good person.</p>
  550. <p>In summary, do these things if you want to <em>appear to be</em> nice, and
  551. also if you want to <em>actually be</em> an effective open source software
  552. maintainer:</p>
  553. <ul>
  554. <li><a href="#respond-quickly">Respond quickly</a></li>
  555. <li><a href="#give-thanks">Give thanks</a></li>
  556. <li><a href="#pay-a-compliment">Pay a compliment</a></li>
  557. <li><a href="#say-yes">Say “yes”</a></li>
  558. <li><a href="#be-clear-about-what-you-expect">Be clear about what you expect</a></li>
  559. <li><a href="#admit-your-mistakes">Admit your mistakes</a></li>
  560. <li><a href="#be-effusive">Be effusive</a></li>
  561. </ul>
  562. <p>By consistently exhibiting a few simple behaviors, one can at least
  563. look like a kind and decent person. Maybe someday we all actually will
  564. be.</p>
  565. <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
  566. People</a>. Read that.</em></p>