Introduction & Getting Started

README.md

@@ -4,6 +4,8 @@ This handbook is a collection of resources to help individual, communities, and
 
 This handbook aims to foster healthy open source communities, and provide a canonical place for the community to discuss and codify best practices into highly-approachable resources.
 
+### [Get Started](_content/index.md)
+
 ## Contributing
 
 This handbook aims to reflect community best practices. Check out [CONTRIBUTING.md](/CONTRIBUTING.md) for ways to offer feedback and contribute.

_content/getting-started/branding.md

@@ -0,0 +1,47 @@
+# **Branding**
+
+You’ve thought about who your users are, what they need from you, and what you might be able to offer them. Next, we’ll put that research into practice as we consider the brand of your project.
+
+Branding may sound like a waste of time. After all there, are plenty of popular open source projects that have never thought about their brand at all.
+
+But branding is more than a flashy logo or catchy project name. It’s about how you talk about your project and who you reach with your message. Here are a few things you’ll want to think about before you launch.
+
+## Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example, [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting, and [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server.
+
+Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Be clever, but not so clever that the name gets in the way of adoption. For example, some of your users might be company employees; you don’t want to make them uncomfortable when they have to explain your project to coworkers!
+
+## Namespace conflicts
+
+Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts here: http://www.uspto.gov
+
+You’ll also want to look for open source projects with a similar name, especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you will confuse your audience and make it less likely that anyone will use what you’ve created. You can check for similar project names here: http://ivantomic.com/projects/ospnc/
+
+Consider whether you’ll want a website, Twitter handle, or other properties to represent your project. If so, make sure you can get the names you want. Ideally, reserve those names now so you have peace of mind. You can check for domain name availability here: https://instantdomainsearch.com/
+
+Finally, it doesn’t hurt to do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn’t want them to see?
+
+## How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you’ll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. How you write, whether it’s official documentation or a casual email, contributes to the brand of a project. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+[@janl](https://github.com/janl) discovered that the way he spoke to others helped create a positive brand for [CouchDB](https://github.com/apache/couchdb):
+
+> When I started out at CouchDB and we finally joined the ASF and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+>
+> My responsibilities since have shifted quite a bit and I’m no longer checking on the user@ mailing list day-to-day, but every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud.
+
+http://writing.jan.io/2015/11/20/sustainable-open-source.html
+
+Beyond how you write words, your coding style may also become part of your project’s brand. For example, [Angular](https://github.com/johnpapa/angular-styleguide) and [jQuery](http://contribute.jquery.org/style-guide/js/) are two projects with rigorous coding styles and guidelines.
+
+It isn’t necessary to write a style guide for your project when you’re just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing (and coding) style might attract (or not attract) different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+We’re almost there! Next, we’ll walk you through a few components that every open source project should include when you launch.
+
+## Related Content
+
+* http://producingoss.com/en/getting-started.html#choosing-a-name
+
+[Previous](setting-expecations.md) | [Next](preparing.md)

_content/getting-started/index.md

@@ -0,0 +1,35 @@
+# Before You Get Started
+
+## What does it mean to open source a project?
+
+So you’re interested in making your project open source? Congratulations! 🎉 🙌 🌟 The world appreciates your contribution.
+
+Before we get into the details of running and managing an open source project, let’s talk about what open sourcing a project actually means.
+
+## Public projects on GitHub are not open source
+
+When you publish a project on GitHub, you have the option to make the repository **private** or **public**. A public repository is not automatically open source unless you pick a license that grants a certain set of rights to people who might interact with your project.
+
+Open source licenses grant permission to everyone to use, modify, and share licensed software for any purpose, subject to certain conditions, depending on the license.
+
+Public repositories on GitHub [comply with GitHub’s Terms of Service](https://help.github.com/articles/open-source-licensing/), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. **(See also: link to license/legal article here)**
+
+## Open source is about more than just a license
+
+Open source is defined by its legal protections and freedoms. In terms of culture, open sourcing a project has come to mean much more.
+
+There are many reasons why a person or organization might want to open source a project. Some examples are:
+
+* **Transparency:** Making your code visible means that anyone can inspect it for errors or inconsistencies. Transparency matters to government (like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/)), regulated industries like banking or healthcare, and security-related software infrastructure (like [Let’s Encrypt](https://github.com/letsencrypt)).
+
+* **Collaboration:** Projects that are open source can accept changes and updates from anybody. Collaboration matters to those who want to build their projects with a community, like [Hoodie](https://github.com/hoodiehq) and [Rust](https://github.com/rust-lang/rust). When people make improvements together, projects can thrive, because they draw from multiple skill sets, experiences, and levels of involvement.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for any purpose, whether it’s making a custom version of the original project, or using that project to build something else entirely. Code can reach more people when it is shared and reused, like [React](https://github.com/facebook/react) or [Sentry](https://github.com/getsentry/sentry). And new projects can grow out of older projects, like [WordPress and b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md), or [Jenkins and Hudson](https://github.com/jenkinsci).
+
+Remember: open source isn’t just for software! You can open source everything from data sets to websites to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+When you open source a project, you open yourself to feedback and suggestions from other people who are engaged with your work. It might feel intimidating to open source a project for the first time, but remember that you’re not alone.
+
+In the next section, we’ll help you figure out your goals around open sourcing your project. Understanding these goals beforehand will make it easier to manage your and others’ expectations later on.
+
+[Previous](../index.md) | [Next](setting-expectations.md)

_content/getting-started/preparing.md

@@ -0,0 +1,99 @@
+# Preparing for launch
+
+You’re almost ready to launch your project! In this section, we’ll talk about what to include in an open source project before releasing it to the world.
+
+Every open source project should include the following:
+
+* License
+* README
+* Contributing guide
+* Code of conduct
+
+As a maintainer, these components will help you communicate expectations, manage contributions, protect your legal rights, and generally facilitate a positive experience. The more you can document for your readers up front, the less work you’ll have to do later on.
+
+## Choosing a license
+
+An open source license guarantees that others can use, copy, modify and contribute back to your project without repercussions. It also protects you from any sticky legal situations.
+
+Legal work is no fun, but the good news is there are many licenses available that you can copy-paste into your repository. It will only take a minute to protect your hard work.
+
+There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that comply with the generally accepted definition of open source. Some licenses you’ll commonly hear about are:
+
+* [MIT License](http://choosealicense.com/licenses/mit/)
+* [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/)
+* [Mozilla Public License 2.0](http://choosealicense.com/licenses/mpl-2.0/)
+* [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/)
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of these licenses will make your GitHub project open source. (Different licenses carry slightly different permissions. You can use http://choosealicense.com to find the right license for you.)
+
+(include image of license selection on GitHub new repo here?)
+
+## Writing a README
+
+Your project’s README file gives your reader context about the project.
+
+The README does more than explain how to use your project. It should also help your audience understand why the project is useful and what they can do with it.
+
+In your README, try to answer the following questions:
+
+* What does the project do?
+* As a user, how does this project help me?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can also use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution.
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don’t want contributions. These are all very good reasons to write one!
+
+As a maintainer, READMEs are an opportunity to clarify your goals in public. If you don’t want to accept contributions, or your project is not yet ready for production, you should especially write this information down. That way, people understand your needs as soon as they arrive to your project.
+
+When you include a README file in the root directory, GitHub will automatically display it on your project repository’s homepage. It will be the first thing someone sees when they arrive.
+
+## Setting your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might want to tell your reader how to create an issue, file a bug report, test fixes, or format code.
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions. Remember that no two open source projects are alike. Write down rules that work best for you and your lifestyle. For example, you may want to convey that you are only accepting certain types of contributions, tell participants how long they should expect to hear a response from you, or explain how (or how not) to get in touch with you.
+
+If you are a community project, you can use the CONTRIBUTING file to actively solicit the types of contributions you’re looking for. Using a warm, friendly tone and offering specific contribution suggestions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+You should reference your CONTRIBUTING file in your README. In your README, give your audience a quick overview of how contributions work, then link to the CONTRIBUTING file for more information.
+
+If you place your CONTRIBUTING file in the root directory, GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
+
+## Writing a code of conduct
+
+Finally, a code of conduct helps set ground rules for communication among your project’s participants. The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Angular Code of Conduct](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md) are two good examples.
+
+A code of conduct is a place to convey the values or philosophy that define your project. This is especially valuable if you’re a community or company launching an open source project.
+
+Codes of conduct help protect not just your participants, but yourself. As you maintain your project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive about these expectations reduces the likelihood that you, or others, will become fatigued with your project later on. ** (Link to: troubleshooting article about dealing with negative actors.)**
+
+In addition to communicating your expectations, you should describe what happens if someone violates the code of conduct, and where someone can report such behavior. We recommend placing a CODE_OF_CONDUCT file in your root directory.
+
+## What’s next?
+
+Now that you have these four files in the root directory of your project, you’re ready to open source your project! Click "publish" and pat yourself on the back. Then continue on to the next section. We’ve got work to do.
+
+Launching your project is only the first step. If you’re looking for feedback or users, you’ll want to make sure other people know about your project. Over the years, your project will likely go through multiple phases of activity and contributorship. That’s okay! The rest of this handbook is designed to help you manage your project every step of the way.
+
+## Related content
+
+* Licenses
+  * https://github.com/blog/1530-choosing-an-open-source-license
+  * http://choosealicense.com
+* READMEs
+  * http://tom.preston-werner.com/2010/08/23/readme-driven-development.html
+  * https://github.com/matiassingers/awesome-readme
+  * https://pages.18f.gov/open-source-guide/making-readmes-readable/
+  * https://changelog.com/a-beginners-guide-to-creating-a-readme/
+  * https://gist.github.com/jxson/1784669
+* Contributing guides
+  * https://github.com/blog/1184-contributing-guidelines
+  * http://www.contribution-guide.org/
+  * https://github.com/nayafia/contributing-template
+  * http://mozillascience.github.io/working-open-workshop/contributing/
+* Codes of conduct
+  * http://contributor-covenant.org/
+  * https://github.com/django/code-of-conduct
+  * https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/