Deprecate contributing directory (#45581)

Co-authored-by: Kevin Heis <[email protected]>

.github/CONTRIBUTING.md

@@ -20,7 +20,7 @@ To get an overview of the project, read the [README](README.md) file. Here are s
 
 ## Getting started
 
-To navigate our codebase with confidence, see [the introduction to working in the docs repository](/contributing/working-in-docs-repository.md) :confetti_ball:. For more information on how we write our markdown files, see [the GitHub Markdown reference](contributing/content-markup-reference.md).
+To navigate our codebase with confidence, see [the introduction to working in the docs repository](/contributing/README.md) :confetti_ball:. For more information on how we write our markdown files, see "[Using Makrdown and Liquid in GitHub Docs](https://docs.github.com/en/contributing/writing-for-github-docs/using-markdown-and-liquid-in-github-docs).
 
 Check to see what [types of contributions](/contributing/types-of-contributions.md) we accept before making changes. Some of them don't even require writing a single line of code :sparkles:.
 
@@ -32,7 +32,7 @@ If you spot a problem with the docs, [search if an issue already exists](https:/
 
 #### Solve an issue
 
-Scan through our [existing issues](https://github.com/github/docs/issues) to find one that interests you. You can narrow down the search using `labels` as filters. See [Labels](/contributing/how-to-use-labels.md) for more information. As a general rule, we don’t assign issues to anyone. If you find an issue to work on, you are welcome to open a PR with a fix.
+Scan through our [existing issues](https://github.com/github/docs/issues) to find one that interests you. You can narrow down the search using `labels` as filters. See "[Label reference](https://docs.github.com/en/contributing/collaborating-on-github-docs/label-reference)" for more information. As a general rule, we don’t assign issues to anyone. If you find an issue to work on, you are welcome to open a PR with a fix.
 
 ### Make Changes
 
@@ -62,7 +62,7 @@ For more information about using a codespace for working on GitHub documentation
 
 ### Commit your update
 
-Commit the changes once you are happy with them. Don't forget to [self-review](/contributing/self-review.md) to speed up the review process:zap:.
+Commit the changes once you are happy with them. Don't forget to use the "[Self review checklist](https://docs.github.com/en/contributing/collaborating-on-github-docs/self-review-checklist) to speed up the review process :zap:.
 
 ### Pull Request
 

.github/ISSUE_TEMPLATE/partner-contributed-documentation.yml

@@ -39,7 +39,7 @@ body:
           required: true
         - label: MUST emphasize how the third-party product works with GitHub.
           required: true
-        - label: MUST be written in Markdown format, using [one of the templates provided](contributing/github-partners/README.md#templates).
+        - label: MUST be written in Markdown format, using [one of the templates provided](https://docs.github.com/en/contributing/writing-for-github-docs/templates).
           required: true
         - label: MUST include the name and URL of the GitHub technology partner responsible for maintenance of the documentation being contributed. This should be added via the `contributor.name` and `contributor.URL` properties in the template's YAML frontmatter.
           required: true

content/README.md

@@ -293,9 +293,9 @@ Do not add hardcoded "In this article" sections in the Markdown source or else t
 A content file can have **two** types of versioning:
 
 - [`versions`](#versions) frontmatter (**required**)
-    - Determines in which versions the page is available. See [contributing/permalinks](../contributing/permalinks.md) for more info.
+    - Determines in which versions the page is available. See "[Versioning documentation](https://docs.github.com/en/contributing/writing-for-github-docs/versioning-documentation) for more info.
 - Liquid statements in content (**optional**)
-    - Conditionally render content depending on the current version being viewed. See [contributing/liquid-helpers](../contributing/liquid-helpers.md) for more info. Note Liquid conditionals can also appear in `data` and `include` files.
+    - Conditionally render content depending on the current version being viewed. See "[Versioning documentation](https://docs.github.com/en/contributing/writing-for-github-docs/versioning-documentation#versioning-with-liquid-conditional-operators)" for more info. Note Liquid conditionals can also appear in `data` and `include` files.
 
 **Note**: As of early 2021, the `free-pro-team@latest` version is not included URLs. A helper function called `lib/remove-fpt-from-path.js` removes the version from URLs.
 

contributing/README.md

@@ -2,20 +2,18 @@
 
 Check out our [contributing guide](../CONTRIBUTING.md) to see all the ways you can participate in the GitHub docs community :sparkling_heart:
 
+Visit "[Contributing to GitHub Docs documentation](https://docs.github.com/en/contributing)" for additional information about how to write and collaborate the GitHub Docs way.
+
 Here, you'll find additional information that might be helpful as you work on a pull request in this repo.
 
 - [development](./development.md) - steps for getting this app running on your local machine
-- [codespace](./codespace.md) - use GitHub Codespaces to work on documentation markdown files
-- [content markup reference](./content-markup-reference.md) - how to use markup and features specific to the GitHub Docs site 
-- [content style guide](./content-style-guide.md) - style guidance specific to GitHub Docs content and additional resources for writing clear, helpful content
-- [content model](./content-model.md) - the content types that make up GitHub Docs and how to write them
-- [content templates](./content-templates.md) - handy templates to get you started with a new article
 - [deployments](./deployments.md) - how our staging and production environments work
 - [liquid helpers](./liquid-helpers.md) - using liquid helpers for versioning in our docs
 - [translations guide for writers](./translations-for-writers.md) - making sure your content is ready to be translated
 - [node versions](./node-versions.md) - our site runs on Node.js
-- [permalinks](./permalinks.md) - permalinks for article versioning
-- [redirects](./redirects.md) - configuring redirects in the site
 - [troubleshooting](./troubleshooting.md) - some help for troubleshooting failed and stalled status checks
+- [Reusables](https://docs.github.com/en/contributing/writing-for-github-docs/creating-reusable-content#about-reusables) - We create reusables and call them from articles to help us keep content that is used in multiple places up to date.
+- [Variables](https://docs.github.com/en/contributing/writing-for-github-docs/creating-reusable-content#about-variables) - We use variables the same way we use reusables. Variables are for short strings of reusable text.
+- [Tests](/tests/README.md) - We use tests to ensure content will render correctly on the site. Tests run automatically in your PR, and sometimes it's also helpful to run them locally.
 
 You can also read the READMEs in the `src/` directory to learn more about the features of the docs site.

contributing/code-annotations.md

@@ -1,79 +1 @@
-# Code annotations
-
-Code annotations help explain longer code examples by describing what a code example does and why. The annotations render next to the code samples in a two pane layout, so we can write longer annotations without making the code itself difficult to read. We only annotate full code examples, not snippets. Code annotations should add value when used and are not required for every code sample.
-
-Code annotations can be helpful for a variety of audiences. Often, code annotations will be used to explain key concepts to new users or specific choices to more experienced users.
-
-For new users, code annotations are a way to go beyond the high level overview of a code example and explain what each line of code does so that someone can understand the code as if a friend or coworker were guiding them through it.
-
-For more experienced users, code annotations can help them understand a code example and then tailor it to their specific needs. Annotations can explain why code was written a certain way so that the fundamentals are clear.
-
-You can annotate multiple code examples in a single article, but keep in mind that each annotation increases the complexity of an article and adds repetitive navigation tasks for people using screen readers. If you have multiple code examples in an article, consider whether they can be combined into a single example.
-
-## Enabling and adding code annotations
-
-1. Specify the `layout: inline` frontmatter property for the article.
-1. Create a code example using triple backticks.
-1. Specify a language for the code example after the triple backtick, followed by `annotate`. For example, ` ```yaml annotate` or ` ```ruby annotate`.
-1. Add annotations using comment tags (`#`, `//`, `<!--`, `%%`) within the code example. Annotations apply from the line below the comment to the next comment tag or the end of the code block.
-
-An annotated code example must start with a single line annotation. You can start with a blank annotation if you do not want to add an annotation to the first line of code.
-
-You must use the comment tag for the language that the code sample is written in. For example, `#` for YAML and `//` for JavaScript.
-
-To enable code sample annotations, you must specify a language followed by the word `annotate` after the starting triple backtick code tag.
-
-Within code sample annotations:
-- Annotations use single-line comment style and must start with a comment tag that matches the code language: `#`, `//`, `<!--`, `%%`.
-- Annotations apply to the code from the line below the comment tag to the next comment tag or the end of the code block.
-- Multiline-style comments, such as `/*` are not supported.
-- You can include any number of spaces before the comment tag starts.
-- You can include any number of spaces after the comment tag ends.
-- To create a blank annotation, insert a comment tag with no text after it.
-- Anything after the comment tag will be parsed with Markdown. Links, versioning, and other styling will render as if they were written in Markdown.
-- Multiple sequential comments will create a single annotation.
-- Lines that do not start with a comment tag and are empty or only contain spaces will be ignored.
-- You must start the code section with a single line comment. If the first line (or section) of the code does not need an annotation, you can use a comment tag with no text to create a blank annotation.
-- For HTML style, you should include a closing tag, `<!-- -->`, after your annotations to maintain syntax highlighting.
-
-## Writing code annotations
-
-Introduce the overall purpose of a code example with an introduction before the code block and use annotations to explain what specific lines of code do and why they do it.
-
-Prioritize clarity in code annotations while trying to keep them as short as possible. People use code samples as a foundation for their own work, so annotations should help people understand the sample as it is written and how they might adapt the sample for other uses.
-
-Consider your audience when writing code annotations and do not assume people will know why an example is written a certain way.
-
-Annotations can be used to show the expected outcomes for the code that they annotate, but the results for the entire code example should be in the introduction for the code example or discussed after the example, whichever way best serves the audience.
-
-If a code example is changed, check that all annotations are still valid.
-
-## Example of an annotated code example
-
-    The following code example shows a workflow that posts a welcome comment on a pull request when it is opened.
-
-    ```yaml annotate
-    # The name of the workflow as it will appear in the "Actions" tab of the GitHub repository.
-    name: Post welcome comment
-    # The `on` keyword lets you define the events that trigger when the workflow is run.
-    on:
-      # Add the `pull_request` event, so that the workflow runs automatically
-      # every time a pull request is created.
-      pull_request:
-        types: [opened]
-    # Modifies the default permissions granted to `GITHUB_TOKEN`.
-    permissions:
-      pull-requests: write
-    # Defines a job with the ID `build` that is stored within the `jobs` key.
-    jobs:
-      build:
-        name: Post welcome comment
-        # Configures the operating system the job runs on.
-        runs-on: ubuntu-latest
-        # The `run` keyword tells the job to execute a command on the runner.
-        steps:
-          - run: gh pr comment $PR_URL --body "Welcome to the repository!"
-            env:
-              GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-              PR_URL: ${{ github.event.pull_request.html_url }}
-    ```
+The content in the `contributing` directory has been deprecated. See "[Annotating code examples](https://docs.github.com/en/contributing/writing-for-github-docs/annotating-code-examples)" in the GitHub Docs for the maintained version of this article.

contributing/codespace.md

@@ -1,34 +1 @@
-# Working in a codespace
-
-This document describes how to use GitHub Codespaces for working on articles for docs.github.com.
-
-## About GitHub Codespaces 
-
-GitHub Codespaces allows you to work in a development environment that's hosted remotely from your machine. You can get started very quickly, with no need to set up the working environment, and without having to download files to your local computer.
-
-**Note**: GitHub Codespaces is currently only available if you are a member of an organization using GitHub Team or GitHub Enterprise Cloud. 
-
-For more information, see "[GitHub Codespaces overview](https://docs.github.com/en/codespaces/overview)."
-
-## Work on documentation in a codespace
-
-The steps described below assume you have GitHub Codespaces set up to edit files using Visual Studio Code for Web. The steps are very similar if you have configured a different editor. For more information, see "[Setting your default editor for GitHub Codespaces](https://docs.github.com/en/codespaces/customizing-your-codespace/setting-your-default-editor-for-codespaces)."
-
-1. Go to the `docs` repository: [https://github.com/github/docs](https://github.com/github/docs).
-1. If you're an open source contributor: [fork the repository](https://docs.github.com/en/get-started/quickstart/fork-a-repo) to your own organization.
-1. [Create a branch to work on](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository).
-1. On the main page of the new `docs` repository, click the **Code** button and click **Create codespace on BRANCHNAME**.<br>
-   The "Setting up your codespace" page is displayed. After a short time the browser-based version of Visual Studio Code is displayed.
-1. Use the Explorer to navigate to the markdown file you want to edit. This will be located below the `content` directory. <br>
-   In most cases, the path to the file, below the `content` directory, matches the path in URL, minus the `.md` file name extension. For example, the source for the article <code>https<span></span>://docs.github.com/en/**codespaces/getting-started/quickstart**</code> is the markdown file <code>content/**codespaces/getting-started/quickstart**.md</code>.
-1. Edit the markdown file as required.
-1. Save your changes.
-1. Commit and push your changes, either using the "Source Control" view, or using Git commands from the Terminal. For more information, see "[About Git](https://docs.github.com/en/get-started/using-git/about-git)."
-1. Go to the **Pull requests** tab of the `github/docs` repository: https://github.com/github/docs/pulls
-1. Click **New pull request**.
-1. If you're an open source contributor: click **compare across forks** and choose the forked repository you created, and your working branch.<br>
-   Otherwise: change the "compare" branch to your working branch.
-1. Check that the changes displayed include all of the changes you made in the codespace. If they do not, it indicates there are changes you have not pushed from the codespace to GitHub.
-1. Click **Create pull request**.
-1. Fill out the details for your pull request and click **Create pull request**.<br>
-   Your pull request will be reviewed by a member of the GitHub documentation team.
+The content in the `contributing` directory has been deprecated. See "[Working on a GitHub Docs in a codepsace](https://docs.github.com/en/contributing/setting-up-your-environment-to-work-on-github-docs/working-on-github-docs-in-a-codespace)" in the GitHub Docs for the maintained version of this article.