├── .editorconfig
├── .gitattributes
├── .github
└── contributing.md
├── .gitignore
└── README.md
/.editorconfig:
--------------------------------------------------------------------------------
1 | root = true
2 |
3 | [*]
4 | indent_style = space
5 | end_of_line = lf
6 | charset = utf-8
7 | indent_size = 2
8 | trim_trailing_whitespace = true
9 | insert_final_newline = true
10 |
11 | [{**/{actual,fixtures,expected,templates}/**,*.md}]
12 | trim_trailing_whitespace = false
13 | insert_final_newline = false
--------------------------------------------------------------------------------
/.gitattributes:
--------------------------------------------------------------------------------
1 | # Enforce Unix newlines
2 | * text eol=lf
3 |
4 | # binaries
5 | *.ai binary
6 | *.psd binary
7 | *.jpg binary
8 | *.gif binary
9 | *.png binary
10 | *.jpeg binary
11 |
--------------------------------------------------------------------------------
/.github/contributing.md:
--------------------------------------------------------------------------------
1 | # Contributing to maintainers-guide-to-staying-positive
2 |
3 | First and foremost, thank you! We appreciate that you want to contribute to maintainers-guide-to-staying-positive, your time is valuable, and your contributions mean a lot to us.
4 |
5 | **What does "contributing" mean?**
6 |
7 | Creating an issue is the simplest form of contributing to a project. But there are many ways to contribute, including the following:
8 |
9 | - Updating or correcting documentation
10 | - Feature requests
11 | - Bug reports
12 |
13 | If you'd like to learn more about contributing in general, the [Guide to Idiomatic Contributing](https://github.com/jonschlinkert/idiomatic-contributing) has a lot of useful information.
14 |
15 | **Showing support for maintainers-guide-to-staying-positive**
16 |
17 | Please keep in mind that open source software is built by people like you, who spend their free time creating things the rest the community can use.
18 |
19 | Don't have time to contribute? No worries, here are some other ways to show your support for maintainers-guide-to-staying-positive:
20 |
21 | - star the [project](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive)
22 | - tweet your support for maintainers-guide-to-staying-positive
23 |
24 | ## Issues
25 |
26 | ### Before creating an issue
27 |
28 | Please try to determine if the issue is caused by an underlying library, and if so, create the issue there. Sometimes this is difficult to know. We only ask that you attempt to give a reasonable attempt to find out. Oftentimes the readme will have advice about where to go to create issues.
29 |
30 | Try to follow these guidelines
31 |
32 | - **Investigate the issue**:
33 | - **Check the readme** - oftentimes you will find notes about creating issues, and where to go depending on the type of issue.
34 | - Create the issue in the appropriate repository.
35 |
36 | ### Creating an issue
37 |
38 | Please be as descriptive as possible when creating an issue. Give us the information we need to successfully answer your question or address your issue by answering the following in your issue:
39 |
40 | - **version**: please note the version of maintainers-guide-to-staying-positive are you using
41 | - **extensions, plugins, helpers, etc** (if applicable): please list any extensions you're using
42 | - **error messages**: please paste any error messages into the issue, or a [gist](https://gist.github.com/)
43 |
44 | ## Above and beyond
45 |
46 | Here are some tips for creating idiomatic issues. Taking just a little bit extra time will make your issue easier to read, easier to resolve, more likely to be found by others who have the same or similar issue in the future.
47 |
48 | - read the [Guide to Idiomatic Contributing](https://github.com/jonschlinkert/idiomatic-contributing)
49 | - take some time to learn basic markdown. This [markdown cheatsheet](https://gist.github.com/jonschlinkert/5854601) is super helpful, as is the GitHub guide to [basic markdown](https://help.github.com/articles/markdown-basics/).
50 | - Learn about [GitHub Flavored Markdown](https://help.github.com/articles/github-flavored-markdown/). And if you want to really go above and beyond, read [mastering markdown](https://guides.github.com/features/mastering-markdown/).
51 | - use backticks to wrap code. This ensures that code will retain its format, making it much more readable to others
52 | - use syntax highlighting by adding the correct language name after the first "code fence"
53 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | # always ignore files
2 | *.DS_Store
3 | *.sublime-*
4 |
5 | # test related, or directories generated by tests
6 | test/actual
7 | actual
8 | coverage
9 |
10 | # npm
11 | node_modules
12 | npm-debug.log
13 |
14 | # misc
15 | _gh_pages
16 | benchmark
17 | bower_components
18 | vendor
19 | temp
20 | tmp
21 | TODO.md
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Maintainer's Guide to Staying Positive
2 |
3 | > Don't let the trolls get you down! Use this reference to avoid open-source burnout and keep doing what you love: writing code!
4 |
5 | * [Preamble](#preamble)
6 | - [What is this?](#what-is-this-about)
7 | - [Why did I write this?](#why-did-i-write-this)
8 | * [Nothing fails like success](#nothing-fails-like-success)
9 | * [Do's and don'ts](#dos-and-donts)
10 | * [Action items](#action-items)
11 | * [Help, or do no harm](#help-or-do-no-harm)
12 | * [When all else fails](#when-all-else-fails)
13 | * [Author](#author)
14 | * [License](#license)
15 |
16 | _(You might also be interested in the [Guide to Idiomatic Contributing](https://github.com/jonschlinkert/idiomatic-contributing))_
17 |
18 |
19 |
20 |
21 |
22 | 
23 |
24 |
25 |
26 |
27 |
28 | ## Preamble
29 |
30 | This guide was written by me, [Jon Schlinkert](#author), programmer, public speaker and author of more than 1,100 code projects. I have published code projects in several different languages, but most are JavaScript. 90+ of my projects receive more than 10 million downloads/month, with the total exceeding `3.9 billion downloads/month`. This brief guide is a distillation of my experiences as a maintainer.
31 |
32 | If you find this useful (and I hope you do!), please consider following me on [github](https://github.com/jonschlinkert) or [twitter](http://twitter.com/jonschlinkert) to receive updates about this and other projects I maintain.
33 |
34 | You might also be interested in [other guides I've written](#other-guides).
35 |
36 | ### What is this about?
37 |
38 | As it relates to open source programming, this is my own personal reference to help me stay positive when I'm having a bad day, or for whatever reason it's more difficult than usual to stay objective.
39 |
40 | Whether it's due to a bad decision I've made myself, or I'm reacting to unnecessarily harsh or negative comments made by a user, I thought it would be nice to have a guide to help me re-center when I'm not at my best. Maybe others will find this useful too.
41 |
42 | ### Why did I write this?
43 |
44 | > I want to spend more time doing what I love, and less time doing things that I don't love.
45 |
46 | I really, honestly love programming. So much so that I look forward to getting out of bed every morning so that I can start writing code. I'm a coffee-drinker, and sometimes I even start coding before I make my coffee or get breakfast. If you drink coffee too, you'll know that this says a lot.
47 |
48 | I also love collaborating, exchanging ideas, learning better and faster ways to accomplish things that I'm already familiar with or, even better, learning completely new things that broaden my horizons as a developer or person.
49 |
50 | I enjoy getting feedback from friends - or programmers I'm building friendships with on GitHub, hearing their thoughts about my code and what I could have improved. Mistakes I made, or how something could be optimized. I believe this is one of the fastest ways to improve. Not to mention, it's a great way to build lasting relationships.
51 |
52 |
53 |
54 |
55 |
56 | 
57 |
58 |
59 |
60 |
61 |
62 | ## Nothing Fails Like Success
63 |
64 | I learned this concept from reading books by Stephen R. Covey, probably [The Seven Habits of Highly Effective People](https://www.amazon.com/dp/B01069X4H0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1).
65 |
66 | In a nutshell, this means that sometimes success comes at a price. For example, it's not unusual for a project to get harder to maintain as it grows in popularity:
67 |
68 | - More bugs and edge cases crop up
69 | - More issues are created
70 | - Users want more features
71 | - More detailed documentation is needed
72 | - Protocols and conventions that were "nice-to-have" before, are now 100% necessary
73 | - Your "breathing room" for mistakes gets smaller (no one wants to make mistakes, but it's even worse when you get berated for it by a disgruntled user)
74 |
75 | Of course, this is not always the case, but when it does happen it can be difficult to keep up with.
76 |
77 | IMHO, these things are all fine and should be expected. They come with the territory of programming and maintaining open source projects. From that standpoint my typical reaction to most problems is: "get over it".
78 |
79 | But what shouldn't come with the territory - and no maintainer should have to lose sleep over - is dealing with trolls and negative comments from users who only seem to want to beat the maintainers into submission, while showing no intent of helping to improve the project itself. This isn't programming, or maintaining, it's conflict resolution and PR, and it can be exhausting.
80 |
81 | I know a few popular maintainers of highly popular projects who have either completely given up on collaborating publicly on any kind of open source development, or they switched to other languages to allow themselves to "start over" with a new community (specifically because of having to deal with negative people on GitHub). I don't want to get to this point. I'm a positive person in general, and I'd rather find a way to insulate myself from these people so I can continue to find a way to continue doing what I love.
82 |
83 | **Note on what "negative comment" means**
84 |
85 | There is a world of difference between a disgruntled user who expresses their frustration in a reasonable way, and a user who seems to only have their own self-interests in mind and wants to make sure that you pay attention to them by insulting you or making disparaging comments.
86 |
87 | If you require clarification on this, or find that you need help understanding the difference between a constructive comment and an antagonistic comment, or you feel inclined to debate what "negative comment" means, then please consider reading [this section](#help-or-do-no-harm).
88 |
89 |
90 |
91 |
92 |
93 | 
94 |
95 |
96 |
97 |
98 |
99 | ## Do's and don'ts
100 |
101 | If you find yourself in need of a morale boost, here are some tips for staying positive:
102 |
103 | ### Do
104 |
105 | 1. **Focus on what you want**: Be positive. When you focus on _what you don't want_, you tend to attract what you don't want. Focus on what you want, and you will get what you want.
106 | 1. **Make lemons into lemonade**: look for the best, most optimistic viewpoint possible, no matter how negative the situation.
107 | 1. **Pace yourself**: If something happens that makes you want to scream from the top of your lungs, just take a step back, breathe, and give yourself time to think about it.
108 | 1. **Do research**: A good way to boost your own morale is to get a grip on the situation. Do some research to learn about what's causing the problems you're dealing with to regain control and find ways to resolve it.
109 | 1. **Add levity**: Be careful not to come across as flippant or insincere. But sometimes it helps to just lighten the mood with a smile or nice comment.
110 |
111 | ### Don't
112 |
113 | 1. **Don't blow things out of proportion**: The sky isn't falling. Things are rarely, if ever, really as bad as they seem. Take a step back and get some perspective.
114 | 1. **Don't let others determine how you feel**: You are in control of your own emotions and your own reactions. No one makes you feel a certain way. If you are feeling heated in response to something someone has said, take some time to reflect on the situation.
115 | 1. **Don't comment until you're rational**: Sometimes it feels like you need to "put a fire out" before it spreads. Whether you need to respond to a troll, or to a flood of bug-related comments, don't say anything unless you can do it rationally. How does this tip help you stay positive? Even if you need to act quickly, saying something insensitive or inappropriate can only make things worse. Doing this will definitely not help you keep a positive attitude, and it won't help your teammates or contributors either.
116 |
117 |
118 |
119 |
120 |
121 | 
122 |
123 |
124 |
125 |
126 |
127 | ## Action items
128 |
129 | Sometimes attitude isn't enough and we need to take action. Here are some things that, while extreme, are sometimes necessary in order to keep a positive outlook:
130 |
131 | 1. **Block negative users**: When you find yourself repeatedly dealing with a troll, there is no shame in permanently shedding the negativity by blocking the user completely. Moreover, you are under no obligation to explain yourself to the user.
132 | 1. **Delete inappropriate comments**: If a comment is antagonistic, disparaging to maintainers, distracts from the actual issue at hand, or otherwise does nothing to further progress on an issue, it goes without saying that the comment should be deleted. There is no contract, written or otherwise, that obligates you to retain comments like this. Whatever sense of integrity you feel you might lose from deleting the comment should be regained by thinking about the impact the comment has on your community - and the spirit of collaboration - as a whole.
133 | 1. **Move on**: Don't linger on negative things. Stay productive and get refocused on things that are positive at best, or at least neutral if necessary.
134 |
135 |
136 |
137 |
138 |
139 | 
140 |
141 |
142 |
143 |
144 |
145 | ## Help, or do no harm
146 |
147 | This section is for those who just can't find a way to stay positive, and are having trouble keeping their negativity to themselves.
148 |
149 | A mentor once said to me, "If I cannot help, I will at least _do no harm_". I now try to live by this rule, and I suggest you do too. It's only practical. You don't have to be [half-Betazoid](https://en.wikipedia.org/wiki/Deanna_Troi) to understand that other people are more likely to go out of their way to help you when you're nice to them. After all, just because you experienced a bug doesn't mean that it's a crucial bug, or that it's urgent. Only the maintainers have the perspective to make this call. Good collaborators recognize this and do what they can to help - or stay out of the way if they can't.
150 |
151 | But if you find that you are so frustrated about a bug you're dealing with that you can barely see straight, and you want to make sure the project's maintainers understand what you're going through, consider the following:
152 |
153 | 1. The (extreme) vast majority of open source projects are maintained by a single individual (I don't have stats on this, but I have a lot of experience in open source and I'd wager it's in the high 99th percentile. Big teams with lots of development resources are very, very rare).
154 | 1. Based on the first point, it's easy to reason that the vast majority of decisions made on the vast majority of open source projects are at the discretion of a single individual.
155 | 1. Based on the previous points it easy to reason that innovation, bug fixes and other improvements on these projects will only happen when a single individual wants them to.
156 |
157 | Now, we can take this information and do what we want with it. If you absolutely need something to be fixed, and it isn't getting fixed, you have options. The most obvious of which are:
158 |
159 | - fork the project and maintain it yourself
160 | - create your own library (but be sure to give proper attribution if your code is based on another library)
161 |
162 | If you don't have the time, knowledge, or inclination to do either of those things, unfortunately, that's just too bad. It's your problem, not the maintainers. The sooner you get over this, the happier and more productive everyone will be. Under no circumstances is it acceptable to berate a project's maintainers because you aren't getting what you want.
163 |
164 | - It's not okay to "call them out" for taking too long
165 | - It's not okay to point to other issues that aren't being resolved, "just to make your point". This just adds insult to injury.
166 | - It's not okay to sling personal insults when you feel like you're being ignored
167 |
168 | **Exceptions to the rule**
169 |
170 | Here are the times when the above things are okay:
171 |
172 | - You are paying the maintainer and have a service level agreement that gives you the right to do these things
173 | - Never
174 |
175 |
176 |
177 |
178 |
179 | 
180 |
181 |
182 |
183 |
184 |
185 | ## Use Negativity as a Test of Character
186 |
187 | To quote Mr. Kipling:
188 |
189 | > If you can bear to hear the truth you’ve spoken
190 | > Twisted by knaves to make a trap for fools,
191 | > Or watch the things you gave your life to, broken,
192 | > And stoop and build ’em up with worn-out tools:
193 | > If you can fill the unforgiving minute
194 | > With sixty seconds’ worth of distance run,
195 | > Yours is the Earth and everything that’s in it,
196 |
197 | If you can deal with the trolls, the negativity, the setbacks, the failures, and have the courage to start again, to fail again, then you'll embody the power of perseverance, and you'll carry that character with you in all other aspects of your life.
198 |
199 |
200 |
201 |
202 |
203 | 
204 |
205 |
206 |
207 |
208 |
209 | ## Focus on what is _truly_ important
210 |
211 | There'll always be fakes, trolls and (real) imposters. Karma's a bitch, let her deal with them. What's most important are your family and close friends. Work hard for them - they are the only ones who will always appreciate you.
212 |
213 |
214 |
215 |
216 |
217 | 
218 |
219 |
220 |
221 |
222 |
223 | ## When all else fails
224 |
225 | Consider getting yourself [one of these](https://web.archive.org/web/20161017204855/https://twitter.com/mark_essig/status/787832689487470596).
226 |
227 |
228 |
229 |
230 |
231 | 
232 |
233 |
234 |
235 |
236 |
237 | ## About
238 |
239 | ### Contributors
240 |
241 | Thanks to the following devs who have helped make this guide better in some way.
242 |
243 |
244 |
245 |
246 | | **Commits** | **Contributor** |
247 | | --- | --- |
248 | | 17 | [jonschlinkert](https://github.com/jonschlinkert) |
249 | | 2 | [rnicholus](https://github.com/rnicholus) |
250 | | 1 | [Kissaki](https://github.com/Kissaki) |
251 | | 1 | [doowb](https://github.com/doowb) |
252 | | 1 | [martinvd](https://github.com/martinvd) |
253 | | 1 | [philmiller-charmworks](https://github.com/philmiller-charmworks) |
254 |
255 | Note: If you'd like to see the _most_ up-to-date and complete contributor information, please visit the [contributors graph](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive/graphs/contributors).
256 |
257 |
258 | ### Other guides
259 |
260 | You might also find these guides useful:
261 |
262 | - [Guide to Staying Productive](https://github.com/jonschlinkert/guide-to-staying-productive/)
263 | - [Idiomatic Contributing](https://github.com/jonschlinkert/idiomatic-contributing/)
264 |
265 | ### Related
266 |
267 | - [Scaling Open Source Communities](https://krausefx.com/blog/scaling-open-source-communities): This is an excellent blog post from [@KrauseFx (Felix Krause)](https://github.com/KrauseFx), in which, among other things, he describes some of the challenges of maintaining growing projects.
268 | - [Dear JavaScript](https://jamie.build/dear-javascript.html): Another great blog post from [@thejameskyle (James Kyle)](https://github.com/thejameskyle), that covers the loss of morale and disenfranchisement that can happen to maintainers when projects become very successful and some users become aggressively negative.
269 |
270 | ### Author
271 |
272 | **Jon Schlinkert**
273 |
274 | * [github/jonschlinkert](https://github.com/jonschlinkert): follow me on GitHub for project updates
275 | * [twitter/jonschlinkert](https://twitter.com/jonschlinkert): follow me on Twitter for the latest news
276 | * [linkedin/jonschlinkert](https://linkedin.com/in/jonschlinkert): connect with me on LinkedIn
277 |
278 | If you'd like to get in touch regarding a speaking engagement or consulting opportunity, please use the email address on my GitHub profile. Thanks!
279 |
280 | ### License
281 |
282 | Copyright © 2016, [Jon Schlinkert](https://github.com/jonschlinkert).
283 | Released under the [CC by 4.0 License](https://creativecommons.org/licenses/by/4.0/legalcode).
--------------------------------------------------------------------------------