Merge branch 'master' into DU-4/Log_out

Gemfile.lock

@@ -100,7 +100,7 @@ GEM
       listen (~> 3.0)
     json (2.3.1)
     kramdown (1.17.0)
-    libv8 (3.16.14.19)
+    libv8 (3.16.14.19.1)
     liquid (4.0.3)
     listen (3.0.8)
       rb-fsevent (~> 0.9, >= 0.9.4)

README.md

@@ -1,73 +1,104 @@
-# About this repository [![Build Status](https://travis-ci.com/travis-ci/docs-travis-ci-com.svg?branch=master)](https://travis-ci.com/travis-ci/docs-travis-ci-com)
+# About Travis CI Repository [![Build Status](https://travis-ci.com/travis-ci/docs-travis-ci-com.svg?branch=master)](https://travis-ci.com/travis-ci/docs-travis-ci-com)
 
-This is the documentation site for Travis CI! (<https://docs.travis-ci.com/>)
+This is the documentation site for [Travis CI!](https://docs.travis-ci.com/).
+Follow this guide to learn how to add new documentation and how to update existing documentation. 
 
-## How to contribute
+## Add Documentation
 
-Fork the repository, read the rest of this README file and make some changes.
-Once you're done with your changes send a pull request. Thanks!
+The following are the steps to add documentation.
 
-## How to check your edit before sending PR
+1. Review the [Travis CI documentation guidelines](/STYLE.md).
+1. Check existing documentation. Verify that the documentation does not already exist or look for related documentation that can be enhanced. 
+1. Determine proper placement. In the [Travis CI repository](https://github.com/travis-ci/docs-travis-ci-com/tree/master), browse to the *user* folder (or any other specific folder) and create a new branch.
+1. Create a new file and add the new documentation files. 
+1. Ensure to insert the name and extension for the file.
+1. Commit your changes and add a short message to describe your changes.
+1. Test the changes locally to verify your edits. 
+1. Submit a pull request. Include a clear title and description of the proposed changes, and click “**Create pull request**.”  
 
-You can inspect how your edits will be reflected by the documentation site. Either by clicking on the Netlify preview link in your Pull Request or building the docs locally.
+Thank you for your contribution! The Travis CI team will review the pull request and approve any necessary changes.
 
-### Install dependencies
+## Update Existing Documentation
 
-1. Make sure you have Ruby and RubyGems installed.
+If you see a page that needs to be updated or that can be improved, follow these steps to update Travis CI's existing documentation. 
 
-1. Install [bundler](http://bundler.io/):
+1. Review the [Travis CI documentation guidelines](/STYLE.md).
+1. Identify the Travis CI docs page that needs to be updated. 
+1. Click the “**Improve this page on GitHub**” button in the top right corner.
+1. Once on GitHub, edit the relevant file.
+1. Commit your changes. Name your branch, and click the “**Propose changes**” button.
+1. Build the docs in a local environment to verify your edits. 
+1. Submit a pull request. Ensure a clear title and description of the proposed changes are added, and click “**Create pull request**.”
+
+Thank you for your contribution. The Travis CI team will review the pull request and approve any necessary changes.   
+
+
+## Build Local Environment
+
+You can inspect how the documentation site will reflect your edits. Follow the steps below to learn how to build your local environment and check all your edits before sending the pull request for approval. 
+
+### Install Dependencies
+
+Follow the steps below to install dependencies.
+
+1. Ensure you have *Ruby* and *RubyGems* installed.
+
+1. Clone the [Travis CI docs](https://github.com/travis-ci/docs-travis-ci-com/tree/master) repository.
+
+1. Install [bundler](http://bundler.io/) as follows:
 
     ```sh-session
     $ gem install bundler
     ```
 
-1. Install application dependencies:
+1. Next, install application dependencies:
 
     ```sh-session
     $ bundle install --binstubs
     ```
 
-### Generate documentation
+### Generate Documentation
 
-Run
+To generate the documentation, run the following command:
 
 ```sh-session
 $ ./bin/jekyll build
 ```
 
+### Run the Application Server
 
-### Run application server
-
-You are now ready to start your documentation site, using Jekyll or Puma.
+You are ready to start your local documentation site using Jekyll or Puma.
 For documentation edits, Jekyll is sufficient.
 
-#### Starting and inspecting edits with Jekyll
+#### Edit with Jekyll
+
+To start and inspect your edits using Jekyll, follow the steps below:
 
-1. Run Jekyll server:
+1. Run the *Jekyll* server:
 
     ```sh-session
     $ ./bin/jekyll serve
     ```
 
 1. Open [localhost:4000](http://localhost:4000/) in your browser.
 
-#### Starting and inspecting edits with Puma
+#### Edit with Puma
 
-For more programmatical PRs (such as handling webhooks notification
-via POST), Puma is necessary.
+For more programmatical pull requests (such as handling webhooks notifications
+via POST), Puma is necessary. To start and inspect your edits using Puma, follow the steps below:
 
-1. Run Puma server:
+1. Run the *Puma* server:
 
     ```sh-session
     $ ./bin/puma
     ```
 
 1. Open [localhost:9292](http://localhost:9292/) in your browser.
 
-### API V2 documentation
+### API  Documentation
 
-API V2 (and 2.1) documentation is maintained in `slate/source` and is generated at build time from source.
+All Travis CI API V2 (and 2.1) documentation is maintained in `slate/source` and generated from the source at build time.
 
 ## License
 
-Distributed under the [MIT license](https://opensource.org/licenses/MIT); the same as other Travis CI projects.
+Distributed under the [MIT license](https://opensource.org/licenses/MIT), like other Travis CI projects.

STYLE.md

@@ -1,6 +1,6 @@
-# Travis CI documentation style guide
+# Travis CI Documentation Style Guide
 
-## Markdown and structure
+## Markdown and Structure
 
 We're planning to lint the Markdown with [Coala.io][coala] and the [MarkdownBear][bear].
 
@@ -12,13 +12,13 @@ We'll be using a subset (TBD) of the full [list of checks][checks].
 
 [checks]: https://github.com/coala/bear-docs/blob/master/docs/MarkdownBear.rst#settings "MarkdownBear checks"
 
-We use Kramdown, with [GFM](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown) codeblocks, and a few Kramdown related exceptions introduced with `{: }` such as class names for specific formatting of columns and notes.
+We use Kramdown, with [GFM](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown) code blocks, and a few Kramdown-related exceptions introduced with `{: }` such as class names for specific formatting of columns and notes.
 
-### Headings
+## Headings
 
-For historical reasons, the top level heading in Jekyll markdown files is level 2 (##) not level 1 (#).
+For historical reasons, the top-level heading in Jekyll's markdown files is level 2 (##), not level 1 (#). Only the page’s title is a level 1 heading. 
 
-We use ATX style headings, and do not use the optional closing hashes:
+We use ATX-style headings and do not use the optional closing hashes:
 
 ```markdown
 ## This is an H2
@@ -28,38 +28,62 @@ We use ATX style headings, and do not use the optional closing hashes:
 #### This is an H4
 ```
 
-We do not use underline style headings:
+We do not use underlined style headings:
 
 ```markdown
 Do not use this style heading
 =============================
 ```
 
-### Lists
+## Lists
 
-If you have long lists you can wrap them into 2 (`.column-2`) or 3 (`.column-3`) columns using one of the follow CSS classes after your list item:
+If you have long lists, you can wrap them into 2 (`.column-2`) or 3 (`.column-3`) columns using one of the following CSS classes after your list item:
 
 ```css
 * long list item 1
 * long list item 2
 {: .column-2 }
 ```
 
-#### In-page table of contents
+## Links
 
-All pages have tables of contents generated automatically from H2 and H3
+Make sure all links have titles:
+
+```markdown
+The [link][example1] in the text
+
+[example1]: http://www.example.com  "Example URL"
+```
+
+or
+
+```markdown
+The [link](http://www.example.com "Example URL") in the text
+```
+
+When linking internal pages, use absolute paths and trailing slashes: `/user/languages/c/`.
+You can link to headings and remember to remove special characters, for example:
+
+To link to "##Node.js Page," use `#nodejs-page`.
+
+
+## In-page Options
 
-To remove the TOC from a page add `no_toc: true` to the frontmatter.
+### Notes, warnings, and blocks
 
-### Note, warnings and blocks
+Travis CI uses the blockquote symbol `>` for general-purpose notes and warnings.
 
-We use the blockquote symbol `>` for general purpose notes and warnings.
+See an example below:
 
-#### Beta features
+> Note: This feature is only available in Version 2.0.
+
+### Beta features
 
 Mark all beta features with a specially formatted note. Both the `> BETA` and
 the `{: .beta}` are required.
 
+See an example below:
+
 > BETA Awesome new feature that might not be enabled and is subject to change.
 {: .beta}
 
@@ -68,46 +92,25 @@ the `{: .beta}` are required.
 Mark all alpha features with a specially formatted note. Both the `> ALPHA` and
 the `{: alpha}` are required.
 
-> ALPHA Awesome new feature that might explode for extra fun.
+> ALPHA: Awesome new feature that might explode for extra fun.
 {: .alpha}
 
 ### GUI
 
-Make sure all references to items in a GUI match the case of the UI, and are marked with *asterisks*.
-
-### Links
-
-Make sure all links have titles:
-
-```markdown
-The [link][example1] in the text
-
-[example1]: http://www.example.com  "Example URL"
-```
-
-or
-
-```markdown
-The [link](http://www.example.com "Example URL") in the text
-```
-
-When linking internal pages, use absolute paths and trailing slashes: `/user/languages/c/`.
-You can link to headings, remember to remove special characters, for example:
-
-To link to "##Node.js Page" use `#nodejs-page`.
+Ensure all references to items in a GUI match the case of the UI and are marked with *asterisks*.
 
 
 ### Code Inline
 
-All function names, filenames, etc should be marked with `back-ticks`.
+All function names, filenames, etc., should be marked with `back-ticks`.
 
 If you're talking about applications or services, only the actual command should be marked as code, not the name of the service:
 
 - Start the PostgreSQL database by running `psql`.
 
 ### Blockquotes / Notes / Warnings
 
-As we have no use for blockquotes we use `>` to indicate notes and warnings:
+As we have no use for blockquotes, we use `>` to indicate notes and warnings:
 
 ```markdown
 > Note this important info!
@@ -131,16 +134,62 @@ This code is in .travis.yml
 ```
 {: data-file=".travis.yml"}
 
+### In-page table of contents
+
+All Travis CI pages have tables of contents generated automatically from H2 and H3
 
+Add `no_toc: true` to the frontmatter to remove the TOC from a page.
 
-### Common misspellings and words to avoid
+### Terminology
+The following are some common misspellings and words to avoid
 
 - Always refer to *Travis CI* and never to Travis.
 
 ## Images
 
+Add images inline-style with a brief description.
+
+To add an image, follow these steps:
+1 Capture the image.
+2 Save the image in the  `images/` path.
+3 Add the image to the documentation as follows:
+![description text](image path or URL) 
+
 ### Screencapture gifs
 
 1. Run a build (or whatever you are trying to capture),
 2. Capture it with [licecap](https://www.cockos.com/licecap/).
-3. Save the gif in `images/`
+3. Save the gif in the following path:  `images/`  
+
+
+## Documentation Template
+
+A basic template for contributing to new documentation pages or sections is as follows: 
+
+```markdown
+---
+title: “Insert Page Title”
+layout: en
+
+---
+
+Start your introduction here. Usually, an introduction is between one and three sentences. 
+
+## Section Heading 
+
+Section introduction sentence. 
+
+* **Item1** - a group of *jobs* that run in sequence. 
+* **Item2** - a group of *jobs* that run in parallel as part of a sequential *build* process composed of multiple [stages](/user/build-stages/).
+* **Item3** - an automated process that clones your repository into a virtual
+  environment and then carries out a series of *phases* such as compiling your
+  code, running tests, etc. 
+* **Item4** - the [sequential steps](/user/job-lifecycle/)
+  of a *job*. 
+
+```
+{: data-file=".travis.yml"}
+
+The example above shows a paragraph with different formatting options. 
+
+Check out the [Travis CI documentation](https://docs.travis-ci.com/) for more examples.

_includes/deploy/opt_in.md

@@ -1,12 +1,30 @@
-## How to opt in to v2
+## How to opt in to different deployment tooling versions
 
-In order to use version `v2` of our deployment tooling, please add the
+In order to use different version of our deployment tooling, please add the
 following to your `.travis.yml`:
 
 ```yaml
 deploy:
   provider: <provider>
   # ⋮
+  dpl_version: <version> # Optional, defaults to the latest stable version
+```
+if you want to use the latest edge version of the deployment tooling:
+
+```yaml
+deploy:
+  provider: <provider>
+  # ⋮
+  edge: true
+```
+if you want to use other edge version of the deployment tooling:
+
+```yaml
+deploy:
+  provider: <provider>
+  # ⋮
+  dpl_version: <version.beta>
   edge: true
 ```
+
 {: data-file=".travis.yml"}

_includes/deploy/providers/anynines.md

@@ -43,4 +43,4 @@ All options can be given as environment variables if prefixed with `ANYNINES_`.
 
 For example, `password` can be given as `ANYNINES_PASSWORD=<password>`.
 
-{% include deploy/secrets.md name="password" env_name="ANYNINES_PASSWORD" %}
+{% include deploy/secrets.md name="password" env_name="ANYNINES_PASSWORD" %}