jekyll · DirtyF · Nov 9, 2016 · Nov 9, 2016
diff --git a/docs/_docs/continuous-integration.md b/docs/_docs/continuous-integration.md
@@ -229,5 +229,5 @@ an entry in the `.gitignore` file to avoid it from being checked in again.
 This entire guide is open-source. Go ahead and [edit it][3] if you have a
 fix or [ask for help][4] if you run into trouble and need some help.
 
-[3]: https://github.com/jekyll/jekyll/edit/master/site/_docs/continuous-integration.md
+[3]: https://github.com/jekyll/jekyll/edit/master/docs/_docs/continuous-integration.md
 [4]: https://jekyllrb.com/help/
diff --git a/docs/_docs/contributing.md b/docs/_docs/contributing.md
@@ -67,13 +67,13 @@ We want the Jekyll documentation to be the best it can be. We've open-sourced ou
 
 ### How to submit changes
 
-You can find the documentation for jekyllrb.com in the [site](https://github.com/jekyll/jekyll/tree/master/site) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
+You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
 
 One gotcha, all pull requests should be directed at the `master` branch (the default branch).
 
 ### Adding plugins
 
-If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/site/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
+If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/docs/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
 
 ## Code Contributions
 
@@ -85,7 +85,7 @@ Any time you propose a code change, you should also include updates to the docum
 
 #### Documentation
 
-If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `site/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
+If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `docs/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
 
 #### Tests
 

diff --git a/docs/_docs/github-pages.md b/docs/_docs/github-pages.md
@@ -122,9 +122,9 @@ custom domain is specified—see below).
 
 The Jekyll project repository itself is a perfect example of this branch
 structure—the [master branch]({{ site.repository }}) contains the
-actual software project for Jekyll, however the Jekyll website (that you’re
-looking at right now) is contained in the [gh-pages
-branch]({{ site.repository }}/tree/gh-pages) of the same repository.
+actual software project for Jekyll, and the Jekyll website that you’re
+looking at right now is contained in the [docs
+folder]({{ site.repository }}/tree/master/docs) of the same repository.
 
 <div class="note warning">
   <h5>Source Files Must be in the Root Directory</h5>

diff --git a/docs/_docs/maintaining/avoiding-burnout.md b/docs/_docs/maintaining/avoiding-burnout.md
@@ -28,4 +28,4 @@ Jekyll gets a lot of feature requests, non-reproducible bug reports, usage quest
 
 Thanks to https://gist.github.com/ryanflorence/124070e7c4b3839d4573 which influenced this document.
 
-Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
+Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/docs/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
diff --git a/docs/_docs/maintaining/becoming-a-maintainer.md b/docs/_docs/maintaining/becoming-a-maintainer.md
@@ -14,7 +14,7 @@ You want to maintain Jekyll? Use it often. Do weird things with it. Do normal th
 
 ## 2. Help Triage Issues
 
-Watch the repository you're interested in. Join [an Affinity Team](https://teams.jekyllrb.com) and receive mentions regarding a particular interest area of the project. When you receive a notification for an issue that has not been triaged by a maintainer, dive in. Can you reproduce the issue? Can you determine the fix? [More tips on Triaging an Issue in our maintainer guide](triaging-an-issue.md). Every maintainer loves an issue that is resolved before they get to it. :smiley:
+Watch the repository you're interested in. Join [an Affinity Team](https://teams.jekyllrb.com) and receive mentions regarding a particular interest area of the project. When you receive a notification for an issue that has not been triaged by a maintainer, dive in. Can you reproduce the issue? Can you determine the fix? [More tips on Triaging an Issue in our maintainer guide](../triaging-an-issue). Every maintainer loves an issue that is resolved before they get to it. :smiley:
 
 ## 3. Write Documentation
 
@@ -26,7 +26,7 @@ As a maintainer, you will be reviewing pull requests which update code. You shou
 
 ## 5. Review Pull Requests
 
-Start by reviewing one pull request a week. Leave detailed comments and [follow our guide for reviewing pull requests](reviewing-a-pull-request.md).
+Start by reviewing one pull request a week. Leave detailed comments and [follow our guide for reviewing pull requests](../reviewing-a-pull-request).
 
 ## 6. Ask!
 
@@ -36,4 +36,4 @@ We would love to expand the team and look forward to many more community members
 
 # Helping Out Elsewhere
 
