Contribute to the docs site

You can also copy a version of the docs repo to your GitHub account and local machine. This gives you more flexibility in exchange for some upfront work. A typical contributor who works this way may edit in VS Code and make commits and file pull requests via GitHub Desktop.

This process has three broad phases:

1. You fork, or copy, the docs site repo to your GitHub account and local machine.

2. You sync your version of the docs repo with the real version of the docs repo. This is an important step. The Docs team will not receive your PRs if you do not sync your fork with our repo.

3. You submit a test PR to confirm you've completed these steps successfully.

   If you're choosing this method, we recommend that you install GitHub Desktop. This is a GUI that handles git commands for you so you don't need to open your CLI after set-up.

   Edit the site locally

   From the docs-website repo, click the Fork button. GitHub will prompt you to choose an owner, repo name, and description.

   

   

   Clone your copy to your local machine

   From your GitHub account profile, find your newly copied docs-website repo. Click the Code button and copy the HTTPS URL. Open your CLI.

   

   You need to choose where you want the docs site to live.

   • If you want your copy to live in your Documents folder, for example, then you'd run this command to ensure that your copied repo goes to your Documents folder: cd <YOUR_PATH_TO_FOLDER>.
   • Using the HTTPS URL you copied from the previous step, run this command: git clone <YOUR_PASTE_OF_HTTPS_URL>

   Connect your copy with the original docs repo

   If you tried to create a PR at this stage, you'd only be changing your version of the docs site — the Docs team wouldn't receive your PR. The following steps establish a connection between your fork and the original docs repo, a process called syncing upstream.

   1. Go to the docs-website repo and click the Code button. Copy the HTTPS URL just as you did in the previous step. Unlike the last step, however, you're copying the HTTPS URL of the docs repo, not your fork.

   2. From your CLI, change directory to the location of your cloned fork. For example, if you copied to your Documents folder, the command would read: cd <YOUR_PATH_TO_DOCUMENTS_FOLDER>/docs-website

   3. Run git remote -v

   4. Run git remote add upstream <HTTPS_URL_HERE>

   5. Run git remote -v to confirm you successfully added the upstream repo. You should see something like this, which is a different print from what you saw in step 3:

      git remote -v
        origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
        origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
        upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
        upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

      Copy

   Set up GitHub Desktop to create pull requests

   At this stage, we recommend you open up GitHub Desktop to edit the docs site rather than using git from your CLI. If you're a git wiz, then you can skip this step and file your first pull request.

   From GitHub Desktop, go to File, then click Add local repository. Use the finder to add your clone of the docs site. To create a test pull request:

   1. Create a new branch.

      

   2. Open the docs-website folder in VS Code or an editor of your choice. Make sure you're working on your new branch.

   3. Make an edit to any doc and save your changes. In GitHub Desktop, you should see your changes reflected in the Changes tab.

   4. In the Summary (required) field, describe your changes. If you're just making a test edit, you can write: Test pull request, do not merge. Click Commit.

   5. Follow the prompts in GitHub Desktop to file the pull request. GitHub will open in your browser. Make sure the base is set to develop.

      

   Congratulations! You're done. A good thing to keep in mind is to routinely Fetch origin from GitHub Desktop. This keeps your fork updated with the upstream repo.

   Now that you've successfully forked the repo, you have the option to collaborate with people on their existing branches. Check out our video tutorial for what this looks like:

You have a few different options for making a request to the team:

• If you're a New Relic employee, you can ping the @hero at our documentation help channel. Our hero is a dedicated interruptible person, who publishes doc edits and answers doc questions.

• You can submit a Jira request. From the right nav, click one of the buttons in the Was this doc helpful? element.

• You can file a GitHub issue from the docs site repo. In the top-most nav under the search box, click Issues, then New Issue.

  You can expect follow-up on your request based on this timeline:

  Type	SLA	Notes
  Small self-service edits	1 business day	A "smaller" edit is any edit that is a few sentences or less. The majority of self-service edits fall into this bucket.
  Larger self-service edits	3 business days	A larger edit is any edit that is a few sentences or more, or any edit that involves an all-new doc. When you submit a "larger" edit, the Docs Hero will create a docs Jira on your behalf, notify you with a link, and place that ticket at the top of our Jira board.
  Requests for Docs team to update docs	2+ weeks lead time for Tech Docs team	Our team works in one-week sprints. Time-sensitive requests should be made at least two weeks in advance for "ordinary" features (roughly, MMF-sized features), and at least six weeks in advance for "larger" features (roughly, milestone-sized projects).

  A good request includes a link to the doc(s) in question and a brief explanation about the nature of the problem. For example, letting us know if install procedures are out of date or unclear.