Fix 301 redirects

getting-started/defining.md

@@ -29,7 +29,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new-
 
 Public repositories on GitHub are covered by [GitHub's Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), 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.
 
-A **public** repository is not **open source** unless you choose an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](../legal).)
+A **public** repository is not **open source** unless you choose an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](../legal/).)
 
 It's easy to add a license. You'll be [asked to add one](https://help.github.com/articles/open-source-licensing/) when you create a new repository.
 

getting-started/index.md

@@ -18,28 +18,28 @@ First things first: we're here to help you launch projects of all shapes and siz
 
 You've heard a lot about this "open source" thing and you'd like to release a project for the first time.
 
-If you're worried about getting things right, check out ["Preparing for launch"](preparing) for a quickstart guide, as well as the [Marketing](../marketing) section.
+If you're worried about getting things right, check out ["Preparing for launch"](preparing/) for a quickstart guide, as well as the [Marketing](../marketing/) section.
 
 ## You've open sourced projects before, but you'd like to sharpen your skills
 
 You currently maintain a few open source projects. You understand the basic mechanics, but there are some things you think you could do better.
 
-If you're hoping to improve your skills as a maintainer, take a look at the [Sustaining Growth](../sustaining) and [Troubleshooting](../troubleshooting) sections.
+If you're hoping to improve your skills as a maintainer, take a look at the [Sustaining Growth](../sustaining/) and [Troubleshooting](../troubleshooting/) sections.
 
 ## You're trying to build a large community project
 
 For you, the best part about open source is _collaboration_. You're excited to work on a project with people from all over the world.
 
-If community is important to you, keep an eye out for resources such as ["Building a community"](../marketing/building-community) and ["Sustaining healthy communities"](../sustaining/healthy-communities).
+If community is important to you, keep an eye out for resources such as ["Building a community"](../marketing/building-community/) and ["Sustaining healthy communities"](../sustaining/healthy-communities/).
 
 ## You're a company open sourcing a project
 
 Your company is about to open source a previously internal project. You want to do it without breaking any laws or upsetting anyone who will interact with your project.
 
-If you're hoping to become a good corporate citizen, ["The legal side of open source"](legal) and ["Leadership & governance"](../sustaining/leadership) can help you with trademark, license, and other company matters.
+If you're hoping to become a good corporate citizen, ["The legal side of open source"](legal/) and ["Leadership & governance"](../sustaining/leadership/) can help you with trademark, license, and other company matters.
 
 ---
 
-One more thing: we can give you advice on running an open source project, but we're not lawyers. Be sure to read our [disclaimer](../disclaimer) before you dive in.
+One more thing: we can give you advice on running an open source project, but we're not lawyers. Be sure to read our [disclaimer](../disclaimer/) before you dive in.
 
 Ready to go? Let's get started!

getting-started/legal.md

@@ -4,7 +4,7 @@ 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. Before you dive in, be sure to read our [disclaimer](../../disclaimer).
+Thankfully, you don't have to start from scratch. This section will make sure you've got all your legal needs covered. Before you dive in, be sure to read our [disclaimer](../../disclaimer/).
 
 * TOC
 {:toc}

getting-started/setting-expectations.md

@@ -1,5 +1,5 @@
 ---
-title: Setting expectations
+title: Setting expectations for your open source project
 next: getting-started/branding.md
 ---
 

marketing/measuring.md

@@ -5,7 +5,7 @@ next: sustaining/index.md
 
 Your project is starting to grow. 🌱 Well, you think it's growing. Is it growing? Let's talk about how to measure and track the success of your open source project.
 
-Popularity isn't everything. Everybody gets into open source for different reasons. If [your goal](../../getting-started/setting-expectations) was to show off your portfolio work, be transparent about your code, or just have fun, don't feel pressured to grow your project through the metrics outlined below.
+Popularity isn't everything. Everybody gets into open source for different reasons. If [your goal](../../getting-started/setting-expectations/) was to show off your portfolio work, be transparent about your code, or just have fun, don't feel pressured to grow your project through the metrics outlined below.
 
 If you _are_ interested in growing your project, the following metrics will give you a framework for analyzing and tracking your progress.
 

sustaining/best-practices.md

@@ -14,7 +14,7 @@ In this section, we'll talk about how to set up your projects in a way that help
 
 ## Know yourself and your needs
 
-Remember way back, before you launched your project, [when you wrote down](../../getting-started/setting-expectations) your expectations? It's time to revisit that document now. Remind yourself why you're doing this work and what you want to get out of open sourcing your project. Has anything changed?
+Remember way back, before you launched your project, [when you wrote down](../../getting-started/setting-expectations/) your expectations? It's time to revisit that document now. Remind yourself why you're doing this work and what you want to get out of open sourcing your project. Has anything changed?
 
 Be honest with yourself about how much time you have to spend on your project. This is not the same as how much time you think the project requires, or how much time others want you to spend on the project. Write down your time constraints, and make it public so others understand your priorities, too.
 
@@ -50,7 +50,7 @@ The first rule of open source, [according to](https://twitter.com/solomonstre/st
 
 Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
 
-One of the most important places you'll practice saying no is on your issue and pull request queue. If someone suggests an idea that you know you won't accept, don't leave it open because you feel guilty or want to be nice. Be kind, but firm. Thank them for their contribution and explain why it doesn't fit into the scope of the project. Then [close the request](../../troubleshooting/contributions).
+One of the most important places you'll practice saying no is on your issue and pull request queue. If someone suggests an idea that you know you won't accept, don't leave it open because you feel guilty or want to be nice. Be kind, but firm. Thank them for their contribution and explain why it doesn't fit into the scope of the project. Then [close the request](../../troubleshooting/contributions/).
 
 Defining your project's scope makes closing pull requests with "scope creep" easier. If you notice repeated requests for things you don't want to accept, consider adding them into your contribution policy or modifying your project's scope, so you don't have to keep repeating yourself.
 
@@ -62,7 +62,7 @@ Wherever you can, keep communication about your project public. If somebody trie
 
 It's tempting to respond to private communication, especially early in the life of a project. Resist the temptation. Keeping communication public means less work for you personally. It also creates opportunities for other people to learn and participate. When the communication is public, other people with the same question can easily find answers without having to ask again.
 
-Notable exceptions to this practice are: 1) security issues and 2) sensitive [code of conduct violations](../../troubleshooting/conduct). You should always have a way for people to report these types of issues privately. If you don't want to use your personal communication channels, set up a separate email address for this purpose.
+Notable exceptions to this practice are: 1) security issues and 2) sensitive [code of conduct violations](../../troubleshooting/conduct/). You should always have a way for people to report these types of issues privately. If you don't want to use your personal communication channels, set up a separate email address for this purpose.
 
 ## Automate your work