| # | +Phase | +Your goals | +Definition of done | +
|---|---|---|---|
| 1 | +Join the community | +
|
+ Consider this phase complete when you join a working group. | +
| 2 | +Adopt a template | +
|
+ Consider this phase complete when you assign yourself to the issue tracking your template or tactic project. | +
| 3 | +Research the template (Research phase) |
+
|
+ Consider this phase complete when you have finished a draft of your Resources document. | +
| 4 | +Draft the template deliverables (Drafting phase) |
+
|
+ This phase completes when you schedule your drafts for review by other members of your working group or community. | +
| 5 | +Get feedback on drafts from the community (Community review phase) |
+
|
+ This phase completes after you incorporate the feedback into your draft and your drafts are ready for a deeper expert review. Ensure you have permission from the working group lead to move to the editorial review phase. | +
| 6 | +Get a review from the template editorial team (Editorial team review phase) |
+
|
+ This phase completes after you incorporate the feedback into your draft and your drafts are in a final state. Ensure you have permission from the working group lead to move to the final review phase. | +
| 7 | +Submit a merge request (Final review phase) |
+
|
+ This phase completes when the template merges into the repository. | +
| 8 | +Hand off to the Chronologue team for user testing (Chronologue phase) |
+
|
+ The Chronologue team considers this phase complete when they create an example for the template. | +
| Priority | +Description | +
|---|---|
| Critical | +
|
+
| High | +
|
+
| Medium | +
|
+
| Low | +
|
+
| File | +Example filename and purpose | +
|---|---|
| Template file | +template_content-type.md The template file is the raw template for the content type. It provides a rough outline of the suggested content and a few embedded writing tips for how to fill in the different sections of the template. |
+
| Template guide | +guide_content-type.md This guide provides a deeper explanation of how to fill in the template. It provides a lightweight introduction to the purpose of this documentation and explains how to fill in each section of the document. |
+
| Resources | +resources_content-type.md This document includes the resources (books, blog entries, guides) that the template author(s) used during the research phase of creating the template. It also includes any high-quality examples of that content type that served as inspiration for the template. |
+
| Process | +process_content-type.md This document explains best practices for researching, writing, and maintaining this content type. |
+
| Example | +example_content-type.md See an example of the template in action in our model documentation project: The Chronologue. |
+
| Template | +Description | +
|---|---|
| Concept | +An explanation of a concept, context, or background information about a product or its features. | +
| How-to | +A concise set of numbered steps to do one task with the product. | +
| README | +Information users need to know about your project, including how users can engage with the project and get started with the tool. | +
| Reference | +Descriptions of specific components or characteristics of an application. | +
| Release notes | +Communicate new features, improvements, bug fixes, and known issues about a product to users and stakeholders. | +
| Tutorial | +Instructions for setting up an example project using the product, intended for the purpose of hands-on learning. | +
| Troubleshooting | +A list of common problems (referred to as "symptoms") experienced by users, an explanation of the causes, and steps to resolve the issue. | +
| Template | +Description | +
|---|---|
| Bug report | +The bug report is an issue template that your users can fill out to provide you with higher-quality, actionable bug issues for your product. | +
| Changelog | +Changelogs document significant product changes in reverse-chronological order. This template offers a more technical, comprehensive alternative to standard release notes. | +
| Code of Conduct | +A Code of Conduct helps you govern your open source or developer community to ensure it remains healthy and open. | +
| Code of Conduct response plan | +Used as part of the Code of Conduct process, the response plan explains the policy your team will follow as you handle Code of Conduct incidents. | +
| Code of Conduct incident record | +Used as part of the Code of Conduct process, an incident record is a form that is filled out when a community moderator takes an incident report from a community member. | +
| Code of Conduct remediation record | +Used as part of the Code of Conduct process, a remediation record is a form that is filled out when a community moderator meets with a community member to explain the consequences of a Code of Conduct violation. | +
| Contributing guide | +A CONTRIBUTING document tells users how they can contribute to your open source project and join the community. | +
| Our team | +Helps you clearly communicate who belongs to your open source project or organization and how contributors can contact or work with them. | +
| README | +Information users need to know about your project, including how users can engage with the project and get started with the tool. | +
| Template | +Description | +
|---|---|
| API getting started | +API getting started guides help new users with the process of creating a minimum working example with your API. | +
| API reference | +API references are technical manuals that provide API specifications and integration instructions to help your audience understand the service. | +
| Contact support | +A contact support page typically includes a list of the communication channels, discussion forums, and links to other resources to assist users with issues that they are having with your product. | +
| Glossary | +A reference document that lists and organizes terms and their definitions that are unique to your organization or which you use in a specific way. | +
| Installation guide | +Explain all the necessary steps to install the product and set it up for further use. | +
| Quickstart | +A quickstart introduces your users to your application for the first time. It focuses on the primary feature of the application and helps your users to start using the application as quickly as possible. | +
| Style guide | +A style guide provides project contributors with general guidelines for writing project documentation. The overall goal of a style guide is to ensure quality and consistency throughout the project's documentation, which is especially important if different authors are contributing to the documentation over time. | +
| Terminology system | +Using this template, writing teams can ensure they consistently use and translate the same terms across all the documentation in their system. | +
| User personas | +User personas are a framework to identify the characteristics that differentiate each user type for your product or service. Discovering more about your users will help you make user-centric product decisions and produce better documentation. | +
| Guideline + | +Check + | +
| Write for the audience. + | +Does the template target one or more of the following personas, as defined by the Good Docs Project?
+
|
+
| Assumptions about the audience + | +What does the audience already know about the subject and what does the audience need to know? + | +
| Try to anticipate questions that the audience might have. + | ++ | +
| Guideline + | +Check + | +
| Always refer to a feature, a concept, or an object with the same term. + | +Did you always use the same term and the same spelling to refer to the same thing? + | +
| Do + | +Don't + | +
| In the Getting started pages, use three levels of headings. + Getting started pages are a great place to start. + | +In the Getting started (GS) pages, use three levels of headings. + GS pages are a great place to start. + | +
| In The Good Docs Project website, you can find information about the monthly meetings. + The website doesn't have a search engine. + | +In The Good Docs Project (TGDP) website, you can find information about the monthly meetings. +TGDP doesn't have a search engine. + | +
| Guideline + | +Check + | +
| Spell out an acronym in the first occurrence of it on a topic. + | +Make a list of the acronyms that you are using and, on every topic, spell them out in the first occurrence. + | +
| Do not spell established acronyms. + | +Are established acronyms unnecessarily spelled out? + | +
| Do + | +Don't + | +
| When the process of freeing a vehicle that has been stuck results in ruts or holes, the operator will fill the rut or hole created by such activity before removing the vehicle from the immediate area. + | +If you make a hole while freeing a stuck vehicle, you must fill the hole before you drive away. + | +
| Do + | +Don't + | +
| To register a user, configure the system first. + | +To register a user, you will need to configure the system first. + | +
| Do + | +Don't + | +
| You must install Docker. + | +Docker should be installed. + | +
| Configure the Oracle instances. + | +If the Oracle instances haven't been configured yet, then they will need to be. + | +
| Do + | +Don't + | +
| Readme documentation of the Terra service OR Readme of the Terra service + | +Terra service readme documentation + | +
| Guideline + | +Check + | +
| Write short sentences + | +Are sentences as short as possible without compromising clarity? + | +
| Write in the simplest tense + | +Are sentences written in the simplest tense possible in the context where they are? + | +
| Write for easier translation + | +Are sentences relatively easy to translate? + | +
| Don`t use metaphors, figures of speech, slangs, or jargons. + | +Are there metaphors, figures of speech, slangs, or jargons? + | +
| Guideline + | +Check + | +
| Sentence case + | +Did you use sentence case in most cases? + | +
| UI + | +Does the text match the capitalization in the UI? + | +
| Product/feature/methodology + | +Do the product/feature/methodology match the authoritative website about the product/feature/methodology? + | +
| Unnecessary capitalization + | +Did you correct unnecessary capitalization? + | +
| Do + | +Don't + | +
| To request a template, send a request to the TGDP with the document type that needs a template. + We will assess the document type. + Depending on the industry needs, we assign it a priority and then add it into the list of templates that need a writer. + | +The process of requesting a template begins with a request to the TGDP for a template for a document type. + TGDP's review of this request includes assessment of the industry needs. + Depending on the demand for the template, we assign a priority to it, and then add it into the list of templates that need a writer. + | +
| Do + | +Don't + | +
| To edit system-defined metadata of an object:
+ +1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/. + +2. Navigate to your Amazon S3 bucket or folder and select the check box to the left of the names of the objects with metadata you want to edit. + |
+ 1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
+ +2. Navigate to your Amazon S3 bucket or folder and select the check box to the left of the names of the objects with metadata you want to edit. + +3. Select Save to save the system-defined metadata of an object. + |
+
| Do + | +Don't + | +
| 1. On the **Actions** menu, choose **Edit** actions, and choose **Edit metadata**. + | +1. Choose **Edit metadata** on the **Actions** menu> **Edit metadata**. + | +
| Do + | +Don't + | +
| 1. On your **home directory**, type command. + | +1. On the terminal, type command. + | +
| Do + | +Don't + | +
| For printing color reproductions locally, use a high-resolution laser or wax-transfer printer that has at least 1MB of memory. + | +For local PC printing, it is recommended that you use a high-resolution laser or wax-transfer type printer for color reproductions, and that the printer have at least 1 MB of memory. + | +
| Unless you have already submitted an up-to-date resume, you must submit a resume containing your undergraduate, graduate, and any other professional education, your work experience in the field of health care, and the name, address and phone number of current and previous employers in the healthcare field. + | +With your grant application you must submit a resume containing your undergraduate, graduate, and any other professional education, your work experience in the field of health care, and the name, and phone number of current and previous employers in the healthcare field, unless you have already submitted this information. + | +
| Guideline + | +Check + | +
| Goal comes first in a sentence + | +Did you make sure that you contextualized sentences based on the goal (if any)? + | +
| Location comes first in a sentence + | +Did you make sure users know where to find the information in the UI? + | +
| Condition comes first in a sentence + | +Did you make sure that conditions came first (if any)? + | +
| Most important information comes first + | +Did you make sure that you placed the most important information first in the topic, section, or page? + | +
| Risk + | +How to write + | +Example + | +
| Low risk + | +Do not hyperlink, but explain how to find the information. + | +To read about how to register an app with Firebase, go to the Firebase website and search for 'register app Firebase'. + | +
| Medium risk + | +Hyperlink to the website, and explain how to search for the information. + | +To read about how to register an app with Firebase, go to `Firebase https://firebase.google.com/`_ and search for 'register app Firebase'. + | +
| High risk + | +Hyperlink to a specific topic + | +To read about how to register an app with Firebase, go to `Add Firebase to your Apple project https://firebase.google.com/docs/ios/setup#register-app`_. + | +
| Not so helpful link + | +Problem + | +Solution + | +Helpful link + | +
| For more information, see this link. https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html#add-links`_ OR
+ + For more information, `click here. https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html#add-links`_x + |
+ 'this link' or 'click here' don't have any context and don't help users figure out what the topic is about. + | +Rewrite the link text so that it tells users what the topic is about. + | +For more information about adding links in Sphinx, see `Add links. https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html#add-links` + | +
| Read the Before Installing or Upgrading documentation before installing or upgrading. + | +If there are multiple products, documentation of which one? + | +Whenever there is more than one possibility, be specific about which documentation the link displays. + | +Before installing or upgrading the NetApp Kubernetes Monitoring Operator, read the Before Installing or Upgrading documentation. + | +
| Guideline + | +Check + | +
| If possible, use low-risk links for external documentation. + | +Did you choose low-risk or medium risk, over high risk links whenever possible? + | +
| Help users to decide to follow the link or not, before they do + | +Did you help users to choose to follow links or not by either by adding an introductory sentence or by writing a helpful link text? + | +
| Accessed on + | +Did you provide the date you accessed the link? + | +
| Place the link where it is helpful and not a distraction + | +Did you place essential links next to the text where it is needed? Did you place links with supporting information in a section for related information? + | +
| Do + | +Don't + | +
Administrators can manage VMs with the following features:
+
|
+ Enable administrators to deal with VMs with the following features:
+
|
+
| Do + | +Don't + | +
Administrators can manage VMs with the following features:
+
|
+ Enable administrators to deal with VMs with the following features:
+
|
+
| Do + | +Don't + | +
+
|
+
+
|
+
| Do + | +Don't + | +
The retention policy is the following:
+
|
+ The retention policy is the following:
+ +1. Slack - 30 days for Chat, 4yrs for channels, 4yrs for files + +2. Gmail attachments - 2yrs for active accounts, 6mths for non-active accounts + |
+
| 2 items in a list + | +3 items in a list + | +
| Turn the system on. Press a, b and c. + | +Turn the system on. Press a, b, and c. + | +
| Do + | +Don't + | +
Things I should eat:
+
|
+ Things that I eat:
+
|
+
| Guideline + | +Check + | +
| Write an introductory sentence + | +Does the list have an introductory sentence? + | +
| Use numbered lists when the order is important + | +Is the numbered list wrong if the items are listed out of the current order? + | +
| Use bullet lists for non-ordered items + | +Can the items be listed in any order? + | +
| Use oxford comma + | +Does the inline list have three or more items? + | +
| Use parallel phrasing + | +Does the list present the same structure for all items? + | +
| Guideline + | +Check + | +
| Use a list whenever possible + | +Can the table be written as a list? + | +
| Use a table for two or more parts of information + | +Does the table contain two or more parts? + | +
| Use a table to bring out more information + | +Does the table bring out information? + | +
| Use a table to save repeating words + | +Does the table save words significantly? + | +
| Write an introductory sentence + | +Does the table have an introductory sentence? + | +
| Add a table header + | +Does the table have a header? + | +
| +Do + | +Don't + | +
| To edit system-defined metadata of an object:
+ +Tip: Use your TGDP credentials. + +1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/. + +2. Navigate to your Amazon S3 bucket or folder and select the check box to the left of the names of the objects with metadata you want to edit. + |
+ 1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
+ +2. Navigate to your Amazon S3 bucket or folder and select the check box to the left of the names of the objects with metadata you want to edit. + +3. Select **Save** to save the system-defined metadata of an object. + +Tip: Use your TGDP credentials. + |
+
| Guideline + | +Check + | +
| Use notes sparingly + | +Does the topic have more than one note? + | +
| Place notes when users need them + | +Is the information in the note something users need to see before they read the text that comes after the note? + | +
| Place notes when users need them + | +Is the note placed before a table, a section, an image, or a chart? + | +
| Deliverable + | +Naming convention for the filename and purpose of the file + | +Use case + | +
| Template + | +template_content-type.md
+ +The template file is the raw template for the content type. +It provides a rough outline of the suggested content and a few embedded writing tips for how to fill in the different sections of the template. + |
+ Used by Developer-Writer Darby to create better documentation.
+ +"Just give me something easy I can fill out and nothing more!" + |
+
| Template guide + | +guide_content-type.md
+ +This guide provides a deeper explanation of how to fill in the template. +It provides a lightweight introduction to the purpose of this documentation and explains how to fill in each section of the document. +Any information that is essential to filling out the template should be noted in this guide. + |
+ Used by Developer-Writer Darby to fill in the template.
+ +"When I get stuck, I'll refer to the guide to help me out. +Keep this guide simple and lightweight for me!" + |
+
| Resources + | +resources_content-type.md
+ +This document includes the resources (books, blog entries, guides) that the templateer used during the research phase of creating the template. +The templateer can also include high quality examples of that content type that served as inspiration for the template. +Template contributors should use this document to ethically cite their sources and give credit where credit is due, in harmony with our Code of Conduct. + |
+ Used by Templateer Terry to ethically cite sources.
+Also used by Doc System Owner Olly to understand the theory that informs this template on a deeper level.
+ +"If I want to customize this template for my project, I can use this document to make informed changes. +If I need to maintain this template and make changes to it in the future, I can understand the thinking that went into the template originally." + |
+
| Process + | +process_content-type.md
+ +This document explains best practices for researching, writing, and maintaining this content type. +As a minimum viable document, it can be very lightweight and include simple content about researching, writing, and maintaining that content type---such as a paragraph each. +If a more detailed explanation is needed for that content type, it can go deeper. + |
+ Used by Developer-Writer Darby and Doc System Owner Olly to learn about any unique challenges or best practices when writing this content type.
+ +"Help me understand best practices and avoid common mistakes." + |
+
| Example + | +example_content-type.md
+ +After a template project is complete, our Chronologue working group will create an example of the template. +While creating the example, the Chronologue group will test whether your template is user-friendly and can be used in a real documentation project. +If you're still involved in the community during this phase, these team members might reach out to you for feedback or to collaborate on possible template revisions. +NOTE: Examples are required, but they are created after the template writing process. + |
+ Used by Developer-Writer Darby and Doc System Owner Olly to see what this content type looks like in a practical context.
+ +"Help me see an example of this template in action so that I can see what 'good enough' looks like." + |
+
| For the project + | +It gives The Good Docs Project a way to ethically cite our sources and give credit where credit is due. + | +
| For the template contributor + | +It gives them a starting point and ending point (a goal + a final deliverable) for the research phase. + | +
| For template readers who choose to read the process document + | +It explains the theory behind why certain decisions were made to the template, which can help them understand why the template author made certain design decisions. +It can also help them know how they can customize the template to their organization's needs. + | +
| Future template maintainers + | +This document helps them understand why a template was developed a certain way. +It will help them decide whether to change the template in the future (or not). + | +
` element; in Markdown, use three backticks.
+* Replace {METHOD} with the actual request method and capitalize all letters. For example, `POST`.
+* In the {request_url} segment, start with a slash character `/` and only provide the URL path (the segment after the hostname). The base URL can be omitted if you have already documented it in the API overview. For example, `/v2/users`.
+* If the {request_url} contains path variables, use a placeholder to indicate the variable name. The format of placeholders should be consistent throughout the documentation set and conform to your organization's guidelines. As an option, you can use snake case characters in curly brace `{}`, delimited by underscores. For example, `{user_id}`.
+* Optionally use a different color to make the path parameters easily identifiable.
+* Do not add slash characters `/` at the end.
+
+### About the "Description" section
+
+Use the _Description_ section to provide more information on what the endpoint does, the purpose, and use cases of this API endpoint.
+
+Optionally add notes about the API endpoint, for example:
+
+* Versioning information
+* Limitations
+* Deprecation status and whether a replacement is available
+
+### About the "Authorization" section
+
+Provide a link to the common `Authorization` section in the API reference overview.
+
+If calling the endpoint requires additional user roles or permissions, document them in this section.
+
+### About the "Request schema" section
+
+Use the _Request schema_ section to define the specifications of the endpoint.
+
+Each of the sub-sections is optional and should be adopted according to the actual endpoint definition:
+
+* **Path parameters**: parameters defined within the path of the endpoint, denoted by placeholders. Path parameters are always required.
+* **Query parameters**: parameters appended to the end of the request URL, after a question mark `?`. Parameters and their assigned values are connected by the `=` (equal) symbol. Multiple query parameters are delimited by the `&` (ampersand) symbol.
+* **Header parameters**: parameters used for custom HTTP headers in a request, often the same across endpoints in an API set. Include this section only when specific header parameters are required for this endpoint.
+* **Request body**: data carrying additional content of the request, only applicable for requests using methods that permit a payload, such as POST, PUT, and PATCH. Include a link to the description of the resource type if applicable.
+
+If no request parameters or request body are supported, specify "None" in this section.
+
+**Tips**:
+
+* In each of the tables, keep the parameter name the same as what is presented in the endpoint section above.
+* In the `Required?` column, specify "Required" or "Optional" to avoid ambiguity. You may use uppercase or the bold style to emphasize the term "Required".
+* In the `Type` column, if the data type has detailed definitions in another place, provide the link.
+* In the `Description` column, start the description with a noun and omit the articles (the/a/an). No need to write "defines/specifies". For example, "Unique identifier of the user" or "Name of the user". If applicable, provide additional information, such as:
+ * Default values. For example: "The default value is 0."
+ * Minimum/maximum values. For example: "The value must be within the range 100 - 999 (both inclusive)."
+ * Allowed values. For example: "The allowed values are `left` and `right`."
+ * Usage restrictions. For example: "Use this parameter only when {a condition} is true."
+ * Any limit applicable to this field. For example, "The ID must be 16 characters long."
+* Do not leave cells empty in the table. If there is no content, fill with "N/A" (short for "not applicable").
+
+### About the "Request example" section
+
+Use the _Request example_ section to provide an example that is complete and correct. The request should include all elements of a request, if applicable:
+
+* Method name
+* Base URL
+* Endpoint
+* Headers
+* Parameters
+* Request body
+
+The example should show as many parameter configurations as possible. Preferably, the example could be copy-pasted directly into your user's environment and return the same result.
+
+**Tips**:
+
+* If you have several parameters for different use cases, especially when then parameters can not be used together, consider providing multiple request examples.
+* The recommended format for your example is `cURL` request. Depending on the business needs, you can add request samples in multiple programming languages, which can be generated by external tools. Do user research in advance to determine what languages should be adopted. Meanwhile, you should also consider the additional maintenance effort when you add more examples.
+* Match the sample request and parameters to the exact response the user would receive with those same parameters.
+* Use preformatted code blocks to make your code distinctive from other text blocks.
+
+### About the "Response schema" section
+
+Use the _Response schema_ section to describe the content type and data model that is returned in the response, in both successful and failed cases:
+
+* For successful requests, provide the content format. If the returned data type is documented somewhere else, provide a link to the definition of the data type.
+* For failed requests, provide the possible error codes and the link to the error description. The list of possible errors is usually a subset of the common errors provided in the [Errors](#about-the-errors-section) section in API Overview.
+
+### About the "Response example" section
+
+Use the _Response example_ section to provide an example of the response body if any, or clearly state that "the response body is empty".
+
+## Additional resources
+
+* [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification/)
+* [REST Resource Naming Guide](https://restfulapi.net/resource-naming/)
+* [HTTP Response Status Code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=API%20reference%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/api-reference/template_api-reference.md b/meta/reference/good-docs-project-template-1.5.0/api-reference/template_api-reference.md
new file mode 100644
index 00000000..5a6f0c7d
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/api-reference/template_api-reference.md
@@ -0,0 +1,186 @@
+# API Reference template
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_api-reference.md).
+>
+> This template includes writing instructions and boilerplate text that you can customize, use as-is, or completely replace with your own text. This text is indicated in {curly brackets}. Make sure you replace the placeholders with your own text.
+
+## Overview
+
+Use the {product} APIs to {access | customize | program} the {features | functionality}.
+
+### Base URL
+
+```text
+{Provide the base URL of the API. For example: https://api.example.com}
+```
+
+### Authorization
+
+Authentication and authorization {is | is not} required for requests to these APIs. Supported authentication methods are:
+{ Basic | Digest | OAuth | others}
+
+```text
+{Provide an example request with {Basic | Digest | OAuth | others} authentication.}
+```
+
+### Version
+
+{This section is optional.}
+
+{Provide the version number using semantic versioning or your product's API versioning scheme. For example: `0.0.1`}
+
+### Pagination
+
+{This section is optional.}
+
+Due to the potentially very large result sets from API calls, responses {are | can be} returned as shorter pages.
+
+Pagination can be customized using {pagination settings}. If not specified, the default values are {values}.
+
+### Rate limiting and throttling
+
+{This section is optional.}
+
+The {product} APIs use a {strategy-name} rate limiting strategy. The maximum number of requests allowed to access a {resource | endpoint |..} is {number} requests per {time period}.
+
+### HTTP status codes
+
+The {product} APIs use the following standard HTTP response codes:
+
+| Status code | Message | Description |
+|-------------|-------------------|---------------|
+| `200 OK` | Request succeeds. | {description} |
+| | | |
+| | | |
+
+### Errors
+
+{This section is optional.}
+
+The {product} APIs use the following error types:
+
+| Error | Description |
+|-----------------------------------------|------------------|
+| [{ExampleErrorType}](#exampleerrortype) | {Failure in ...} |
+| | |
+| | |
+
+#### ExampleErrorType
+
+| Field | Type | Description |
+|----------------|----------|--------------------------------------------------|
+| {errorType} | {enum} | {Predefined error codes. Possible enum values are x, y, ..., and z.} |
+| {errorMessage} | {string} | {Additional information about why the error occurs.} |
+
+## {Resource name}
+
+The {resource name} is used to {functionality}.
+
+### Data model
+
+| Attribute | Type | Required? | Description |
+|-----------|--------|-----------|------------------------------|
+| {id} | string | Required | {Unique identifier of user} |
+| {name} | string | Optional | {Name of user} |
+| | | | |
+
+### Example
+
+```text
+{Provide an example of the data representation in the format that your project use.}
+```
+
+### Endpoints
+
+Use the following endpoints to interact with the {resource name} entities.
+
+| Method | Endpoint name | Description |
+|--------|------------------------------------------|-------------------------|
+| POST | {[Endpoint name A](#link_to_endpoint_a)} | Creates a {resource}. |
+| GET | {[Endpoint name B](#link_to_endpoint_b)} | Retrieves a {resource}. |
+| | | |
+
+## {Endpoint name}
+
+{Provide a one-line description of what the API does. Starts with a verb in the indicative mood. For example, "Retrieves a user by `userID`".}
+
+### Endpoint
+
+```text
+{METHOD} /{request-url}/{{path-parameter}}
+```
+
+### Description
+
+{Explain what the endpoint does.}
+
+{This paragraph is optional.} This endpoint has been deprecated. Use {the recommended endpoint} instead. For more information about how to migrate to {the recommended endpoint}, see [{the migration guide}](#link).
+
+{This paragraph is optional.} The maximum number of calls to this API endpoint is {number} per minute. For more information about API rate limiting/throttling, see [{the topic}](#example).
+
+### Authorization
+
+The [{authorization method}](#authorization) is required for each API request.
+
+{This paragraph is optional.} Calling this endpoint also requires the {permission-name} permission.
+
+### Request schema
+
+#### Path parameters
+
+{This section is optional.}
+
+| Path parameter | Type | Required? | Description |
+|----------------|--------|-----------|------------------------------|
+| {id} | string | Required | {Unique identifier of user} |
+| | | | |
+
+#### Query parameters
+
+{This section is optional.}
+
+| Query parameter | Type | Required? | Description |
+|-----------------|------|-----------|-----------------------------------------|
+| {pageSize} | int | Optional | {The number of items to be returned in a single request. The default value is N.} |
+| | | | |
+
+#### Header parameters
+
+{This section is optional.}
+
+| Header parameter | Type | Required? | Description |
+|------------------|--------|-----------|--------------------------------------|
+| {Content-Type} | string | Required | {Media type of the resource. Must be an object.} |
+| | | | |
+
+#### Request body
+
+{This section is optional.}
+
+| Field | Type | Required? | Description |
+|--------|--------|-----------|----------------------------------|
+| {id} | string | Required | {Unique identifier of the user} |
+| {name} | string | Optional | {Name of the user} |
+
+### Request example
+
+```text
+{Provide an example of the API request, filled with sample values.}
+```
+
+### Response schema
+
+| Status code | Schema | Description |
+|-------------|-----------------------------------------|----------------------|
+| `2xx` | [{ExampleDataType}](#data-model) | {Describe the result where the request succeeds.} |
+| `4xx` | [{ExampleErrorType}](#exampleerrortype) | {Describe the result where the request fails with the specified error code.} |
+
+### Response example
+
+```text
+{Provide an example of the API response, filled with sample values.}
+```
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=API%20reference) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/bug-report/guide_bug-report.md b/meta/reference/good-docs-project-template-1.5.0/bug-report/guide_bug-report.md
new file mode 100644
index 00000000..c7f76b61
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/bug-report/guide_bug-report.md
@@ -0,0 +1,103 @@
+# Bug report user guide
+
+> Thank you for downloading this template from The Good Docs Project! Before using the template, read this template guide for information about how to complete each section. Want to explore more templates? Check them out in our [templates GitLab repository](https://gitlab.com/tgdp/templates).
+
+## Introduction
+
+Bug reports play a crucial role in any software development process. They allow both developers and users to accurately track and understand unintended issues with project functionality.
+
+## Why do I need a Bug Report template?
+
+A Bug Report template provides a standardized framework for bug reports in a project, helping users and developers understand the necessary information to reproduce, understand, and fix a bug.
+
+When a developer needs clarification regarding critical bug-related information, relaying information from the party identifying the bug to the developers working on the underlying issue can waste time and resources. By providing a bug report template that covers important areas, it bridges the gap in information and enables effective bug resolution within a project, regardless of a reporter's technical abilities.
+
+## Bug Report best practices
+
+When writing bug reports:
+
+* Limit bug reports to a single bug per report.
+* Check the existing issues to ensure the bug has not already been reported.
+* Try to reproduce the bug more than once, including environment setup if possible.
+* Don't get lost in irrelevant details.
+* Don't make assumptions about why a bug occurs.
+* Provide as much proof of the bug as possible (logs and screenshots / video where necessary).
+
+When addressing, or responding to bug reports:
+
+* Identify any gaps in the information provided that may be important in reproducing the bug.
+* Communicate clearly in the report so the reporter, and anyone else viewing the report can understand any further inquiry, any provided workaround, or a provided solution.
+
+Depending on the work environment, issues may be assigned development related information. This information should be assigned by a project developer, and not necessarily a bug reporter. Potential categories of information that should be assigned by project staff include:
+
+* Priority
+* Weight
+* Assignees
+* Labels
+* Any other project level data, like milestones or epics
+
+## Content of the Bug Report template
+
+### About the "Title" section
+
+The title of a bug report serves as the primary means of discovering an issue. Both developers and project users often search for bug reports and issues. A descriptive title reduces the number of duplicate bug reports and allows users to find and utilize information provided in existing bug reports.
+
+### About the "Summary" section
+
+Specific context and detail may not fit within the title of a bug report. Edge cases often arise under explicit conditions, and a summary provides context for a bug, allowing developers to group related bug reports or prioritize bugs without delving into the details.
+
+Including an optional summary section enables reporters to quickly summarize the specific nature and conditions of a bug. A concise summary ensures that key information isn't lost when extensive detail is provided in the report.
+
+### About the "Environment" section
+
+Bugs are often encountered in specific environments. Providing detailed information about the system environment in which a bug occurred is crucial for developers to identify the root cause. Even if reproduction is impossible, knowledge of an environment where a bug occurred can reveal key differences in operation on different systems, guiding development practices.
+
+### About the "Steps to reproduce" section
+
+Detailing the specific steps taken to encounter the bug allows developers to identify any errors in the process or accurately reproduce the bug if the environment can be replicated.
+
+### About the "Observed behavior" section
+
+Detailing the observed behavior provides developers with an understanding of the bug's effects. Observations that may not be evident in logging or output can offer insights that assist in identifying the bug's cause. For example, if a specific step takes longer than expected, it may indicate a connection to the issue. Detailing such observations is important, while providing personal perspectives on the cause can be distracting or provide incorrect information. Manual review and acknowledgment by the reporter can provide accurate information, unlike relying solely on logs.
+
+### About the "Expected behavior" section
+
+Detailing the expected behavior of the product without the bug can be as simple as stating "should not produce an error." However, for edge cases or specific product uses, the bug reporter's expectations may differ from the product's intended behavior. This disparity may indicate an issue with product documentation or the reporter's understanding. Identifying these differences early in the bug reporting process saves developers from investigating bug reports that may be rooted solely in the reporter's expectations.
+
+### About the "Proof" section
+
+Allocating space for providing proof of a bug allows reporters to provide screenshots, logs, videos, or other forms of hard evidence. Proof not only confirms the validity of a bug report but can also provide additional bug-related information beyond what the reporter can provide.
+
+### About the "Test data" section
+
+Products that require input may contain bugs that are not easily identified due to the variety of potential input. Sharing test data that led to the bug allows for accurate reproduction of the issue, simplifying the developer's process of identifying and resolving the bug.
+
+Test data may contain sensitive information and should be redacted before reporting a bug. Reporters should be encouraged to redact the data and test it again to ensure that any provided test data still triggers the bug.
+
+### About the "Additional context" section
+
+Additional context can provide critical information for finding the root cause of a bug. Bugs may only occur under specific conditions, during certain processes, or when system resources are being consumed by other processes. The product itself may shape what additional context is desirable in a bug report. Identifying common conditions associated with increased bugs and performance issues becomes significantly easier if bug reporters know to provide context related to those conditions.
+
+### Project information
+
+Depending on the platform used, issues may have additional project-related information attached. This information is directed toward project management and internal issue tracking and is not covered in this template. If a reporter is also a project maintainer, they may add this information.
+
+Some examples of project oriented information are:
+
+* Severity
+* Assigned project members
+* Labels
+* Milestone
+* Status
+* Resolution
+
+## Additional Bug Report resources
+
+* How to create an issue (GitHub): https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue
+* How to create an issue (GitLab): https://docs.gitlab.com/ee/user/project/issues/create_issues.html
+* Issue templates for GitHub: https://github.com/MarketingPipeline/Awesome-Repo-Template/tree/main/.github/ISSUE_TEMPLATE
+* Issue templates for GitLab: https://www.garybell.co.uk/gitlab-issue-templates/
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Bug%20report%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/bug-report/template_bug-report.md b/meta/reference/good-docs-project-template-1.5.0/bug-report/template_bug-report.md
new file mode 100644
index 00000000..2c887720
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/bug-report/template_bug-report.md
@@ -0,0 +1,58 @@
+# Bug Report Template
+
+> If you need more information about how to fill in this template, read the accompanying [guide](guide_bug-report.md).
+>
+> This template includes writing instructions and boilerplate text that you can customize, use as-is, or completely replace with your own text. This text is indicated in {curly brackets}. Make sure you replace the placeholders with your own text.
+
+## Title
+
+{A description of the issue using key words relating to the issue. 50 to 80 characters recommended. Description should cover the problem, the action, and the location (if relevant).}
+
+## Summary (optional)
+
+{If the title is insufficient for summarizing the bug, use the summary to detail the bug as concisely as possible. 3-4 sentences recommended.}
+
+## Environment
+
+{Detail the specific environment used when the bug was encountered.}
+
+* {Product version}
+* {Browser}
+* {Installed packages and versions}
+* {Operating system}
+* {Device model}
+* {Connection details (type, speed, any packet loss)}
+
+## Steps to reproduce
+
+{An ordered list of the steps taken where the result was encountering the bug. Include any observations of relevance such as unexpected output, visual glitches, unusual process duration.}
+
+* {Step 1}
+* {Step 2}
+* {Step 3}
+
+## Observed behavior
+
+{Briefly describe the result of the steps taken that resulted in the bug being encountered. Avoid any assumptions regarding the behavior.}
+
+## Expected behavior (optional)
+
+{Briefly describe the expected result of the steps taken.}
+
+## Proof (optional)
+
+{Provide a copy of any relevant logs, screenshots, or malformed output if relevant.}
+
+## Test data (optional)
+
+{If the bug is only encountered when using specific test data, provide a copy of that data. If the data needs to be redacted, please ensure the redacted data also causes the unexpected behavior using the same steps.}
+
+## Additional context (optional)
+
+{If any additional context is required, detail that context here.}
+
+{Please keep in mind the project team may need additional clarification after the report is submitted.}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Bug%20report) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/changelog/guide_changelog.md b/meta/reference/good-docs-project-template-1.5.0/changelog/guide_changelog.md
new file mode 100644
index 00000000..15560cd5
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/changelog/guide_changelog.md
@@ -0,0 +1,146 @@
+# Changelog guide
+
+Thank you for downloading this template from The Good Docs Project! Before using the template, read this template guide for information about how to complete each section. Want to explore more templates? Check them out in our [templates](https://gitlab.com/tgdp/templates) GitLab repository.
+
+## Introduction
+
+A changelog records all significant and noteworthy modifications you make to each release of a product in reverse-chronological order. Changes can be bug and issue fixes, feature enhancements, updates, additions, security updates, and other significant changes. Well-written changelogs provide a transparent and detailed view of the development approach, product evolution, and the organization's commitment to the product.
+
+Changelogs are often confused with release notes. They're both essential documents in software development for documenting and communicating product changes over time. However, there are several key differences between the two.
+
+| | Changelogs | Release notes |
+| -------- | ---------- | ------------- |
+| Audience | Technical product users or those interested in detailed code changes. | Technical and non-technical product users. |
+| Purpose | Document code changes made to a software project. | Describe changes to features and functionality at a high level. |
+| Scope | Is comprehensive and documents every change in the software, whether major or minor. | Is narrower and focuses on features and fixes relevant to the end user. |
+| Content | Uses technical, developer-focused language. | Uses plain language and avoids technical jargon. |
+
+## Why do I need a changelog?
+
+Changelogs provide several benefits to software development teams:
+
+* They help team members track their project work.
+* They show users that you are making progress on your project's development.
+* They can serve as onboarding tools for new team members. For example, team members can read the changelog to familiarize themselves with the project.
+
+Changelogs that follow a consistent format, style, and reporting cadence also help development teams to communicate and understand the reason behind the change by focusing on when the change was made, who made it, and why.
+
+## When do I need a changelog?
+
+Changelogs and release notes both inform users about changes to your software. However, they differ in terms of audience, purpose, scope, and content. When deciding whether to create a changelog or release notes, think about these questions:
+
+* Which audience are you targeting?
+ * Are the changes relevant to technical product users or non-technical product users? If the changes are relevant to both, you might consider creating a changelog and release notes for your project.
+* How much information do you want to provide?
+ * If you want to provide detailed, comprehensive information about the changes, a changelog might be best for your team. If you'd rather provide a high-level summary of the feature, then release notes might be suitable.
+* How often are product releases?
+ * If you release your software every three months, you might have a changelog that is long and hard to digest. In this case, release notes might be suitable because they provide a high-level overview of the changes.
+ * If you release your software every month, your team might benefit from changelogs to communicate changes to your users, as they might be shorter.
+
+## Content of the changelog template
+
+This section provides details about the different sections in the changelog template. The following sections are included in the template:
+
+* Version
+* Release highlights
+* Added
+* Changed
+* Deprecated
+* Fixed
+* Security
+* Breaking changes
+
+If you're in the early stages of building your application, you may only need the "added," "changed," and "fixed" sections. As your project evolves, you can include the other sections.
+
+Always include a link to the associated merge request or pull request for the entries in each section.
+
+### About the "Version" section
+
+In this section, you provide the version number for the release. You should use Semantic Versioning ([SemVer](https://semver.org/)) for the version number and YYYY-MM-DD International Date Format for the date. SemVer is the industry-standard way to write release versions.
+
+Here are some examples of writing version numbers:
+
+* 18.2.8 (2024-10-10)
+* 1.1.1 - 2023-03-05
+
+### About the "Release highlights" section
+
+The "Release highlights" section provides insight into new features, enhancements, and bug fixes for a release. Highlighting these changes benefits both developers and end users:
+
+* End users can identify key features and bug fixes for a release. This might encourage them to explore highlighted features, leading to increased feature adoption.
+* Developers can quickly understand the most significant changes in a release. For example, if the release contains breaking changes, developers can update their software immediately and plan to accommodate those changes.
+
+Each highlighted feature or enhancement should be a 1-2 sentence summary. You may optionally include a link to a release announcement or blog post.
+
+### About the "Added" section
+
+In this section, you describe any new features that were added since the last release. Provide a brief description of what the feature does. If the new feature makes your application faster, solves a problem, or makes the application more secure, highlight that here.
+
+Here are some examples:
+
+**Added**
+
+* Add Ubuntu 24.04 support [#66180](https://github.com/saltstack/salt/issues/66180) ([Salt changelog](https://github.com/saltstack/salt/blob/master/CHANGELOG.md))
+
+### About the "Changed" section
+
+In this section, you describe any changes in existing functionality for your application. Provide a brief description of the change and how it improves your application. Some examples include improved error messages or faster load times for your application.
+
+Here is an example:
+
+**Changed**
+
+* Better mono-repo support: Nested node_modules/ folders are ignored by default [#1182](https://github.com/standard/standard/issues/1182)
+([Standard changelog](https://github.com/standard/standard/blob/master/CHANGELOG.md))
+
+### About the "Deprecated" section
+
+In this section, you list features that were deprecated for the release. Include a brief explanation of why the feature was deprecated, and provide recommended or alternative features to use instead.
+
+Here is an example:
+
+**Deprecated**
+
+* Removed ExpiredSignature, InvalidAudience, and InvalidIssuer. Use ExpiredSignatureError, InvalidAudienceError, and InvalidIssuerError instead.
+([PyJWT changelog](https://pyjwt.readthedocs.io/en/2.1.0/changelog.html))
+
+### About the "Fixed" section
+
+In this section, you highlight any bugs that were fixed during the release. Provide a brief description of the bug fix and how the fix benefits the user.
+
+Here is an example:
+
+**Fixed**
+
+* MNT: Replace deprecated DataFrame.append call (#833)
+([PyBIDS](https://github.com/bids-standard/pybids/blob/master/CHANGELOG.rst))
+
+### About the "Security" section
+
+In this section, you list any resolved common vulnerabilities and exposures (CVEs) or other improvements to your software's security.
+
+If you find a CVE in your software, you report the CVE to the CVE Program, which identifies, defines, and catalogs publicly disclosed cybersecurity vulnerabilities. After you complete the reporting process, you receive a CVE ID, which references the vulnerability. Users can use the CVE ID to look up details about the vulnerability in the CVE program database.
+
+It is important that you provide clear, concise details about the nature of the CVE so your users know how the CVE will affect their system. You should also include the CVE ID in the changelog entry.
+
+Visit the [CVE Program website](https://www.cve.org/about/Process) for more information about the process for submitting a CVE.
+
+Here is an example:
+
+**Security**
+
+* secrets/identity: A privileged Vault operator with write permissions to the root namespace's identity endpoint could escalate their privileges to Vault's root policy (CVE-2024-9180) HCSEC-2024-21 ([Vault changelog](https://github.com/hashicorp/vault/blob/main/CHANGELOG.md))
+
+### About the "Breaking changes" section
+
+In this section, you describe any breaking changes to your software, such as:
+
+* Deleting or adding resources to your API
+* Changing project dependencies
+* Modifying the behavior of existing functions
+
+If users need to upgrade their application as a result of the breaking change, you should include that information here and include any instructions to upgrade.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Changelog%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/changelog/process_changelog.md b/meta/reference/good-docs-project-template-1.5.0/changelog/process_changelog.md
new file mode 100644
index 00000000..e906fab4
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/changelog/process_changelog.md
@@ -0,0 +1,63 @@
+# Changelog process
+
+Thank you for downloading this template from The Good Docs Project! Before using the template, read this document for best practices about how to research, write, and maintain this type of content. Want to explore more templates? Check them out in our [templates](https://gitlab.com/tgdp/templates) GitLab repository.
+
+## How to research a changelog
+
+We recommend collaborating with the department that manages changelogs at your organization-this could be software developers, product development, or quality assurance. Some general tips include:
+
+* Know your audience. Internal and external audiences can view changelogs-sometimes even both audiences. Internal audiences may require more technical language, while external audiences may need user-friendly language. You should determine if the changelog is viewable for a public audience prior to the changelog creation.
+* Pick a style and format. There are different options for formatting and style when it comes to creating a changelog. Using a specific style and format makes the content easier for a reader to skim-and makes it easier for the writer to create changelogs.
+
+### Automated or manual changelogs
+
+It's also important to think about how you will write your changelog: by manually drafting commit entries or by using a changelog automation tool. Changelog automation tools like [standard-version](https://github.com/conventional-changelog/standard-version) or [towncrier](https://pypi.org/project/towncrier/) generate a changelog based on your commits, which can save you time. Manually writing changelog entries might take longer, but you can be more selective with the entries that appear in the changelog.
+
+| | Automation | Manual |
+| -------- | ---------- | ------------- |
+| Time | Takes less time to generate. | May take more time to write each entry.|
+| Onboarding | Can require readers and writers to learn, install, and configure specific tooling to generate content. | Has little to no learning curve for readers and writers. |
+| Readability | Tooling can cause all commits to be included, which may make the changelog harder to read. | Allows more agency for writers when deciding what is necessary to include in a changelog. |
+
+### Additional considerations
+
+We recommend addressing the following topics regarding changelogs:
+
+* Adopt a best practice for ensuring manual changelog entries are both well-thought-out and comprehensive.
+* Establish criteria to determine which changes should be included in a manually written changelog.
+* Develop standards around formatting Git commit messages for automated changelogs.
+* Address the process for handling Security issues, especially Common Vulnerabilities and Exposures (CVE's).
+ * There is a process for reporting any CVE's found in your software.
+ * Depending on the severity of the CVE, there may be legal ramifications if the CVE is not reported.
+ * We recommend learning more about CVE's from https://www.cve.org/.
+
+## How to write a changelog
+
+The following tips may be useful when writing a manual changelog:
+
+* Label changelog entries for ease of use.
+ * Added, Changed, Deprecated, Removed, Fixed, and Security are common labels for sorting changelog entries.
+* Give credit where credit is due. If you use GitHub or GitLab, tag your project's contributors in the changelog itself or by including a link to the pull request they created. Most companies and teams have a precedent for this.
+* Determine if the change needs to be documented. Not all changes have to be included in a changelog.
+ * In general, any breaking changes, user-facing changes, or changes related to security should always be documented.
+* Keep it short. Changelogs are meant to be read by humans, not machines. They have to be long enough to make sense but concise enough to be efficient.
+ * Examples:
+ * MNT: Replace deprecated DataFrame.append call (#833) ([PyBIDS](https://github.com/bids-standard/pybids/blob/master/CHANGELOG.rst))
+ * Removed ExpiredSignature, InvalidAudience, and InvalidIssuer. Use ExpiredSignatureError, InvalidAudienceError, and InvalidIssuerError instead.
+([PyJWT changelog](https://pyjwt.readthedocs.io/en/2.1.0/changelog.html))
+* Include links to commits. This can help explain the rationale behind any changes being made. Links are often added at the end of a changelog entry with parentheses and the commit issue number.
+ * Examples:
+ * Better mono-repo support: Nested node_modules/ folders are ignored by default [#1182](https://github.com/standard/standard/issues/1182) ([Standard changelog](https://github.com/standard/standard/blob/master/CHANGELOG.md))
+ * Add Ubuntu 24.04 support [#66180](https://github.com/saltstack/salt/issues/66180) ([Salt changelog](https://github.com/saltstack/salt/blob/master/CHANGELOG.md))
+
+## How to maintain changelogs
+
+Changelogs are most useful when you update them consistently. Here are some helpful recommendations:
+
+* Sort entries in reverse chronological order. Keeping the most recent changes at the top of a changelog is useful for the audience.
+* Use Semantic Versioning ([SemVer](https://semver.org/)) to keep different versions of a project separated. This will help when it comes time to run tests, de-bug, or get an efficient summary of the state of a project.
+* Follow the ISO standard (YYYY-MM-DD) for dates to avoid confusion. This format is easiest to sort and list dates in chronological order. Additionally, using the ISO format makes it easier for readers to process the chronological information.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Changelog%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/changelog/resources_changelog.md b/meta/reference/good-docs-project-template-1.5.0/changelog/resources_changelog.md
new file mode 100644
index 00000000..a582be93
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/changelog/resources_changelog.md
@@ -0,0 +1,28 @@
+# Changelog resources
+
+Thank you for downloading this template from The Good Docs Project! Before using the template, read this document to see high-quality examples of the template in action and to review the resources that were consulted when this template was created. Want to explore more templates? Check them out in our [templates](https://gitlab.com/tgdp/templates) GitLab repository.
+
+## Examples of changelogs
+
+* [Writing good changelog entries](https://docs.gitlab.com/ee/development/changelog.html#writing-good-changelog-entries) - GitLab lists several examples of good and bad changelog entries, with additional information explaining why the example is good or bad.
+* [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) - Keep a Changelog has a scrollable Changelog file on their site. This shows actual examples of changelog entries in a specific style and format.
+* [Angular](https://github.com/angular/angular/blob/main/CHANGELOG.md) - Angular is an open-source web development framework.
+* [Grafana](https://github.com/grafana/grafana/blob/main/CHANGELOG.md) - Grafana is an observability and data visualization platform.
+
+## References
+
+The authors of this template want to acknowledge the resources that were consulted in the making of this template and how it informed certain elements of the template.
+
+| Source material | Best practice or section |
+| -------- | ---------- |
+|[Keep a changelog](https://keepachangelog.com/en/1.1.0/)| Guiding principles and tags for changelogs. Also includes a general FAQ about changelogs, formatting, and maintenance. |
+|[Common changelog](https://common-changelog.org)| Demonstrates a different style and formatting method than Keep a Changelog. Also includes general tips and examples. |
+|[Writing good changelog entries](https://docs.gitlab.com/ee/development/changelog.html#writing-good-changelog-entries)| Contains examples of good and bad changelog entries. Explains what makes each example good or bad. |
+|[Changelog example, format and how to write a changelog?](https://amoeboids.com/blog/changelog-how-to-write-good-one/)| Details how to maintain a changelog.|
+|[The dos and don'ts of keeping a changelog](https://devm.io/programming/dos-donts-keeping-changelog-147373) | Has a helpful "What Not to Do" section.|
+|[A Beginner's Guide to Git - What is a Changelog and How to Generate it](https://www.freecodecamp.org/news/a-beginners-guide-to-git-what-is-a-changelog-and-how-to-generate-it/) | How to automate changelogs, including different changelogs automation tools.|
+|[CVE Program Mission](https://www.cve.org/) | Provides information about CVE's, how to report them, and what the CVE Program does.|
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Changelog%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/changelog/template_changelog.md b/meta/reference/good-docs-project-template-1.5.0/changelog/template_changelog.md
new file mode 100644
index 00000000..f05ef940
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/changelog/template_changelog.md
@@ -0,0 +1,94 @@
+# Changelog template
+
+{If you need more information about how to fill in this template, read the accompanying [changelog template guide](/changelog/guide_changelog.md).}
+
+{This template includes writing instructions and boilerplate text that you can customize, use as-is, or completely replace with your own text. This text is indicated in {curly brackets}. Make sure you replace the placeholders with your own text.}
+
+## {MAJOR.MINOR.PATCH} - {YYYY-MM-DD}
+
+{The version number should be listed first. You should use Semantic Versioning ([SemVer](https://semver.org/)) for the version number and International Date Format [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) for the date.}
+
+## Release highlights
+
+{Use this section to provide an overview of the most important changes in this release. This section should be a bulleted list.}
+
+* {Feature Name}: {Summary}
+* {Feature Name}: {Summary}
+* {Feature Name}: {Summary}
+
+## Added
+
+{Use this section to list any new features that have been added since the last release. If you build your changelog from Git commits, the feature description and commit number will be added automatically.}
+
+{Start each description with a verb, such as "Fixed", "Improved", or "Added."}
+
+{Replace "Commit number" with the commit number for the feature. Remember to update the link text for the commit and contributor handle.}
+
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+
+## Changed
+
+{Use this section to list changes in existing functionality for your application. If you build your changelog from Git commits, the feature description and commit number will be added automatically.}
+
+{Start each description with a verb, such as "Fixed", "Improved", or "Added."}
+
+{Replace "Commit number" with the commit number for the feature. Remember to update the link text for the commit and contributor handle.}
+
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+
+## Deprecated
+
+{Use this section to list features that were deprecated for the release. If you build your changelog from Git commits, the feature description and commit number will be added automatically.}
+
+{Start each description with a verb, such as "Fixed", "Improved", or "Added."}
+
+{Replace "Commit number" with the commit number for the feature. Remember to update the link text for the commit and contributor handle.}
+
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+
+## Fixed
+
+{Use this section to highlight bugs that were fixed during the release. If you build your changelog from Git commits, the feature description and commit number will be added automatically.}
+
+{Start each description with a verb, such as "Fixed", "Improved", or "Added."}
+
+{Replace "Commit number" with the commit number for the feature. Remember to update the link text for the commit and contributor handle.}
+
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+
+## Security
+
+{Use this section to list any resolved common vulnerabilities and exposures (CVEs) or other improvements to your software's security. If you build your changelog from Git commits, the feature description and commit number will be added automatically.}
+
+{Start each description with a verb, such as "Fixed", "Improved", or "Added."}
+
+{Replace "Commit number" with the commit number for the feature. Remember to update the link text for the commit and contributor handle.}
+
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+
+## Breaking changes
+
+{Use this section to list any breaking changes to your software. If you build your changelog from Git commits, the feature description and commit number will be added automatically.}
+
+{Start each description with a verb, such as "Fixed", "Improved", or "Added."}
+
+{Replace "Commit number" with the commit number for the feature. Remember to update the link text for the commit and contributor handle.}
+
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+* {Feature description} {[Commit number](https://www.github.com)} {[Contributor handle](https://www.github.com/username)}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Changelog%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/guide_code-of-conduct-incident-record.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/guide_code-of-conduct-incident-record.md
new file mode 100644
index 00000000..613d5dc2
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/guide_code-of-conduct-incident-record.md
@@ -0,0 +1,86 @@
+# Code of Conduct incident record template guide
+
+> Thank you for downloading this template from The Good Docs Project! Before using the template, read this template guide for information about how to complete each section. Want to explore more templates? Check them out in our [templates GitLab repository](https://gitlab.com/tgdp/templates).
+
+This is the guide that explains how to use the Good Docs Project Code of Conduct incident record, which is part of the Code of Conduct template set.
+
+The Code of Conduct template set includes:
+
+* **Code of Conduct** - Use to create and explain your community's Code of Conduct.
+* **Code of Conduct response plan** - Use to create and explain the policy your team will follow as you handle Code of Conduct incidents.
+* **Code of Conduct incident record** - A form that is filled out when a community moderator takes an incident report from a community member.
+* **Code of Conduct remediation record** - A form that is filled out when a community moderator meets with a community member to explain the consequences of a Code of Conduct violation.
+
+You might also consider using the `../our-team/template_our-team.md` template to let your community members know who they can contact to report a Code of Conduct violation. This document is useful beyond Code of Conduct violations. It is a core document that helps you clearly communicate who belongs to your open source project or organization.
+
+---
+
+## Why do I need a Code of Conduct incident record?
+
+See the `guide_code-of-conduct.md` for reasons to incorporate a Code of Conduct and response plan.
+
+The Code of Conduct incident record is part of the documentation that needs to be kept when investigating and resolving Code of Conduct incidents.
+It is important to file this documentation to enable the community moderators to identify and prevent potential repeated patterns of abuse in the community.
+
+## Content of the Code of Conduct incident record template
+
+The following sections provide guidance about how to fill out each section of the Code of Conduct incident record template.
+
+:information_source: The Code of Conduct incident record template includes boilerplate text that you can customize or adapt, use as-is, or completely replace with your own text.
+
+### About the "Introduction" section
+
+The *Introduction* section includes a description of the goals the community moderator should keep in mind while taking an incident report from an individual.
+The community moderator should refer to this section regularly to ensure that the incident reporter feels safe and supported throughout the process.
+The moderator should default to believing the incident reporter.
+
+### About the "Incident number" section
+
+Follow your organization's incident number protocol in assigning an incident number.
+
+The incident number can include the date an investigation was opened.
+For example, yyyy-001.
+
+### About the "Name of community moderator who took the report" section
+
+The community moderator who took the report lists their name here.
+
+### About the "Reporter's contact information" section
+
+This section is optional.
+If the reporter is comfortable giving their name and contact information, note that information here.
+
+### About the "Permission from incident reporter to proceed?" section
+
+Ask the incident reporter for permission to proceeed.
+Indicate their response in thise section.
+
+If an incident reporter does not give permission to proceed with an investigation, they will be given the option to hold the report "in escrow."
+Escrowed reports will not be acted upon until there is a second report of the same incident or a similar incident involving the same individual.
+The goal of an escrow report is to retain a record of incidents in case there is a pattern of misbehavior by the same individual.
+
+If the reporter wants to keep the report in escrow, the incident record should still be filled out and filed in the appropriate archives for future tracking.
+
+### About the "Date, time, and location of incident" section
+
+This section is optional. Indicate the date, time, or location of the incident if known.
+
+### About the "Additional witnesses or contacts" section
+
+If the incident reporter mentions that other individuals were involved or present as witnesses, list those individuals here.
+If possible, note their contact information.
+
+### About the "Incident description" section
+
+After listening to the incident reporter's description of the incident, write the details here.
+
+As indicated on the template, remember to only document information required to inform the report resolution.
+Where possible, avoid documenting your opinion about the incident, or any information about individuals that is not relevant to the report.
+
+## Additional resources
+
+In creating this form, the authors were inspired by the [Otter Tech Code of Conduct Enforcement Training](https://otter.technology/code-of-conduct-training/).
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct%20incident%20record%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/template_code-of-conduct-incident-record.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/template_code-of-conduct-incident-record.md
new file mode 100644
index 00000000..5e83827d
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/template_code-of-conduct-incident-record.md
@@ -0,0 +1,54 @@
+# {Organization name} Code of Conduct incident record
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_code-of-conduct-incident-record.md).
+
+---
+
+TIPS FOR THE COMMUNITY MODERATOR:
+When gathering information from an incident reporter, strive for these goals:
+
+* **Safety** - Bring in another community moderator if something about the situation is unsafe or dangerous, but avoid inviting too many moderators into the discussion. You might make the incident reporter feel overwhelmed if there are too many moderators.
+* **Privacy** - Where possible, always strive to uphold the incident reporter's privacy. Obtain permission to proceed with the investigation.
+* **Empathy** - Be an understanding, active listener who recognizes the real emotions being felt by the incident reporter. For example, say: "It sounds like you felt (this emotion) when (this thing happened)."
+* **Support** - You should default to believing the reporter. Ask if there's anything you can do to make the incident reporter feel safe, emotionally whole, or restored. Explain the possible outcomes that are available, as provided in the [Code of Conduct](CODE_OF_CONDUCT.md) (correction, warning, temporary ban, permanent ban). However, avoid making any direct promises for exactly how the report will be handled until the investigation is concluded.
+* **Acknowledgment** - At the end of the meeting, thank the incident reporter for being part of the community and for reaching out about the incident. Let the reporter know that you will be in touch to explain how the incident will be resolved after the investigation is complete.
+
+## Incident number
+
+{Assign a number to this incident for tracking purposes.
+It can include the date an investigation was opened.
+For example, yyyy-001.}
+
+## Name of community moderator who took the report
+
+{Put your name here.}
+
+## Name of incident reporter
+
+{If the reporter wants to be anonymous, include a simple description of their role or involvement in the project.}
+
+## Reporter's contact information (optional)
+
+{Ask the reporter if they would like to provide their name and contact information.
+If yes, fill in the contact information.}
+
+## Permission from incident reporter to proceed?
+
+{Yes/no.} {If no, ask if they would like to hold the report in escrow.}
+
+## Date, time, and location of incident (optional)
+
+{yyyy-mm-dd} {time} {location}.
+
+## Additional witnesses or contacts (optional)
+
+{List anyone who might be able to provide additional information as part of the investigation.}
+
+## Incident description
+
+{Only document information required to inform the report resolution.
+Where possible, avoid documenting your opinion about the incident, or any information about individuals that is not relevant to the report.}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct%20incident%20record) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/guide_code-of-conduct-remediation-record.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/guide_code-of-conduct-remediation-record.md
new file mode 100644
index 00000000..690259ad
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/guide_code-of-conduct-remediation-record.md
@@ -0,0 +1,87 @@
+# Code of Conduct remediation record template guide
+
+> Thank you for downloading this template from The Good Docs Project! Before using the template, read this template guide for information about how to complete each section. Want to explore more templates? Check them out in our [templates GitLab repository](https://gitlab.com/tgdp/templates).
+
+This is the guide that explains how to use the Good Docs Project Code of Conduct remediation record, which is part of the Code of Conduct template set.
+
+The Code of Conduct template set includes:
+
+* **Code of Conduct** - Use to create and explain your community's Code of Conduct.
+* **Code of Conduct response plan** - Use to create and explain the policy your team will follow as you handle Code of Conduct incidents.
+* **Code of Conduct incident record** - A form that is filled out when a community moderator takes an incident report from a community member.
+* **Code of Conduct remediation record** - A form that is filled out when a community moderator meets with a community member to explain the consequences of a Code of Conduct violation.
+
+You might also consider using the `../our-team/template_our-team.md` template to let your community members know who they can contact to report a Code of Conduct violation. This document is useful beyond Code of Conduct violations. It is a core document that helps you clearly communicate who belongs to your open source project or organization.
+
+---
+
+## Why do I need a Code of Conduct remediation record?
+
+See the `guide_code-of-conduct.md` for reasons to incorporate a Code of Conduct and response plan.
+
+The Code of Conduct remediation record is part of the documentation that needs to be kept when investigating and resolving Code of Conduct incidents.
+It is important to file this documentation to enable the community moderators to identify and prevent potential repeated patterns of abuse in the community.
+
+## Content of the Code of Conduct remediation record template
+
+The following sections provide guidance about how to fill out each section of the Code of Conduct remediation record template.
+
+:information_source: The Code of Conduct remediation record template includes boilerplate text that you can customize or adapt, use as-is, or completely replace with your own text.
+
+### About the "Introduction" section
+
+The *Introduction* section includes a description of the goals the community moderator should keep in mind while taking an incident report from an individual.
+The community moderator should refer to this section regularly to ensure that they stay focused on the goal of explaining the outcome of the Code of Conduct violation.
+These meetings have the potential to be stressful and full of high emotions.
+The introduction section provides some guidelines for keeping these meetings under control.
+
+### About the "Incident number" section
+
+The incident number should match the same incident number assigned on the [Code of Conduct incident record](../code-of-conduct-incident-record/template_code-of-conduct-incident-record.md) for this incident.
+
+### About the "Name of community moderator who remediated the incident" section
+
+List the name of the community moderator who remediated the incident here.
+
+### About the "Name of community member involved in the incident" section
+
+List the name of the individual who committed the Code of Conduct violation here.
+
+### About the "Outcome" section
+
+Indicate the outcome of the Code of Conduct violation, as discussed with the other community moderators.
+
+### About the "Behavior modification plan" section
+
+Indicate the steps that will be taken as part of the outcome of the Code of Conduct violation.
+For example, if the outcome is a temporary ban from the community, indicate what steps will be taken to remove the individual's access to community forums, repositories, etc.
+
+### About the "Do you agree to follow the plan?" section
+
+After explaining the behavior modification plan, the community moderator should ask directly whether the individual will agree to follow the plan and note their response here.
+
+### About the "Consequences if they do not agree to the behavior modification plan" section
+
+In this section, list the consequences for failing to agree to the behavior modification plan.
+The suggested consequence is removal from the community.
+
+### About the "Who can they appeal this decision to?" section
+
+Fill out the details for appealing a decision in this form.
+If the appeals process doesn't change, simply add that to this form from the start for all incidents.
+
+### About the "Reported person's response to the plan" section
+
+Record the details of how the reported person responded to the plan here.
+
+### About the "Additional information gathered" section
+
+If any additional information needed, it can be noted here.
+
+## Additional resources
+
+In creating this form, the authors were inspired by the [Otter Tech Code of Conduct Enforcement Training](https://otter.technology/code-of-conduct-training/).
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct%20remediation%20record%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/template_code-of-conduct-remediation-record.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/template_code-of-conduct-remediation-record.md
new file mode 100644
index 00000000..8a54da63
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/template_code-of-conduct-remediation-record.md
@@ -0,0 +1,82 @@
+# {Organization name} Code of Conduct remediation record
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_code-of-conduct-remediation-record.md).
+
+---
+
+TIPS FOR THE COMMUNITY MODERATOR:
+When meeting with a community member to explain the outcome of a Code of Conduct violation, strive for these goals:
+
+* **Preparation** - Simply tell the community member beforehand that you wish to discuss an issue privately. Invite only one other community moderator for support if needed.
+* **Calmness** - When explaining what behavior prompted the Code of Conduct investigation, calmly state what the behavior was without judgment or emotion. State the impact on the incident reporter or the community.
+* **Clarity** - Set a clear behavior modification plan. If possible, get the community member to agree to this plan.
+* **Privacy** - Do not disclose the identity of the incident reporter or allow them to be contacted. If the community member under investigation wants to contact the incident reporter to apologize, explain that you can take the apology on their behalf. With your permission, a public apology may be acceptable under the circumstances.
+
+## Incident number
+
+{Use the same incident number that was assigned to the incident report.}
+
+## Name of community moderator who remediated the incident
+
+{Put your name here.}
+
+## Name of community member involved in the incident
+
+{List the name of the community member who committed the Code of Conduct violation.}
+
+## Severity level
+
+Select one:
+
+[ ] High
+[ ] Medium
+[ ] Low
+
+## Impact level
+
+Select one:
+
+[ ] High
+[ ] Low
+
+## Outcome
+
+Select one:
+
+[ ] Correction
+[ ] Warning
+[ ] Temporary ban
+[ ] Permanent ban
+[ ] None
+
+{List any additional details about the outcome and consequences as needed.}
+
+## Behavior modification plan
+
+{List the details of the behavior modification plan as discussed with the other community moderators.}
+
+## Do you agree to follow the plan?
+
+{Yes/no.} {If no, proceed to the consequences listed in the next section.}
+
+## Consequences if they do not agree to the behavior modification plan
+
+{List the consequences if the community member who committed the Code of Conduction violation does not agree to the plan.
+The suggested consequence is removal from the community.}
+
+## Who can they appeal this decision to?
+
+{Explain the options for appealing a decision as explained in the Code of Conduct policy.
+Explain that they must still comply with the incident response plan even if an appeal process is underway.}
+
+## Reported person's response to the plan
+
+{Provide details about how the community member responded to the proposed plan.}
+
+## Additional information gathered
+
+{List any other observations or notes as needed.}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct%20remediation%20record) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/guide_code-of-conduct-response-plan.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/guide_code-of-conduct-response-plan.md
new file mode 100644
index 00000000..d51565c1
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/guide_code-of-conduct-response-plan.md
@@ -0,0 +1,164 @@
+# Code of Conduct response plan template guide
+
+> Thank you for downloading this template from The Good Docs Project! Before using the template, read this template guide for information about how to complete each section. Want to explore more templates? Check them out in our [templates GitLab repository](https://gitlab.com/tgdp/templates).
+
+This is the guide that explains how to use the Good Docs Project Code of Conduct response plan, which is part of the Code of Conduct template set.
+
+The Code of Conduct template set includes:
+
+* **Code of Conduct** - Use to create and explain your community's Code of Conduct.
+* **Code of Conduct response plan** - Use to create and explain the policy your team will follow as you handle Code of Conduct incidents.
+* **Code of Conduct incident record** - A form that is filled out when a community moderator takes an incident report from a community member.
+* **Code of Conduct remediation record** - A form that is filled out when a community moderator meets with a community member to explain the consequences of a Code of Conduct violation.
+
+You might also consider using the `../our-team/template_our-team.md` template to let your community members know who they can contact to report a Code of Conduct violation. This document is useful beyond Code of Conduct violations. It is a core document that helps you clearly communicate who belongs to your open source project or organization.
+
+---
+
+## Why do I need a Code of Conduct and a response plan?
+
+See the `guide_code-of-conduct.md` for reasons to incorporate a Code of Conduct and response plan.
+
+## Content of the Code of Conduct response plan template
+
+The following sections provide guidance about how to fill out each section of the Code of Conduct response plan template.
+
+:information_source: The Code of Conduct response plan template includes boilerplate text that you can customize or adapt, use as-is, or completely replace with your own text. If you use the boilerplate text, make sure you replace the project name placeholders with your own project name.
+
+### About the "Introduction" section
+
+The introduction section explains the purpose of the response plan document.
+
+### About the "Community moderators" section
+
+In the *Community moderators* section, you can list the names of the community moderators or link to a document that lists the community moderators, such as a website that uses the [Our Team](../our-team/template_our-team.md) template.
+
+Alternatively, you could list the names of the community moderators and their preferred contact information, such as their Slack handles.
+You could also link to a dedicated email address or contact form.
+
+Remember to respect your community moderator's privacy by only including contact methods that go through official project channels, such as community forums or project-issued email accounts.
+Don't include personal email addresses or contact information.
+The goal is to strike a balance between making your moderators easy to contact while also respecting their privacy.
+
+### About the "Contacting a community moderator" section
+
+In the *Contacting a community moderator* section, provide clear instructions for the best way to contact the community moderators.
+Filling out this section will require some pre-work on your part to clearly think through how community moderators should be contacted.
+
+### About the "Community moderator values" section
+
+In this section, articulate the values that your community moderators should strive to uphold.
+You can customize the provided boilerplate text or write your own.
+
+### About the "Requirements for community moderators" section
+
+In this section, explain the eligibility requirements for your community moderators.
+Once again, this section will require some pre-work for you to think through what your community moderators will need to do to be prepared to serve in this role:
+
+* How should individuals be selected or nominated to serve in this role?
+* What qualifications should someone in this role have?
+* What training will be required to serve in this role?
+
+Community moderators do need training in handling Code of Conduct incidents in order to be effective in this role.
+
+Some training options and resources you can consider using:
+
+* **[The Code of Conduct book](https://frameshiftconsulting.com/resources/code-of-conduct-book/)** - This free book can act as a baseline guide for handling Code of Conduct incidents. Your community moderator team could possibly host a book club and go through the chapters together, discussing them as they go. The authors of this book also offer Code of Conduct training workshops.
+* **[Mozilla's Community Participation Guidelines Enforcement](https://mozilla.teachable.com/p/cpg-training-contributors)** - This free course was developed by Mozilla for Mozilla community moderators and only takes a few hours to complete. However, be aware that this course is not as comprehensive as your community may need. The training is also specific to Mozilla's Code of Conduct, although some of its principles are general enough to apply to many projects.
+* **[Otter Tech Code of Conduct Enforcement Training](https://otter.technology/code-of-conduct-training/)** - Otter Tech is a diversity and inclusion consulting firm that offers regular workshops. The course provides a general framework for how to respond to Code of Conduct violations and provides many opportunities to role-play and practice acting as a community moderator. The Otter Tech training is excellent, but expensive and is only offered in U.S. friendly time zones.
+* If there are other resources that we are not aware of, please [open an issue](https://github.com/thegooddocsproject/templates/issues) to let us know!
+
+In addition to these resources, we recommend holding regular practice sessions with your community moderators where you role-play what it would be like to handle an actual incident if one were to occur.
+Try creating a hypothetical situation and see if you can take it through the entire process to its conclusion.
+
+### About the "Community moderator terms of service" section
+
+In this section, describe your plan for rotating community moderators or limiting terms of service if needed.
+
+### About the "Reviewing the Code of Conduct" section
+
+In the *Reviewing the Code of Conduct* section, indicate your timetable for reviewing the Code of Conduct and supporting policy documents.
+
+Consider reviewing your Code of Conduct and your response plan on a yearly basis at least.
+An annual review can also be a good time to check that each community moderator is familiar with your Code of Conduct policies and that they have been sufficiently trained in handling Code of Conduct incidents.
+Ensure that someone in your community is responsible for regularly reviewing the Code of Conduct policies.
+If your community uses a calendar, add an event to your calendar to remind you to do the yearly review.
+
+### About the "Key terms used in this document" section
+
+This section explains the meaning of the terms used throughout the remainder of the document.
+You may change these terms if you'd rather use different ones.
+If you do change the terms, make sure you find and replace all instances of the old term in the document.
+
+### About the "Handling incident reports" section
+
+The *Handling incident reports* section includes several subsections.
+It makes up the main body of this document and explains how you will handle incident reports.
+
+The remediation process explained in this template was based on the Mozilla process for handling incidents.
+Feel free to adapt the process for your community if needed.
+Whatever you do, we want you to truly make this process your own.
+Take time to really think through the logistics of how to make this process work for your community.
+
+:information_source: All of the sections in the Code of Conduct response plan template includes boilerplate text that you can customize or adapt, use as-is, or completely replace with your own text. If you use the boilerplate text, make sure you replace the project name placeholders with your own project name.
+
+### About the "Overview" section
+
+The *Overview* section provides a brief overview of the different phases of handling a Code of Conduct incident.
+
+### About the "Listen" section
+
+The *Listen* section explains the policy and procedures for meeting with a Code of Conduct incident reporter to gather information about the Code of Conduct violation.
+
+At the end of this phase, the investigating moderator should fill out a [Code of Conduct incident record](../code-of-conduct-incident-record/template_code-of-conduct-incident-record.md).
+
+### About the "Triage" section
+
+The *Triage* section provides guidelines for assigning an initial severity and impact assessment.
+
+* **Severity** refers to the overall seriousness of the behavior and the risk that behavior will be repeated.
+* **Impact** refers to how public the incident was and the number of community members who were or who could have been impacted by the incident, especially members of marginalized communities.
+
+You may use your own assessment categories and definitions if preferred.
+
+### About the "Recommend" section
+
+The *Recommend* section provides guidelines for recommending a suggested response to the Code of Conduct incident.
+
+### About the "Respond" section
+
+The *Respond* section explains how to meet with the accused individual to deliver the suggested response and behavior modification plan.
+
+At the beginning of this phase, the investigating moderator should fill out the [Code of Conduct remediation record](../code-of-conduct-remediation-record/template_code-of-conduct-remediation-record.md).
+
+### About the "Resolve" section
+
+The *Resolve* section explains how to conclude the Code of Conduct investigation by filing the necessary paperwork for record-keeping purposes.
+
+It is important to record and store this documentation to enable the community moderators to identify and prevent potential repeated patterns of abuse in the community.
+
+### About the "Handling incident appeals" section
+
+The *Handling incident appeals* provides guidelines for handling incident appeals.
+
+Filling out this section will require some pre-work on your part to clearly think through which team should best handle appeals.
+
+### About the "Preventing conflicts of interest" section
+
+The *Preventing conflicts of interest* section explains the conditions that can be considered a conflict of interest and the steps that should be taken if a community moderator has a conflict of interest.
+
+## Additional resources
+
+The authors of this template cannot stress enough the important of ensuring your community moderators are trained in the protocol and best practices for handling Code of Conduct incidents.
+
+The following lists some of the resources for training your moderators that were mentioned earlier in this guide:
+
+* [The Code of Conduct book](https://frameshiftconsulting.com/resources/code-of-conduct-book/)
+* [Mozilla's Community Participation Guidelines Enforcement](https://mozilla.teachable.com/p/cpg-training-contributors)
+* [Otter Tech Code of Conduct Enforcement Training](https://otter.technology/code-of-conduct-training/)
+
+Once again, if there are other resources that we are not aware of, please [open an issue](https://github.com/thegooddocsproject/templates/issues) to let us know!
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct%20response%20plan%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/template_code-of-conduct-response-plan.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/template_code-of-conduct-response-plan.md
new file mode 100644
index 00000000..12ce0150
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/template_code-of-conduct-response-plan.md
@@ -0,0 +1,327 @@
+# {Organization name} Code of Conduct response plan
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_code-of-conduct-response-plan.md).
+
+---
+
+This document explains:
+
+* How to contact the current {Project name} community moderators to report a [Code of Conduct](code-of-conduct.md) incident.
+* The policies and procedures that community moderators should follow when responding to a Code of Conduct incident.
+* Additional governing policies for the community moderator team (also sometimes referred to as the "Code of Conduct committee").
+
+## Community moderators
+
+For a list of the current {Project name} community moderators and the best way to reach them, see [Community Moderators](our-team.md).
+You may contact any of these individuals to make a Code of Conduct incident report.
+
+{Instead of linking to a separate page, you could list the names of the community moderators and their preferred contact information.}
+
+## Contacting a community moderator
+
+You can contact a community moderator to make a Code of Conduct incident report or to discuss the process and options related to Code of Conduct incidents.
+To make an incident report, send a message to the community moderator that you have the best working relationship with and feel most comfortable talking.
+
+To contact a moderator, please {describe your preferred contact method, such as sending a direct private message on Slack or some other method}.
+Community moderators will respond as soon as they possibly can.
+They might also request a one-on-one meeting with you (such as a phone call or online video conference) to get more information about the incident.
+
+## Community moderator values
+
+Community moderators should strive to:
+
+* Occupy a position of trust within {Project name} community.
+* Be active listeners who can show empathy and understanding when meeting with an incident responder.
+* Respect the privacy of incident reporters or other potentially sensitive and private information they may have access to in this role.
+* Be fair and open-minded when investigating an incident and recommending a response.
+* Develop healthy self-care strategies to prevent burnout and reduce personal stress.
+
+## Requirements for community moderators
+
+The {Project name} community moderators play an important role in the community because they help ensure the community is healthy, vibrant, and welcoming to all contributors.
+Because of the crucial nature of this role, potential community moderators should be invested in the long-term health of the
+{Project name} community and should be willing to develop a set of communication skills that may require some formal training.
+For that reason, individuals who are interested in serving as community moderators must:
+
+* Commit to a day or half-day formal training in incident response skills within {required time period} of joining the moderator team. Formal training involves taking an online training course in incident response skills, mediation, or arbitration. Or it could also involve participating in an informal workshop in incident response skills led by a current {Project name} moderator. Upon joining the moderator team, the new moderator can work with other moderators to develop a training plan and ensure this training requirement is met.
+* Be recommended for the team by either another community moderator or a member of the {Project name} core team. Nominated individuals should demonstrate the values and qualities necessary to carry out the responsibilities of community moderators. Note that {Project name} community members may first volunteer for consideration and then seek a recommendation afterwards.
+* Be active contributors to the {Project name} who have participated in the community for at least three months. Contributions can include authoring pull requests, submitting issues, attending meetings regularly, and participating in {Project name} community forums.
+* Not be subject of an ongoing {Project name} Code of Conduct incident.
+
+## Community moderator terms of service
+
+The {Project name} community moderator team should consist of 3-5 community members at a given time.
+To prevent burnout, community moderators should serve for a recommended term limit of {time period}, unless there have been few or no incidents in that space of time.
+Community members should stagger terms of service to ensure there is some continuity on the team over time.
+Community moderators may return to serve second terms after a break from service.
+If possible, outgoing community moderators should recommend a replacement from the community.
+
+## Reviewing the Code of Conduct
+
+The Code of Conduct and this document (the Code of Conduct response plan) should be reviewed by the moderator team at least once a year, typically in {time period}, to ensure these documents are meeting the needs of the community.
+The {Project name} community will notify the community of any revisions by publicizing the revisions in the community's {communication platforms used by the community}.
+
+## Key terms used in this document
+
+This section provides a definition of key terms and roles that appear in the incident response policy that follows this section:
+
+* **Incident** - A behavior by a member of the {Project name} that allegedly violates the community [Code of Conduct](code-of-conduct.md). Also known as a "Code of Conduct incident" or "conduct violation."
+* **Incident report** - Begins when a member of the {Project name} reports behavior that violates the community Code of Conduct. The incident report refers to the violating behavior that is then investigated by community moderators. Also sometimes referred to as the "report."
+* **Incident reporter** - The person who reports a Code of Conduct violation to a community moderator. Also sometimes referred to as the "reporter."
+* **Handling an incident report** - The process of investigating and resolving an incident report as explained using the processes and guidelines in the subsequent sections. Also known as "investigating a report."
+* **Investigating moderator** - The community moderator who will handle the incident report and ensure the report moves through all six stages. Also known as the "investigator."
+* **Accused individual** - The accused individual is the person who is alleged to have violated the Code of Conduct.
+* **Escrowed reports** - An incident report where the reporter has not give permission to proceed with an investigation. If the reporter gives permission to keep the report "in escrow," these escrowed reports will not be acted upon until there is a second report of the same incident or a similar incident involving the same individual. The goal of an escrow report is to retain a record of incidents in case there is a pattern of misbehavior by the same individual.
+
+## Handling incident reports
+
+An incident report begins when a member of {Project name} contacts a community moderator to report an incident.
+The moderator who is contacted should handle the incident report and should try to respond as soon as possible.
+This moderator will become the investigating moderator.
+
+The investigating moderator may involve another community moderator as an additional investigator or as a replacement investigator under these conditions:
+
+* If the moderator who was contacted by the incident reporter does not feel comfortable investigating and handling the incident alone.
+* If the moderator cannot handle the incident in a timely manner and must ask a different moderator to investigate the incident report.
+* If the moderator needs to be recused because of a conflict of interest.
+
+If the moderator who was contacted by an incident reporter intends to involve an additional community moderator for support or as a replacement, they should first inform the incident reporter, explain the circumstances, and offer the opportunity to withdraw their incident report if they are uncomfortable having another moderator involved.
+
+To promote impartiality, if the incident reporter is a community moderator themselves, then a different community moderator must handle the report.
+See [#preventing-conflicts-of-interest](Preventing conflicts of interest) for more information.
+
+### Overview
+
+All incident reports have six stages:
+
+1. Listen
+2. Triage
+3. Recommend
+4. Respond
+5. Follow up
+6. Resolve
+
+See the following sections for more information about what occurs in each phase.
+
+### Listen
+
+During the listening phase, the investigating moderator will:
+
+* Listen to the incident reporter's explanation of the Code of Conduct violation.
+* Explain the available outcomes.
+* Obtain permission to proceed to the next steps in the investigation.
+* Fill out the {link to your [Code of Conduct incident record](code-of-conduct-incident-record.md)}. NOTE: This record can be filled out after taking the report if needed.
+
+Throughout the process, the investigating moderator will treat the reporter's identity as confidential and will only disclose their identity to other moderators on a need-to-know basis.
+
+The investigating moderator should talk directly to the person who reported the incident either through an online video conference or by phone.
+
+During this meeting, the investigating moderator should:
+
+* Note the reporter's name and contact information.
+* If possible, note the incident's date, time, and/or location.
+* Listen carefully to the incident reporter and get a complete understanding of the incident, its context, and the parties involved. The moderator should strive to listen with empathy and understanding. They should default to believing the incident responder.
+* Ask what the incident reporter would need in order to feel emotionally whole or restored. Explain the possible outcomes that are available, as provided in the [Code of Conduct](code-of-conduct.md) (correction, warning, temporary ban, permanent ban). However, the moderator should not make any direct promises for exactly how the report will be handled until the investigation is concluded.
+* Obtain permission from the incident reporter to proceed with the investigation. If permission is not granted, the investigator can offer to hold the incident report in escrow. Escrowed reports will not be acted upon until there is a second report of the same incident or a similar incident involving the same individual. The goal of escrow reports is to retain incident reports in case there is a pattern of misbehavior by the same individual.
+
+During or immediately after the meeting, the investigating moderator should:
+
+* Fill out the {link to your [Code of Conduct incident record](code-of-conduct-incident-record.md)} to ensure that all information from the meeting has been accurately captured. The investigating moderator should avoid over-documenting the incident: only document information required to inform the report resolution. Where possible, avoid documenting your opinion about the incident, or any information about individuals that is not relevant to the report.
+* File the incident record in the {describe where these files are kept}. If permission was not obtained, the incident report is kept in the incident record archives. If the incident reporter wanted to keep the report in escrow, the incident report is kept in the escrow incident report archives.
+* If permission was obtained, proceed with the rest of the investigation.
+
+If necessary, the moderator may need to conduct additional interviews with other corroborating witnesses or may have to review any additional recorded evidence of the incident (such as emails, documents, message transcripts, or chat histories).
+
+### Triage
+
+After completing the listening phase, the moderator should assign an initial risk and impact level to the incident using their best judgment based on the following guidelines.
+
+#### Severity levels
+
+Severity refers to the overall seriousness of the behavior and the risk that behavior will be repeated:
+
+| Severity level | +Definition | +Examples | +
|---|---|---|
| High | +
+
|
+
+
|
+
| Medium | +
+
|
+
+
|
+
| Low | +The incident is minor in nature and doesn't pose serious harm or risk of harm. | +
+
|
+
| Impact level | +Definition | +Examples | +
|---|---|---|
| High | +
+
|
+
+
|
+
| Low | +
+
|
+
+
|
+
| + | Contact support | +Contact us | +Support portal | +
|---|---|---|---|
| What kind of organization should use this content type? | +
+
|
+
+
|
+
+
|
+
| Who is their audience? | +
+
|
+
+
|
+
+
|
+
| What is their purpose? | +
+
|
+
+
|
+
+
|
+
| What is the end goal? | +
+
|
+
+
|
+
+
|
+
| Source material | +Best practice or section | +
| Understanding customer support and customer service | +Hiver teaches the history of customer support, the different components of this form of support, and how it is implemented. The article recommends using an omnichannel approach to customer support as it helps solve problems quickly and streamlines the customer support process, increasing customer loyalty. | +
| How to build an effective customer support knowledge base | +Zapier describes how to organize a help center, choose what to document on a customer support page, and create easy-to-understand content. The article also provides ample examples of popular websites and how they manage the different sections of their customer support pages. When it comes to creating digestible content, Zapier suggests using different forms of multimedia to convey explanations. | +
| How to create customer support content that rocks + | +This article contains an example of an eCommerce customer journey on a website to dive into different sections like product pages, FAQs, knowledge base or community, and blogs. Under each section, the article goes into detail about how to best deliver information to the user. A best practice that they recommend is adding customer ratings to make it easier for users to find solutions to their issues with a product. + | +
| 7 steps to improve your customer support strategy in 2024 | +This article provides steps on how businesses can improve customer support strategies. One of the points made is that customers gravitate towards authentic voices. With this advice in mind, the company's phone number is added to the contact support template. | +
| 8 Best Practices for Designing a Helpful Contact Page | +This article gives eight tips for creating an effective, user-centric, contact support. One of its best practices is to set expectations for response times, which is presented in the phone number subsection of the contact details section in the template. | +
| How Customer Self-Service Improves First Contact Resolution Rate | +This article describes the ways self-service options can improve a business's First Contact Resolution Rate (FCR). It stresses that user experience matters because the way users find information can determine the success of a product. For that reason, it suggests providing visual aids like a chat bubble icon or a contrasting button. With this in mind, the "Our Products" section of the contact support template encourages the use of product icons and hyperlinking them. | +
| 13 Actionable Ways to Improve CSAT and Keep it High | Fullview | +This article provides tips on how businesses can improve their low customer satisfaction score (CSAT). The "More Support" section in the contact support template was heavily inspired by the author's suggestion, "join where the customers frequently hangout". | +
| 7 proven ways to reduce customer churn rate | +This article describes 7 strategies businesses can decrease customer churn rate, which is the percentage of customers who no longer purchase a product. One key tip is to provide diverse sets of communication channels as customers more often want to solve the issue on their own before interacting with a support agent. With this in mind, the "Our Products" section is the first communication channel shown in the Contact Support template. | +
| 9 Types of Customer Service & Support Models - Whatfix | +This article describes different kinds of customer service models and their benefits and disadvantages. For example, it mentions that live chat support provides immediate responses to customers, which increases customer loyalty. For complex situations that might need something beyond live chat support, the article mentions the benefits of adding email as a communication option. With this in mind, the template contains both methods. | +
| 10 Types of Customer Service: And which one is the best for your business | +This article covers similar material to the previous article. However, it mentions additional contact support methods that aren't mentioned in the first one, such as virtual reality (VR). It also encourages businesses to base the types of support methods on their company's needs. As a result, the "Other Communications section" in the Contact Support template has the suggestion for users to delete the content that does not suit their company. | +
| Contact us page design: 11 best practices | +This article describes 11 best practices for designing a contact us page. One of the tips mentioned adding a simple form that users can fill out to request support. It was not included in the final template because it would require front-end development and design. However, an intake form could benefit some organizations. | +
| Customer Experience Strategy of Apple - Revealing the Secret | +This article goes in depth on how Apple formulated its customer support strategy. It is used as an example in the "How to do research for your company's contact support page" section of the process document to describe how a company's size influences their decision about which communication channels to use in their contact support page. | +
| Community-Driven Support with Pieces for Developers | +This blog post talks about the start-up company's community-driven approach to track and solve problems users have with the product. Like the article about Apple's customer service strategy, it has been used in the "How to do research for your company's contact support page" section of the process documentation to describe how a company's size influences their decision about which communication channels to use in their contact support page. | +
| Free plan or basic license level | +Pro plan or next license level | +
|---|---|
| Free | +{Cost per month/annually} | +
+
|
+
+
|
+
| + Issue + | ++ Solution + | +
| + {Describe the issue here} + | ++ {Write solution here} + | +
| + {Describe the issue here} + | ++ {Write solution here} + | +
| + {Describe the issue here} + | ++ {Write solution here} + | +
| Deliverable | +Example filename and purpose | +Use case | +
|---|---|---|
| Template file | +template_content-type.md The template file is the raw template for the content type. It provides a rough outline of the suggested content and a few embedded writing tips for how to fill in the different sections of the template. |
+ Used by Developer-Writer Darby to create better documentation. "Just give me something easy I can fill out and nothing more!" |
+
| Template guide | +guide_content-type.md This guide provides a deeper explanation of how to fill in the template. It provides a lightweight introduction to the purpose of this documentation and explains how to fill in each section of the document. Any information that is essential to filling out the template should be noted in this guide. |
+ Used by Developer-Writer Darby to fill in the template. "When I get stuck, I'll refer to the guide to help me out. Keep this guide simple and lightweight for me!" |
+
| Resources | +resources_content-type.md This document includes the resources (books, blog entries, guides) that the templateer used during the research phase of creating the template. The templateer can also include high quality examples of that content type that served as inspiration for the template. Template contributors should use this document to ethically cite their sources and give credit where credit is due, in harmony with our Code of Conduct. |
+ Used by Templateer Terry to ethically cite sources. Also used by Doc System Owner Olly to understand the theory that informs this template on a deeper level. "If I want to customize this template for my project, I can use this document to make informed changes. If I need to maintain this template and make changes to it in the future, I can understand the thinking that went into the template originally." |
+
| Process | +process_content-type.md This document explains best practices for researching, writing, and maintaining this content type. As a minimum viable document, it can be very lightweight and include simple content about researching, writing, and maintaining that content type---such as a paragraph each. If a more detailed explanation is needed for that content type, it can go deeper. |
+ Used by Developer-Writer Darby and Doc System Owner Olly to learn about any unique challenges or best practices when writing this content type. "Help me understand best practices and avoid common mistakes." |
+
| Example | +example_content-type.md After a template project is complete, our Chronologue working group will create an example of the template. While creating the example, the Chronologue group will test whether your template is user-friendly and can be used in a real documentation project. If you're still involved in the community during this phase, these team members might reach out to you for feedback or to collaborate on possible template revisions. NOTE: Examples are required, but they are created after the template writing process. |
+ Used by Developer-Writer Darby and Doc System Owner Olly to see what this content type looks like in a practical context. "Help me see an example of this template in action so that I can see what 'good enough' looks like." |
+
| For the project | +It gives The Good Docs Project a way to ethically cite our sources and give credit where credit is due. | +
|---|---|
| For the template contributor | +It gives them a starting point and ending point (a goal + a final deliverable) for the research phase. | +
| For template readers who choose to read the process document | +It explains the theory behind why certain decisions were made to the template, which can help them understand why the template author made certain design decisions. It can also help them know how they can customize the template to their organization's needs. | +
| Future template maintainers | +This document helps them understand why a template was developed a certain way. It will help them decide whether to change the template in the future (or not). | +
This is example for a terminology system.
+ +| Term | +Definition | +Usage | +Part of speech | +Source | +Notes for translation and localization | +Updates | +
|---|---|---|---|---|---|---|
| access control list | +An access control list (ACL), with respect to a computer file system, is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. | +
+
|
+ Noun | +Wikipedia.org | +When you have enabled access control on client data, the access control lists (ACLs) for the data are also included in the backup. | ++ N/A + | +
| allowlist, allow list | +a list with allowed values | +
+
|
+ Noun | +Wikipedia.org | +N/A | ++ N/A + | +
| application programming interface | +A set of definitions and protocols for building and integrating application software. | +
+
|
+ Noun | +Wikipedia.org | +Representational State Transfer, or REST, is a software architecture style for building scalable web services, and an application programming interface, or API, is a set of routines, protocols, and tools for building software applications. | ++ N/A + | +
| denylist, deny list | +a list of not approved values | +
+
|
+ Noun | +N/A | +N/A | ++ N/A + | +
| text box | +A text box in a UI | +
+
|
+ Noun | +N/A | +In the User Name box, type the Active Directory user account. | ++ 12/02/2023, update from 'text field' to 'text box' because of the size of the UI (box is shorter) + | +
| Glossary | +Terminology system | +
| A dictionary of terms and definitions, often including abbreviations and acronyms. | +A terminology system is the collection of terms that defines a common language for a project:
+
|
+
| A simple list of terms, their definitions, and related notes or examples. + | +A complex list of terms that goes beyond a definition and notes for each term.
+ This information can include:
+
|
+
A list of terms created by one entity, intended for use by a specific audience.
+ Examples:
+
|
+ A list of terms shared between multiple entities or organizations, requiring information relevant to each.
+ Examples:
+
|
+
| Term | +Definition | +Usage | +Part of speech | +Source | +Notes for translation and localization | +Updates | +
|---|---|---|---|---|---|---|
| + | + |
+
|
+ + | + | + |
+
|
+
| Source material + | +Best practice or section + | +
| Writing a great troubleshooting guide for software applications - indoc.pro + | +This source provides a great overview of writing troubleshooting guides. Its information about the steps of writing a troubleshooting guide was used to format the steps in the template. + | +
| 5 Steps To Create Interactive Troubleshooting Guides For Customer Service + | +This article is a great resource to help make troubleshoot guides more interactive and engaging for users. It was the inspiration for the Symptoms and Issues sections of the template. + | +
| Troubleshooting Article Template | Atlassian + | +This resource is a great example of a troubleshooting guide. Its the main inspiration for the Introduction section and Related Articles sections of the template. + | +
| Benefits | +Detriments | +
|---|---|
|
+ Documentation planned with effective user personas are more likely to have readers who: +
|
+
+ Documentation planned without effective user personas are more likely to have readers who: +
|
+