Merge pull request #21 from github/blank-lines

Remove consecutive blank lines

getting-started/branding.md

@@ -5,64 +5,40 @@ next: getting-started/preparing.md
 
 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.
 
-
-
 Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. For example, some of your users might be employees; you don’t want to make them uncomfortable when they have to explain your project’s name to coworkers!
 
 ## Avoiding 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. Whether it’s official documentation or a casual email, how you write 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 [Apache Software Foundation] 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. [...]*
 
-
-
 *Every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud.* [1]
 
-
-
 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.
 
 ### Footnotes

getting-started/legal.md

@@ -4,32 +4,24 @@ title: The legal side of open source
 
 Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn’t know you had to worry about.
 
-
-
 Thankfully, you don’t have to start from scratch. This section will make sure you’ve got all your legal needs covered.
 
-
-
 **(Do we need a legal disclaimer for this piece?)**
 
 ## Table of Contents
+
 1. [Why do I need an open source license?](#why-do-i-need-an-open-source-license)
 2. [Which open source license is appropriate for me?](#which-open-source-license-is-appropriate-for-me)
 3. [Do I need a contributor agreement in addition to my open source license?](#do-i-need-a-contributor-agreement-in-addition-to-my-open-source-license)
 4. [I’m a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know)
 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know)
 
-
 ## Why do I need an open source license?
 
 When you publish a creative work (which includes code), your work is under copyright by default. Unless you include a license that specifies otherwise, nobody can copy or modify your work without being subject to copyright law.
 
-
-
 An open source license guarantees that others can use, modify and share your project. It protects both you and anybody else who might interact with your project.
 
-
-
 Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work is otherwise copyrighted unless you add an open source license.
 
 ## Which open source license is appropriate for me?
@@ -63,14 +55,11 @@ You can also consider using a DCO, which is less cumbersome than signing an agre
 
 If you are a company open sourcing a project, there are a few legal aspects you may want to consider.
 
-
 * **Existing Intellectual Property (IP):** Consider whether there is anything existing in the project that might fall under company IP, which you would not want to make available to the general public. If so, you could open source the rest of your project, but keep the IP private.
 * **Future Patents:** If you are concerned that there may be patents associated with your project later on, use an open source license that provides patent protections (such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/)).
 * **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects, especially if you expect employees to maintain the project. A clear corporate policy will reduce confusion among your employees and encourage them to make open source contributions during work hours. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
 * **Trademarks:** Double check that your project’s name does not conflict with any existing trademarks. If you use your own company trademarks in the project, check that it does not cause any conflicts.
 
-
-
 These are starting points for conversation. Be sure to run any open source project by your legal team before proceeding!
 
 ## I’m using others’ open source code. What does my legal team need to know?
@@ -85,7 +74,6 @@ If you use others’ open source code to create anything that could be considere
 
 To learn more about the implications of different open source licenses, [TLDRLegal](https://tldrlegal.com/) is a great resource.
 
-
 ### Further reading
 
 * [http://choosealicense.com](http://choosealicense.com)

getting-started/preparing.md

@@ -54,7 +54,6 @@ As a maintainer, READMEs are an opportunity to clarify your goals in public. If
 
 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.
@@ -77,7 +76,6 @@ Codes of conduct help protect not just your participants, but yourself. As you m
 
 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.

sustaining/healthy-communities.md

@@ -9,8 +9,6 @@ If you’re starting an open source project today, the vast majority of contribu
 
 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

sustaining/leadership.md

@@ -7,6 +7,7 @@ Your project is growing, people are engaged, and you’re committed to keeping t
 In this section, we’ll answer some commonly asked questions about leadership and governance for open source projects.
 
 ## Table of Contents
+
 1. [What are some of the common governance structures for open source projects?](#what-are-some-of-the-common-governance-structures-for-open-source-projects)
 2. [Do I need governance docs when I launch my project?](#do-i-need-governance-docs-when-i-launch-my-project)
 3. [When should I give someone commit access?](#when-should-i-give-someone-commit-access)

troubleshooting/index.md

@@ -2,14 +2,14 @@
 title: Troubleshooting
 ---
 
-
 This section of the handbook addresses some common situations or questions that may come up as you maintain your open source project.
 
 These topics aren’t fun. They may feel unfamiliar or force you out of your comfort zone. No matter what you do, people may feel upset or criticize how you handled the situation.
 
 Sometimes, being a maintainer is a thankless job. If you’re reading this section, though, you’ve taken an important first step towards becoming a leader, and for that, we thank you. ❤️
 
 ## Troubleshooting topics
+
 * [Enforcing your code of conduct](conduct/)
 * [Feeling guilty or burned out](burnout/)
 * [Finding community consensus](finding-consensus/)