Docs: more inclusive writing (#7283)

Merge pull request 7283

.github/CONTRIBUTING.markdown

@@ -25,7 +25,7 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
 
 * The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
 
-* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
+* If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
 
 * If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
 

History.markdown

@@ -1545,7 +1545,7 @@
   * Internal: trigger hooks by owner symbol (#3871)
   * Update MIME types from mime-db (#3933)
   * Add header to site template `_config.yml` for clarity & direction (#3997)
-  * Site template: add timezone offset to post date frontmatter (#4001)
+  * Site template: add timezone offset to post date front matter (#4001)
   * Make a constant for the regex to find hidden files (#4032)
   * Site template: refactor github & twitter icons into includes (#4049)
   * Site template: add background to Kramdown Rouge-ified backtick code blocks (#4053)
@@ -1685,7 +1685,7 @@
   * Add a link on all the docs pages to "Improve this page". (#3510)
   * Add jekyll-auto-image generator to the list of third-party plugins (#3489)
   * Replace link to the proposed `picture` element spec (#3530)
-  * Add frontmatter date formatting information (#3469)
+  * Add front matter date formatting information (#3469)
   * Improve consistency and clarity of plugins options note (#3546)
   * Add permalink warning to pagination docs (#3551)
   * Fix grammar in Collections docs API stability warning (#3560)

docs/_docs/code_of_conduct.md

@@ -6,50 +6,47 @@ redirect_from: "/conduct/index.html"
 editable: false
 ---
 
-As contributors and maintainers of this project, and in the interest of
-fostering an open and welcoming community, we pledge to respect all people who
-contribute through reporting issues, posting feature requests, updating
-documentation, submitting pull requests or patches, and other activities.
+## Our Pledge
 
-We are committed to making participation in this project a harassment-free
-experience for everyone, regardless of level of experience, gender, gender
-identity and expression, sexual orientation, disability, personal appearance,
-body size, race, ethnicity, age, religion, or nationality.
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery
-* Personal attacks
-* Trolling or insulting/derogatory comments
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing other's private information, such as physical or electronic
-  addresses, without explicit permission
-* Other unethical or unprofessional conduct
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
 
-By adopting this Code of Conduct, project maintainers commit themselves to
-fairly and consistently applying these principles to every aspect of managing
-this project. Project maintainers who do not follow or enforce the Code of
-Conduct may be permanently removed from the project team.
+## Enforcement
 
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting a project maintainer. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by opening an issue or contacting a project maintainer. All complaints
-will be reviewed and investigated and will result in a response that is deemed
-necessary and appropriate to the circumstances. Maintainers are obligated to
-maintain confidentiality with regard to the reporter of an incident.
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
 
+## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 1.3.0, available at
-[http://contributor-covenant.org/version/1/3/0/][version]
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html][version]
 
-[homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/3/0/
+[homepage]: https://www.contributor-covenant.org/
+[version]: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

docs/_docs/collections.md

@@ -209,7 +209,7 @@ you specified in your `_config.yml` (if present) and the following information:
   <p>Except for documents in hard-coded default collection <code>posts</code>, all documents in collections
     you create, are accessible via Liquid irrespective of their assigned date, if any, and therefore renderable.
   </p>
-  <p>However documents are attempted to be written to disk only if the concerned collection
+  <p>Documents are attempted to be written to disk only if the concerned collection
     metadata has <code>output: true</code>. Additionally, future-dated documents are only written if
     <code>site.future</code> <em>is also true</em>.
   </p>

docs/_docs/configuration/front-matter-defaults.md

@@ -117,7 +117,7 @@ defaults:
 
 ### Precedence
 
-Jekyll will apply all of the configuration settings you specify in the `defaults` section of your `_config.yml` file. However, you can choose to override settings from other scope/values pair by specifying a more specific path for the scope.
+Jekyll will apply all of the configuration settings you specify in the `defaults` section of your `_config.yml` file. You can choose to override settings from other scope/values pair by specifying a more specific path for the scope.
 
 You can see that in the second to last example above. First, we set the default page layout to `my-site`. Then, using a more specific path, we set the default layout for pages in the `projects/` path to `project`. This can be done with any value that you would set in the page or post front matter.
 

docs/_docs/continuous-integration/circleci.md

@@ -38,7 +38,7 @@ CircleCI detects when `Gemfile` is present is will automatically run `bundle ins
 
 ## 3. Testing
 
-The most basic test that can be run is simply seeing if `jekyll build` actually works. This is a blocker, a dependency if you will, for other tests you might run on the generate site. So we'll run Jekyll, via Bundler, in the `dependencies` phase.
+The most basic test that can be run is seeing if `jekyll build` actually works. This is a blocker, a dependency if you will, for other tests you might run on the generate site. So we'll run Jekyll, via Bundler, in the `dependencies` phase.
 
 ```yaml
 dependencies:

docs/_docs/continuous-integration/travis-ci.md

@@ -2,7 +2,7 @@
 title: "Travis CI"
 ---
 
-You can easily test your website build against one or more versions of Ruby.
+You can test your website build against one or more versions of Ruby.
 The following guide will show you how to set up a free build environment on
 [Travis][travis], with [GitHub][github] integration for pull requests.
 
@@ -11,7 +11,7 @@ The following guide will show you how to set up a free build environment on
 
 ## 1. Enabling Travis and GitHub
 
-Enabling Travis builds for your GitHub repository is pretty simple:
+To enable Travis builds for your GitHub repository:
 
 1. Go to your profile on travis-ci.org: https://travis-ci.org/profile/username
 2. Find the repository for which you're interested in enabling builds.
@@ -21,7 +21,7 @@ Enabling Travis builds for your GitHub repository is pretty simple:
 
 ## 2. The Test Script
 
-The simplest test script simply runs `jekyll build` and ensures that Jekyll
+The simplest test script runs `jekyll build` and ensures that Jekyll
 doesn't fail to build the site. It doesn't check the resulting site, but it
 does ensure things are built properly.
 
@@ -222,7 +222,7 @@ does need `sudo` access, modify the line to `sudo: required`.
 sudo: false
 ```
 
-To speed up the build, you should cache the gem packages created by `bundler`. 
+To speed up the build, you should cache the gem packages created by `bundler`.
 Travis has a pre-defined [cache strategy for this tool][6] which should have
 all the default configs to do exactly that.
 

docs/_docs/contributing.md

@@ -29,7 +29,7 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
 
 * The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
 
-* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
+* If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
 
 * If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
 

docs/_docs/deployment/manual.md

@@ -7,24 +7,12 @@ Jekyll generates your static site to the `_site` directory by default. You can
 transfer the contents of this directory to almost any hosting provider to get
 your site live. Here are some manual ways of achieving this:
 
-## FTP
-
-Most traditional web hosting provider let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, simply run the `jekyll build` command and copy the contents of the generated `_site` folder to the root folder of your hosting account. This is most likely to be the `httpdocs` or `public_html` folder on most hosting providers.
-
-## scp
-
-If you have direct access to the deployment web server, the process is essentially the same, except you might have other methods available to you (such as `scp`, or even direct filesystem access) for transferring the files. Just remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
-
 ## rsync
 
 Rsync is similar to scp except it can be faster as it will only send changed
 parts of files as opposed to the entire file. You can learn more about using
 rsync in the [Digital Ocean tutorial](https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories-on-a-vps).
 
-## Rack-Jekyll
-
-[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) is an easy way to deploy your site on any Rack server such as Amazon EC2, Slicehost, Heroku, and so forth. It also can run with [shotgun](https://github.com/rtomayko/shotgun/), [rackup](https://github.com/rack/rack), [mongrel](https://github.com/mongrel/mongrel), [unicorn](https://github.com/defunkt/unicorn/), and [others](https://github.com/adaoraul/rack-jekyll#readme).
-
 ## Amazon S3
 
 If you want to host your site in Amazon S3, you can do so by
@@ -34,3 +22,16 @@ any web server,
 dynamically scaling to almost unlimited traffic. This approach has the
 benefit of being about the cheapest hosting option available for
 low-volume blogs as you only pay for what you use.
+
+## FTP
+
+Most traditional web hosting provider let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, run the `jekyll build` command and copy the contents of the generated `_site` folder to the root folder of your hosting account. This is most likely to be the `httpdocs` or `public_html` folder on most hosting providers.
+
+## scp
+
+If you have direct access to the deployment web server, the process is essentially the same, except you might have other methods available to you (such as `scp`, or even direct filesystem access) for transferring the files. Remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
+
+
+## Rack-Jekyll
+
+[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) allows you to deploy your site on any Rack server such as Amazon EC2, Slicehost, Heroku, and so forth. It also can run with [shotgun](https://github.com/rtomayko/shotgun/), [rackup](https://github.com/rack/rack), [mongrel](https://github.com/mongrel/mongrel), [unicorn](https://github.com/defunkt/unicorn/), and [others](https://github.com/adaoraul/rack-jekyll#readme).

docs/_docs/deployment/third-party.md

@@ -21,11 +21,11 @@ Sites on GitHub Pages are powered by Jekyll behind the scenes, so if you’re lo
 
 ## Kickster
 
-Use [Kickster](http://kickster.nielsenramon.com/) for easy (automated) deploys to GitHub Pages when using unsupported plugins on GitHub Pages.
+Use [Kickster](http://kickster.nielsenramon.com/) for automated deploys to GitHub Pages when using unsupported plugins on GitHub Pages.
 
 Kickster provides a basic Jekyll project setup packed with web best practises and useful optimization tools increasing your overall project quality. Kickster ships with automated and worry-free deployment scripts for GitHub Pages.
 
-Setting up Kickster is very easy, just install the gem and you are good to go. More documentation can here found [here](https://github.com/nielsenramon/kickster#kickster). If you do not want to use the gem or start a new project you can just copy paste the deployment scripts for [Travis CI](https://github.com/nielsenramon/kickster/tree/master/snippets/travis) or [Circle CI](https://github.com/nielsenramon/kickster#automated-deployment-with-circle-ci).
+Install the Kickster gem and you are good to go. More documentation can here found [here](https://github.com/nielsenramon/kickster#kickster). If you do not want to use the gem or start a new project you can just copy paste the deployment scripts for [Travis CI](https://github.com/nielsenramon/kickster/tree/master/snippets/travis) or [Circle CI](https://github.com/nielsenramon/kickster#automated-deployment-with-circle-ci).
 
 
 ## Netlify

docs/_docs/front-matter.md

@@ -71,14 +71,14 @@ front matter of a page or post.
         <ul>
           <li>
             Using <code>null</code> will produce a file without using a layout
-            file. However this is overridden if the file is a post/document and has a
+            file. This is overridden if the file is a post/document and has a
             layout defined in the <a href="/docs/configuration/front-matter-defaults/">
             front matter defaults</a>.
           </li>
           <li>
             Starting from version 3.5.0, using <code>none</code> in a post/document will
             produce a file without using a layout file regardless of front matter defaults.
-            Using <code>none</code> in a page, however, will cause Jekyll to attempt to
+            Using <code>none</code> in a page will cause Jekyll to attempt to
             use a layout named "none".
           </li>
         </ul>
@@ -116,7 +116,7 @@ front matter of a page or post.
 <div class="note">
   <h5>ProTip™: Render Posts Marked As Unpublished</h5>
   <p>
-    To preview unpublished pages, simply run `jekyll serve` or `jekyll build`
+    To preview unpublished pages, run `jekyll serve` or `jekyll build`
     with the `--unpublished` switch. Jekyll also has a handy <a href="/docs/posts/#drafts">drafts</a>
     feature tailored specifically for blog posts.
   </p>
@@ -204,7 +204,7 @@ These are available out-of-the-box to be used in the front matter for a post.
   <h5>ProTip™: Don't repeat yourself</h5>
   <p>
     If you don't want to repeat your frequently used front matter variables
-    over and over, just define <a href="/docs/configuration/front-matter-defaults/" title="Front Matter defaults">defaults</a>
+    over and over, define <a href="/docs/configuration/front-matter-defaults/" title="Front Matter defaults">defaults</a>
     for them and only override them where necessary (or not at all). This works
     both for predefined and custom variables.
   </p>

docs/_docs/github-pages.md

@@ -56,7 +56,7 @@ Be sure to run `bundle update` often.
 ### Project Page URL Structure
 
 Sometimes it's nice to preview your Jekyll site before you push your `gh-pages`
-branch to GitHub. However, the subdirectory-like URL structure GitHub uses for
+branch to GitHub. The subdirectory-like URL structure GitHub uses for
 Project Pages complicates the proper resolution of URLs. In order to assure your
 site builds properly, use the handy [URL filters](/docs/liquid/filters/):
 

docs/_docs/history.md

@@ -4,6 +4,15 @@ permalink: "/docs/history/"
 note: This file is autogenerated. Edit /History.markdown instead.
 ---
 
+## 3.8.4 / 2018-09-18
+{: #v3-8-4}
+
+### Bug Fixes
+{: #bug-fixes-v3-8-4}
+
+- 3.8.x: security: fix `include` bypass of `EntryFilter#filter` symlink check ([#7228]({{ site.repository }}/issues/7228))
+
+
 ## 3.8.3 / 2018-06-05
 {: #v3-8-3}
 
@@ -137,6 +146,15 @@ note: This file is autogenerated. Edit /History.markdown instead.
 - Allow front matter defaults to be applied properly to documents gathered under custom `collections_dir` ([#6885]({{ site.repository }}/issues/6885))
 
 
+## 3.7.4 / 2018-09-07
+{: #v3-7-4}
+
+### Bug Fixes
+{: #bug-fixes-v3-7-4}
+
+- Security: fix `include` bypass of EntryFilter#filter symlink check ([#7224]({{ site.repository }}/issues/7224))
+
+
 ## 3.7.3 / 2018-02-25
 {: #v3-7-3}
 
@@ -318,6 +336,15 @@ note: This file is autogenerated. Edit /History.markdown instead.
 - Fix permalink icon markup in news-item layout ([#6639]({{ site.repository }}/issues/6639))
 
 
+## 3.6.3 / 2018-09-18
+{: #v3-6-3}
+
+### Bug Fixes
+{: #bug-fixes-v3-6-3}
+
+- 3.6.x: security: fix `include` bypass of `EntryFilter#filter` symlink check ([#7229]({{ site.repository }}/issues/7229))
+
+
 ## 3.6.2 / 2017-10-21
 {: #v3-6-2}