-In addition to maintainers of our core and plugin code, the Jekyll team is comprised of moderators for our forums. These helpful community members take a look at the topics posted to https://talk.jekyllrb.com and ensure they are properly categorized and are acceptable under our Code of Conduct. If you would like to be a moderator, email one of the maintainers with links to where you have answered questions and a request to be added as a moderator. More help is always welcome.
+In addition to maintainers of our core and plugin code, the Jekyll team is comprised of moderators for our forums. These helpful community members take a look at t
8000
he topics posted to [https://talk.jekyllrb.com](https://talk.jekyllrb.com) and ensure they are properly categorized and are acceptable under our Code of Conduct. If you would like to be a moderator, email one of the maintainers with links to where you have answered questions and a request to be added as a moderator. More help is always welcome.
diff --git a/docs/_docs/maintaining/merging-a-pull-request.md b/docs/_docs/maintaining/merging-a-pull-request.md
@@ -10,7 +10,7 @@ layout: docs
 
 All pull requests should be subject to code review. Code review is a [foundational value](https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs-b125a13aa292) of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
 
-**Read our guide for [Reviewing a pull request](reviewing-a-pull-request.md) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
+**Read our guide for [Reviewing a pull request](../reviewing-a-pull-request) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
 
 ## Merging
 

diff --git a/docs/_docs/maintaining/reviewing-a-pull-request.md b/docs/_docs/maintaining/reviewing-a-pull-request.md
@@ -8,7 +8,7 @@ layout: docs
 
 ## Respond Kindly
 
-Above all else, please review a pull request kindly. Our community can only be strong if we make it a welcoming and inclusive environment. To further promote this, the Jekyll community is governed by a [Code of Conduct](../CONDUCT.markdown) by which all community members must abide.
+Above all else, please review a pull request kindly. Our community can only be strong if we make it a welcoming and inclusive environment. To further promote this, the Jekyll community is governed by a [Code of Conduct](/docs/conduct) by which all community members must abide.
 
 Use emoji liberally :heart: :tada: :sparkles: :confetti_ball: and feel free to be emotive!! Contributions keep this project moving forward and we're always happy to receive them, even if the pull request isn't ultimately merged.
 

diff --git a/docs/_docs/maintaining/special-labels.md b/docs/_docs/maintaining/special-labels.md
@@ -18,4 +18,4 @@ These labels are used to indicate that the Git state of a pull request must chan
 
 ## `stale`
 
-This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](triaging-an-issue.md#staleness-and-automatic-closure).
+This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](../triaging-an-issue/#staleness-and-automatic-closure).
diff --git a/docs/_docs/plugins.md b/docs/_docs/plugins.md
@@ -771,7 +771,6 @@ LESS.js files during generation.
 - [Markdown References by Olov Lassus](https://github.com/olov/jekyll-references): Keep all your markdown reference-style link definitions in one \_references.md file.
 - [Stylus Converter](https://gist.github.com/988201): Convert .styl to .css.
 - [ReStructuredText Converter](https://github.com/xdissent/jekyll-rst): Converts ReST documents to HTML with Pygments syntax highlighting.
-- [Jekyll-pandoc-plugin](https://github.com/dsanson/jekyll-pandoc-plugin): Use pandoc for rendering markdown.
 - [Jekyll-pandoc-multiple-formats](https://github.com/fauno/jekyll-pandoc-multiple-formats) by [edsl](https://github.com/edsl): Use pandoc to generate your site in multiple formats. Supports pandoc’s markdown extensions.
 - [Transform Layouts](https://gist.github.com/1472645): Allows HAML layouts (you need a HAML Converter plugin for this to work).
 - [Org-mode Converter](https://gist.github.com/abhiyerra/7377603): Org-mode converter for Jekyll.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -28,4 +28,4 @@ Jekyll gets a lot of feature requests, non-reproducible bug reports, usage quest

		Thanks to https://gist.github.com/ryanflorence/124070e7c4b3839d4573 which influenced this document.

		Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
		Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/docs/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -18,4 +18,4 @@ These labels are used to indicate that the Git state of a pull request must chan

		## `stale`

		This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](triaging-an-issue.md#staleness-and-automatic-closure).
		This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](../triaging-an-issue/#staleness-and-automatic-closure).