Add Sustaining Growth section

sustaining/healthy-communities.md

@@ -0,0 +1,86 @@
+---
+title: Sustaining Healthy Communities
+next: sustaining/leadership.md
+---
+
+Your project’s community is extremely powerful. That power can be a blessing or a curse, depending on how you wield it. In this section, we’ll look at ways to structure your community to become a force of construction, not destruction.
+
+If you’re starting an open source project today, the vast majority of contributions will come from "casual contributors": people who contribute to a project only occasionally. Sometimes these are also called “drive-by contributors”.
+
+A casual contributor may not have time to get fully up to speed with your project. Nearly half of contributors on popular GitHub projects, for example, only made one contribution. [1] This level of noise can be overwhelming at first. But the more people feel ownership of your project, the more work can be distributed. [2] It will be much less stressful than trying to do everything yourself.
+
+
+
+Here are some ways you can empower your biggest fans to run with the work they’re excited about.
+
+## Meet contributors where they’re at
+
+Good documentation is important to give casual contributors the context they need. Make sure people know what the goal of your project is and whether there are contributions you categorically won’t accept.
+
+In your CONTRIBUTING.md file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. For example, [Read the Docs](http://docs.readthedocs.io/en/latest/contribute.html#contributing-to-development) tells its readers:
+
+*If you want to deep dive and help out with development on Read the Docs, then first get the project installed locally according to the Installation Guide. After that is done we suggest you have a look at tickets in our issue tracker that are labelled Good First Bug. These are meant to be a great way to get a smooth start and won’t put you in front of the most complex parts of the system.*
+
+In Issues, label bugs that are suitable for beginners: for example, *"good first bug"*, *“help wanted”*, or *“first-timers-only”*. These labels make it easy for someone new to your project to quickly scan your issues and get started. ([Here](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) are some other examples of commonly used labels.)
+
+Finally, use your documentation to make people feel welcome at every step of the way. Remember that you will never meet most of the people who come across your project. There are probably contributions you didn’t receive because somebody felt intimidated or didn’t know where to get started. Do your best to reduce your chances of someone leaving your project in frustration. Even a few kind words can help. For example, here’s how [Rubinius](https://github.com/rubinius/rubinius/blob/master/CONTRIBUTING.md) starts off its contributing guide:
+
+*We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.*
+
+## Share ownership of your project
+
+People are excited to contribute to projects when they feel like it belongs to them. That doesn’t mean you need to turn over your project’s vision or accept contributions you don’t want. But the more you can give credit to others, the more likely it is that they will stick around.
+
+[@orta](https://github.com/orta) found that this approach to ownership helped him succeed with his open source projects, including [Danger](https://github.com/danger/danger/):
+
+*Understanding motivations, encouraging ownership and accommodating multiple viewpoints are vital parts of anyone who wants to make a project bigger than themselves. There [are lots of times](https://github.com/danger/danger/graphs/contributors) when I'm not the lead developer on Danger. [4]*
+
+See if you can find ways to give credit to your community as much as possible. Here are some ideas:
+
+* Resist fixing easy bugs. Instead, use them as opportunities to recruit new contributors, or mentor someone who’d like to contribute. It may seem unnatural at first, but your investment will pay off over time.
+
+* Start a CONTRIBUTORS.txt file in your project that lists everyone who’s contributed to your project. Here’s an example that [@shazow](https://github.com/shazow) made for his project, [urllib3](https://github.com/shazow/urllib3/blob/master/CONTRIBUTORS.txt).
+
+* If you’ve got a sizeable community, consider sending out a newsletter or writing a blog post that calls out contributors and thanks them. Rust’s [This Week in Rust](https://this-week-in-rust.org/) and Hoodie’s [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* Consider giving every contributor commit access. [@felixge](https://github.com/felixge) found that this made people more excited to polish up their patches, and he even found new maintainers for projects that he hadn’t worked on in awhile. [5]
+
+The bigger your project, and the bigger your community, the easier it is to find help. The reality is that most projects only have one or two maintainers who do most of the work. [6] While you many not always find someone to answer the call, putting a Batsignal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. Early investments in your community will pay off over time.
+
+As you build a community of engaged and thoughtful people, you may start thinking about how to formalize their ownership in your project. In the next section, we’ll cover some commonly asked questions around leadership and governance.
+
+## Don’t tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave. Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these types of conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to ask them to leave. Your code of conduct can be a constructive guide for these conversations. **<link to "Enforcing your code of conduct" article>**
+
+### Footnotes
+
+[1] [http://gustavopinto.org/lost+found/saner2016.pdf](http://gustavopinto.org/lost+found/saner2016.pdf)
+
+[3] [Node.js](https://github.com/nodejs) is a big project that helped popularize some of these ideas: [https://medium.com/node-js-javascript/building-a-better-node-community-3f8f45b45cb5#.db5dkrbrw](https://medium.com/node-js-javascript/building-a-better-node-community-3f8f45b45cb5#.db5dkrbrw) 
+
+[4] [http://artsy.github.io/blog/2016/07/03/handling-big-projects/](http://artsy.github.io/blog/2016/07/03/handling-big-projects/)
+
+[5] [http://felixge.de/2013/03/11/the-pull-request-hack.html](http://felixge.de/2013/03/11/the-pull-request-hack.html) 
+
+[6] [https://peerj.com/preprints/1233.pdf](https://peerj.com/preprints/1233.pdf) 
+
+### Further reading
+
+* [https://opensource.com/life/16/5/growing-contributor-base-modern-open-source](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source) 
+
+* [http://writing.jan.io/2015/11/20/sustainable-open-source.html](http://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+* [http://www.mckinsey.com/business-functions/organization/our-insights/whartons-adam-grant-on-the-key-to-professional-success](http://www.mckinsey.com/business-functions/organization/our-insights/whartons-adam-grant-on-the-key-to-professional-success)
+
+* [https://github.com/Moya/contributors](https://github.com/Moya/contributors)
+
+* [https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md) 
+
+* [http://radek.io/2015/08/24/github-issues/](http://radek.io/2015/08/24/github-issues/)
+
+* [http://producingoss.com/en/producingoss.html#difficult-people](http://producingoss.com/en/producingoss.html#difficult-people) 

sustaining/leadership.md

@@ -0,0 +1,87 @@
+---
+title: Leadership & Governance
+---
+
+Your project is growing, people are engaged, and you’re committed to keeping this thing going. At this stage, you’re probably starting to wonder about governance. Maybe you want to recognize a community members who’s made significant contributions to your project. Maybe you’ve gotten into a debate with your community and realized you didn’t know how to resolve it. 
+
+In this section, we’ll answer some commonly asked questions about leadership and governance for open source projects.
+
+## What are some of the common governance structures for community projects?
+
+If you’re a growing community project, there are three common governance structures associated with open source projects:
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example of a BDFL project. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy was pioneered by the [Apache Foundation](http://www.apache.org/); [all Apache projects](http://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. The liberal contribution model was pioneered by [Node.js](https://nodejs.org/en/foundation/). [Rust](https://www.rust-lang.org/en-US/) is another example.
+
+There is no one correct governance model, and although they may seem quite different at first, all three models have more in common than it might seem. If you’re interested in adopting one of these models, here are some templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+
+* [Node.js’s liberal contribution policy](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79)
+
+## Do I need governance docs when I launch my project?
+
+It’s not necessary to define your project’s governance when you launch. The best part about open source governance is that it is shaped by the community!
+
+There is no right time to write down your project’s governance, but it’s much easier to define once you’ve seen your community dynamics play out. However, some documentation will inevitably contribute to your project’s governance, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project’s launch. And if you’re a company launching an open source project, you may also want to explain anything particular to how your company will (or won’t!) be involved with the project.
+
+## When should I give someone commit access?
+
+It’s up to you when you want to give someone commit access to your project. Some people think you should give commit access to everybody who makes a contribution. [1] Doing so could encourage more people to feel ownership of your project. On the other hand, especially for big community projects, you may want to only give commit access to people who have made have demonstrated their commitment. There’s no one right way of doing it - do what makes you most comfortable!
+
+## What are some leadership roles or responsibilities I should consider?
+
+Here are some common roles that you might have heard of for open source projects. What these roles actually mean, though, is entirely up to you.
+
+* Maintainer
+
+* Contributor
+
+* Committer
+
+[Node.js](https://github.com/nodejs), for example, defines a "contributor" as anyone who comments on an issue or pull request, whereas other projects would define a contributor as somebody whose pull request was accepted. [2]
+
+For some projects, "maintainers" are the only people in a project with commit access. In other projects, they’re simply the people who are listed in the README as maintainers.
+
+A maintainer doesn’t necessarily have to be someone who writes code for your project. It could be someone who’s done a lot of work evangelizing your project (like [@janl](https://github.com/janl) did for [CouchDB](https://github.com/apache/couchdb)) or written documentation that made the project more accessible to others (like [@orta](https://github.com/orta) did for [CocoaPods](https://github.com/CocoaPods/CocoaPods)). [3] Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+You should use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. [@jacobian](https://github.com/jacobian), one of [Django](https://github.com/django/django)’s former BDFLs, once told a crowd at PyCon that he is actually a mediocre programmer who joined the project a year after it started, even though he’s often mistaken as the co-creator or even "inventor" of Django. [4]
+
+## How do I formalize leadership roles in my project?
+
+Formalizing your leadership roles helps people take ownership and tells other community members who to look to for help. For a smaller project, designating leaders can be as simple as adding their names to your README. You could also create a separate text file that lists the names of project leaders. If your project has a website, you can create a team page or list your project leaders there.
+
+If your project is bigger, you may have a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas. [Rust](https://github.com/rust-lang/rust) is an example of a project that moved from having one core team to multiple teams. [5] For example, you could have subcommittees focused on security, issue triaging, or community conduct. Let people self-organize and volunteer for the roles they’re most excited about, rather than assigning them.
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, hosts office hours every week. [6]
+
+Once you’ve established leadership roles, don’t forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions in private.
+
+Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization. [GitHub Organizations](https://github.com/blog/674-introducing-organizations) make it easier to manage permissions and help protect your project’s legacy.
+
+## Do I need a legal entity to support my project?
+
+You don’t need a legal entity to support your open source project unless you’re handling money. For example, if you want to create a commercial business, you’ll want to set up a C Corp or LLC (if you’re based in the US). If you’re just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you’re based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won’t be tax-deductible unless you are a nonprofit (such as a 501c3 or 501c6, if you’re in the US). Many projects don’t wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](http://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.python.org/pypi), the Python package manager, and the [Node.js Foundation](https://nodejs.org/en/foundation/) helps support [Express.js](http://expressjs.com/), a Node-based framework.
+
+### Footnotes
+
+[1] [http://felixge.de/2013/03/11/the-pull-request-hack.html](http://felixge.de/2013/03/11/the-pull-request-hack.html) 
+
+[2] [https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.46vkbdar7](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.46vkbdar7)
+
+[3] From Orta: *"I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding."* [https://realm.io/news/orta-therox-moving-to-oss-by-default/](https://realm.io/news/orta-therox-moving-to-oss-by-default/) 
+
+[4] [https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s) 
+
+[5] [https://www.rust-lang.org/en-US/team.html](https://www.rust-lang.org/en-US/team.html) 
+
+[6] [https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs)