From 9591998b4b36465cdcc097bdfdd48f8fcbbc49f3 Mon Sep 17 00:00:00 2001 From: Inline Pizza <249805557+InlinePizza@users.noreply.github.com> Date: Tue, 28 Apr 2026 13:06:17 -0700 Subject: [PATCH 1/3] Add Good Docs reference templates --- AGENTS.md | 13 + meta/reference/AGENTS.md | 7 + meta/reference/README.md | 11 + .../.gitignore | 13 + .../.gitlab-ci.yml | 16 + .../.gitlab/issue_templates/missing-files.md | 39 + .../.gitlab/issue_templates/new-pack.md | 26 + .../issue_templates/new-tactic-article.md | 33 + .../.gitlab/issue_templates/new-template.md | 55 + .../template-merge-request.md | 45 + .../.gitpod.yml | 5 + .../.markdownlint-cli2.jsonc | 13 + .../ADOPTERS.md | 31 + .../CODE_OF_CONDUCT.md | 3 + .../CONTRIBUTING.md | 431 +++++ .../good-docs-project-template-1.5.0/DCO.txt | 36 + .../good-docs-project-template-1.5.0/DEI.md | 3 + .../GOVERNANCE.md | 3 + .../good-docs-project-template-1.5.0/LICENSE | 7 + .../README.md | 215 +++ .../SECURITY.md | 3 + .../STYLE-GUIDE.md | 1434 +++++++++++++++++ .../SUPPORT.md | 10 + .../guide_api-getting-started.md | 85 + .../process_api-getting-started.md | 55 + .../resources_api-getting-started.md | 22 + .../template_api-getting-started.md | 105 ++ .../api-reference/example_api-reference.md | 4 + .../api-reference/guide_api-reference.md | 271 ++++ .../api-reference/template_api-reference.md | 186 +++ .../bug-report/guide_bug-report.md | 103 ++ .../bug-report/template_bug-report.md | 58 + .../changelog/guide_changelog.md | 146 ++ .../changelog/process_changelog.md | 63 + .../changelog/resources_changelog.md | 28 + .../changelog/template_changelog.md | 94 ++ .../guide_code-of-conduct-incident-record.md | 86 + ...emplate_code-of-conduct-incident-record.md | 54 + ...uide_code-of-conduct-remediation-record.md | 87 + ...late_code-of-conduct-remediation-record.md | 82 + .../guide_code-of-conduct-response-plan.md | 164 ++ .../template_code-of-conduct-response-plan.md | 327 ++++ .../code-of-conduct/guide_code-of-conduct.md | 137 ++ .../template_code-of-conduct.md | 136 ++ .../concept/example_concept.md | 4 + .../concept/guide_concept.md | 253 +++ .../concept/process_concept.md | 241 +++ .../concept/resources_concept.md | 56 + .../concept/template_concept.md | 109 ++ .../contact-support/guide_contact-support.md | 173 ++ .../process_contact-support.md | 55 + .../resources_contact-support.md | 84 + .../template_contact-support.md | 110 ++ .../example_contributing-guide.md | 4 + .../guide_contributing-guide.md | 198 +++ .../template_contributing-guide.md | 126 ++ .../glossary/guide_glossary.md | 92 ++ .../glossary/process_glossary.md | 118 ++ .../glossary/resources_glossary.md | 34 + .../glossary/template_glossary.md | 13 + .../how-to/guide_how-to.md | 174 ++ .../how-to/template_how-to.md | 59 + .../images/importance.png | Bin 0 -> 188284 bytes .../images/voiceNtone.png | Bin 0 -> 41892 bytes .../index.json | 663 ++++++++ .../guide_installation-guide.md | 158 ++ .../process_installation-guide.md | 36 + .../resources_installation-guide.md | 30 + .../template_installation-guide.md | 192 +++ .../our-team/guide_our-team.md | 148 ++ .../our-team/template_our-team.md | 107 ++ .../quickstart/guide_quickstart.md | 160 ++ .../quickstart/template_quickstart.md | 91 ++ .../readme/example_readme.md | 4 + .../readme/guide_readme.md | 147 ++ .../readme/process_readme.md | 70 + .../readme/resources_readme.md | 27 + .../readme/template_readme.md | 151 ++ .../reference/guide_reference.md | 71 + .../reference/process_reference.md | 36 + .../reference/resources_reference.md | 26 + .../reference/template_reference.md | 33 + .../release-notes/guide_release-notes.md | 303 ++++ .../release-notes/process_release-notes.md | 167 ++ .../release-notes/resources_release-notes.md | 44 + .../release-notes/template_release-notes.md | 90 ++ .../style-guide/guide_style-guide.md | 188 +++ .../style-guide/template_style-guide.md | 148 ++ .../template_deliverables.md | 167 ++ .../example_terminology-system.csv | 15 + .../example_terminology-system.htm | 104 ++ .../guide_terminology-system.md | 181 +++ .../process_terminology-system.md | 34 + .../resources_terminology-system.md | 33 + .../template_terminology-system.csv | 1 + .../template_terminology-system.htm | 43 + .../troubleshooting/guide_troubleshooting.md | 62 + .../process_troubleshooting.md | 35 + .../resources_troubleshooting.md | 44 + .../template_troubleshooting.md | 42 + .../tutorial/guide_tutorial.md | 172 ++ .../tutorial/template_tutorial.md | 85 + .../user-personas/UserPersonaAvatar.png | Bin 0 -> 18738 bytes .../user-personas/guide_user-personas.md | 228 +++ .../user-personas/process_user-personas.md | 200 +++ .../user-personas/resources_user-personas.md | 48 + .../user-personas/template_user-personas.md | 187 +++ .../writing-tips.md | 60 + 108 files changed, 11479 insertions(+) create mode 100644 AGENTS.md create mode 100644 meta/reference/AGENTS.md create mode 100644 meta/reference/README.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitignore create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitlab-ci.yml create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/missing-files.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-pack.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-tactic-article.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-template.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitlab/merge_request_templates/template-merge-request.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/.gitpod.yml create mode 100644 meta/reference/good-docs-project-template-1.5.0/.markdownlint-cli2.jsonc create mode 100644 meta/reference/good-docs-project-template-1.5.0/ADOPTERS.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/CODE_OF_CONDUCT.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/CONTRIBUTING.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/DCO.txt create mode 100644 meta/reference/good-docs-project-template-1.5.0/DEI.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/GOVERNANCE.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/LICENSE create mode 100644 meta/reference/good-docs-project-template-1.5.0/README.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/SECURITY.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/STYLE-GUIDE.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/SUPPORT.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-getting-started/guide_api-getting-started.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-getting-started/process_api-getting-started.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-getting-started/resources_api-getting-started.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-getting-started/template_api-getting-started.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-reference/example_api-reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-reference/guide_api-reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/api-reference/template_api-reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/bug-report/guide_bug-report.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/bug-report/template_bug-report.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/changelog/guide_changelog.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/changelog/process_changelog.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/changelog/resources_changelog.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/changelog/template_changelog.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/guide_code-of-conduct-incident-record.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct-incident-record/template_code-of-conduct-incident-record.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/guide_code-of-conduct-remediation-record.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct-remediation-record/template_code-of-conduct-remediation-record.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/guide_code-of-conduct-response-plan.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct-response-plan/template_code-of-conduct-response-plan.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct/guide_code-of-conduct.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/code-of-conduct/template_code-of-conduct.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/concept/example_concept.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/concept/guide_concept.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/concept/process_concept.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/concept/resources_concept.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/concept/template_concept.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contact-support/guide_contact-support.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contact-support/process_contact-support.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contact-support/resources_contact-support.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contact-support/template_contact-support.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contributing-guide/example_contributing-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contributing-guide/guide_contributing-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/contributing-guide/template_contributing-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/glossary/guide_glossary.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/glossary/process_glossary.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/glossary/resources_glossary.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/glossary/template_glossary.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/how-to/guide_how-to.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/how-to/template_how-to.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/images/importance.png create mode 100644 meta/reference/good-docs-project-template-1.5.0/images/voiceNtone.png create mode 100644 meta/reference/good-docs-project-template-1.5.0/index.json create mode 100644 meta/reference/good-docs-project-template-1.5.0/installation-guide/guide_installation-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/installation-guide/process_installation-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/installation-guide/resources_installation-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/installation-guide/template_installation-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/our-team/guide_our-team.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/our-team/template_our-team.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/quickstart/guide_quickstart.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/quickstart/template_quickstart.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/readme/example_readme.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/readme/guide_readme.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/readme/process_readme.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/readme/resources_readme.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/readme/template_readme.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/reference/guide_reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/reference/process_reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/reference/resources_reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/reference/template_reference.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/release-notes/guide_release-notes.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/release-notes/process_release-notes.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/release-notes/resources_release-notes.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/release-notes/template_release-notes.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/style-guide/guide_style-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/style-guide/template_style-guide.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/template_deliverables.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.csv create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.htm create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/guide_terminology-system.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/process_terminology-system.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/resources_terminology-system.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.csv create mode 100644 meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.htm create mode 100644 meta/reference/good-docs-project-template-1.5.0/troubleshooting/guide_troubleshooting.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/troubleshooting/process_troubleshooting.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/troubleshooting/resources_troubleshooting.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/troubleshooting/template_troubleshooting.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/tutorial/guide_tutorial.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/tutorial/template_tutorial.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/user-personas/UserPersonaAvatar.png create mode 100644 meta/reference/good-docs-project-template-1.5.0/user-personas/guide_user-personas.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/user-personas/process_user-personas.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/user-personas/resources_user-personas.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/user-personas/template_user-personas.md create mode 100644 meta/reference/good-docs-project-template-1.5.0/writing-tips.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 00000000..b844a24c --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,13 @@ +# Agent Instructions + +## Good Docs Project templates + +The Good Docs Project template bundle is stored at: + +`meta/reference/good-docs-project-template-1.5.0/` + +Use these files as read-only reference material when planning documentation information architecture, page types, explanation flow, templates, and writing patterns. + +Do not edit, rewrite, reformat, rename, delete, or regenerate files under `meta/reference/good-docs-project-template-1.5.0/` unless the user explicitly asks to update the vendored template bundle itself. + +When applying recommendations from the templates, make changes in the Promptless documentation source files instead, such as files under `src/content/docs/`. diff --git a/meta/reference/AGENTS.md b/meta/reference/AGENTS.md new file mode 100644 index 00000000..9f4306da --- /dev/null +++ b/meta/reference/AGENTS.md @@ -0,0 +1,7 @@ +# Agent Instructions for Reference Material + +This directory contains reference material for humans and agents. + +Files in this directory are not website source content and are not generated output. Treat third-party reference bundles here as immutable inputs. + +The Good Docs Project template bundle at `good-docs-project-template-1.5.0/` is read-only. You may inspect and cite it when making documentation recommendations, but do not edit files in that directory unless the user explicitly asks to update the vendored template bundle itself. diff --git a/meta/reference/README.md b/meta/reference/README.md new file mode 100644 index 00000000..a2a89d1a --- /dev/null +++ b/meta/reference/README.md @@ -0,0 +1,11 @@ +# Reference Material + +This directory contains source and reference material that can inform documentation strategy, information architecture, and writing patterns. + +## Good Docs Project template 1.5.0 + +`good-docs-project-template-1.5.0/` contains the downloaded Good Docs Project template bundle. + +Use it as a reference for documentation page types such as concept docs, quickstarts, how-to guides, tutorials, reference docs, troubleshooting docs, release notes, changelogs, glossaries, and style guides. + +Do not edit the template bundle as part of normal Promptless documentation changes. Apply useful patterns from the templates to the Promptless docs source files instead. diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitignore b/meta/reference/good-docs-project-template-1.5.0/.gitignore new file mode 100644 index 00000000..a343ea17 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitignore @@ -0,0 +1,13 @@ +# See https://help.github.com/articles/ignoring-files/ for more about ignoring files. + +# Misc +.vscode +.DS_Store +*.pem + +# Local env files +.env +.env.local +.env.development.local +.env.test.local +.env.production.local \ No newline at end of file diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitlab-ci.yml b/meta/reference/good-docs-project-template-1.5.0/.gitlab-ci.yml new file mode 100644 index 00000000..e8d233fe --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitlab-ci.yml @@ -0,0 +1,16 @@ +stages: + - ekline-pr-review + +ekline-pr-review-job: + stage: ekline-pr-review + image: ghcr.io/ekline-io/ekline-ci-cd:v6 + rules: + - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_LABELS =~ /ekline/i' + script: + - echo "Running EkLine" + variables: + INPUT_EK_TOKEN: $EK_TOKEN + INPUT_GITLAB_TOKEN: $GITLAB_API_TOKEN + INPUT_REPORTER: 'gitlab-mr-discussion' + # INPUT_FILTER_MODE: 'added' + # INPUT_IGNORE_RULE: "EK00001,EK00004" # Optional diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/missing-files.md b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/missing-files.md new file mode 100644 index 00000000..eb577c4b --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/missing-files.md @@ -0,0 +1,39 @@ +The [{content type} template](link-to-file) is missing the following template file deliverables: + +* [ ] **Template resources** - Includes the resources consulted during the research phase of creating the template. Also includes high quality examples of that content type that served as inspiration for the template. +* [ ] **Template process** - Explains best practices for researching, writing, and maintaining this content type. + +Templateers who work on this issue will need to create these template file deliverables. See the [Template deliverables guide](https://gitlab.com/tgdp/templates/-/blob/main/template-deliverables.md) for guidance about these files. You can also look at examples of other templates in the repository to see examples of each template file. Be aware that some templates might be missing some files. + +## Link to Google Doc drafts +Our project composes rough draft of templates in Google Docs that are owned and maintained by the project leads. The Good Docs Project owns these files so that we can maintain our project archive and history. With that in mind, the project has pre-generated Google Doc files for you to use as you are researching and drafting your template project. These files include a starting point for the structure of each file that should help you as you draft the documents: + +* [ ] **Template resources** - [{Content type} resources](link-to-Google-Doc) +* [ ] **Template process** - [{Content type} process](link-to-Google-Doc) + +Bookmark these drafts and use them as you work on your project. + +See the next section for more information about these files. + +## Definition of done +A template project is considered complete when the missing template file deliverables have been added to the template. + +### Template writing phases +Although it is optional, we recommend working these missing files through each template writing phase. + +See the [Templates CONTRIBUTING guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md) for guidance about these phases. You can also receive help from your working group leads and members about how to move your issue through each phase. + +### Required template deliverables +To be considered complete, a template project must have the missing files. + +## Want to work on this template? +Great! Make sure you follow our contributing guidelines: + +1. Check that the template is unassigned. If it is assigned, you might be able to work with the current assignee as a paired writer. +2. Join The Good Docs Project by attending a [Welcome Wagon meeting](https://thegooddocsproject.dev/welcome/). You will get access to The Good Docs Project Slack workspace after scheduling or attending this meeting. +3. Read the [Templates CONTRIBUTING guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md). +4. You are strongly encouraged to join one of the [working groups](https://thegooddocsproject.dev/working-group/) to get valuable support from the community such as mentorship, Git training, and helpful feedback as you contribute to your first template. +5. Request access to the `templates` repository by joining the #tech-requests channel in Slack and posting a request. +6. [Assign yourself to an issue](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#assignee) for the template that you want to work on. +7. Add the `Template phase:: Research` label to the issue. +8. Attend your template working group regularly to receive support and resources for your project. diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-pack.md b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-pack.md new file mode 100644 index 00000000..6d398901 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-pack.md @@ -0,0 +1,26 @@ +{Add a description of the template pack, use case, and intended audience.} + +See [Template packs](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md#template-packs) for more information about what a template pack is. + +## Templates that are planned for this template pack +The following templates are planned for this template pack: + +* [ ] {Template name} - {issue link} +* [ ] {Template name} - {issue link} +* [ ] {Template name} - {issue link} +* [ ] {Template name} - {issue link} +* [ ] {Template name} - {issue link} + +## Definition of done +A template pack can be released as soon as it has at least at least one of each template that is: + +* Task-oriented +* Concept-oriented +* Reference-oriented + +The template pack can be released if it has one of each of these types of templates, but the issue can't be closed until all planned templates are complete. + +A template pack is released when it is included on our README file or our website. All new or enhanced template packs should be included in the release notes. + +## Want to work on this template pack? +Great! The best way to contribute is to work on one of the templates that are part of the pack. See the issue for that specific template for more information. diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-tactic-article.md b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-tactic-article.md new file mode 100644 index 00000000..b785c63f --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-tactic-article.md @@ -0,0 +1,33 @@ +{Add a description of the tactic article topic.} + +{Optional: List any resources the templateer might consult while creating the article.} + +See [The Good Docs Project tactic articles](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md#the-good-docs-project-tactic-articles) for more information about what a tactic article is. + +## Definition of done +Tactic articles are written using the same processes, workflows, and teams as a template project. However, they are published on the website instead of in the template repository. + +A tactic article template project is considered complete when it has progressed through all the template writing phases and when it has been merged into the website. + +### Tactic article writing phases +To be considered complete, a tactic article must progress through each template writing phase: + +* [ ] **Research phase** - When you first start a tactic article, you begin by researching examples and best practices for that article. This phase ends when you create your *resources* document for that article. +* [ ] **Rough draft phase** - After you conclude your research, you create a draft of your tactic article in Google Docs. This phase ends when you schedule your drafts for review by other members of your working group or community. +* [ ] **Community review phase** - When your tactic article is ready for review, your working group lead will schedule 1-2 sessions in the community where other members of the project will review and provide feedback on your template files deliverables. This phase ends after you incorporate the feedback into your draft and your drafts are in a final state. +* [ ] **Editorial review phase** - When your draft is in a state where you feel it is ready to get merged in, you can work with your working group lead to request an editorial team review. The template editorial team is composed of experienced members of the project who review your template project to ensure that it follows best practices for technical writing, has no major organization or structural issues, has no obvious gaps or missing content, is consistent with our style guide. +* [ ] **Final review phase** - When your tactic article is in a final state, you convert it from Google Docs into Markdown and [open a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html) to add your template to the website repository. The template leads will review the template and possibly request additional changes. This phase ends when the article is merged into the repository. + +See the [Templates CONTRIBUTING guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md) for guidance about these phases. You can also receive help from your working group leads and members about how to move your template project through each phase. + +## Want to work on this tactic article? +Great! Make sure you follow our contributing guidelines: + +1. Check that the article is unassigned. If it is assigned, you might be able to work with the current assignee as a paired writer. +2. Join The Good Docs Project by attending a [Welcome Wagon meeting](https://thegooddocsproject.dev/welcome/). You will get access to The Good Docs Project Slack workspace after scheduling or attending this meeting. +3. Read the [Templates CONTRIBUTING guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md). +4. You are strongly encouraged to join one of the [working groups](https://thegooddocsproject.dev/working-group/) to get valuable support from the community such as mentorship, Git training, and helpful feedback as you contribute to your first template. +5. Request access to the `templates` and `website` repository by joining the #tech-requests channel in Slack and posting a request. +6. [Assign yourself to an issue](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#assignee) for the article that you want to work on. +7. Add the `Template phase:: Research` label to the issue. +8. Attend your template working group regularly to receive support and resources for your project. diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-template.md b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-template.md new file mode 100644 index 00000000..f02dcf03 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitlab/issue_templates/new-template.md @@ -0,0 +1,55 @@ +{Add a description of the template content type.} + +{Optional: List any resources the templateer might consult while creating the template.} + +## Link to Google Doc drafts +Our project composes rough draft of templates in Google Docs that are owned and maintained by the project leads. The Good Docs Project owns these files so that we can maintain our project archive and history. With that in mind, the project has pre-generated Google Doc files for you to use as you are researching and drafting your template project. These files include a starting point for the structure of each file that should help you as you draft the documents: + +* [ ] **Template file** - [{Content type} file](link-to-Google-Doc) +* [ ] **Template guide** - [{Content type} guide](link-to-Google-Doc) +* [ ] **Template resources** - [{Content type} resources](link-to-Google-Doc) +* [ ] **Template process** - [{Content type} process](link-to-Google-Doc) + +Bookmark these drafts and use them as you work on your project. + +See the next section for more information about these files. + +## Definition of done +A template project is considered complete when it has progressed through all the template writing phases and when it has all the required template file deliverables. + +### Template writing phases +To be considered complete, a template project must progress through each template writing phase: + +* [ ] **Research phase** - When you first start a template project, you begin by researching examples and best practices for that template project. This phase ends when you create your *resources* document for that template. +* [ ] **Rough draft phase** - After you conclude your research, you create drafts of your template file deliverables in Google Docs. This phase ends when you schedule your drafts for review by other members of your working group or community. +* [ ] **Community review phase** - When your template project is ready for review, your working group lead will schedule 1-2 sessions in the community where other members of the project will review and provide feedback on your template files deliverables. This phase ends after you incorporate the feedback into your draft and your drafts are in a final state. +* [ ] **Editorial review phase** - When your draft is in a state where you feel it is ready to get merged in, you can work with your working group lead to request an editorial team review. The template editorial team is composed of experienced members of the project who review your template project to ensure that it follows best practices for technical writing, has no major organization or structural issues, has no obvious gaps or missing content, is consistent with our style guide. +* [ ] **Final review phase** - When your template is in a final state, you convert it from Google Docs into Markdown and [open a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html) to add your template to the templates repository. The template leads will review the template and possibly request additional changes. This phase ends when the template is merged into the repository. + +After the final review phase, the template project is considered done. However, be aware that after it is merged, the template then goes to the Chronologue working group for testing. They will make a high quality example of the template and they may make additional changes to the template to improve its usability. + +See the [Templates CONTRIBUTING guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md) for guidance about these phases. You can also receive help from your working group leads and members about how to move your template project through each phase. + +### Required template deliverables +To be considered complete, a template project must have the following four files: + +* [ ] **Template file** - The raw template for the content type. +* [ ] **Template guide** - Provides a deeper explanation of how to fill in the template. +* [ ] **Template resources** - Includes the resources consulted during the research phase of creating the template. Also includes high quality examples of that content type that served as inspiration for the template. +* [ ] **Template process** - Explains best practices for researching, writing, and maintaining this content type. + +After a template project is complete, our Chronologue working group will create an example of the template. + +See the [Template deliverables guide](https://gitlab.com/tgdp/templates/-/blob/main/template-deliverables.md) for guidance about these files. You can also look at examples of other templates in the repository to see examples of each template file. Be aware that some templates might be missing some files. + +## Want to work on this template? +Great! Make sure you follow our contributing guidelines: + +1. Check that the template is unassigned. If it is assigned, you might be able to work with the current assignee as a paired writer. +2. Join The Good Docs Project by attending a [Welcome Wagon meeting](https://thegooddocsproject.dev/welcome/). You will get access to The Good Docs Project Slack workspace after scheduling or attending this meeting. +3. Read the [Templates CONTRIBUTING guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md). +4. You are strongly encouraged to join one of the [working groups](https://thegooddocsproject.dev/working-group/) to get valuable support from the community such as mentorship, Git training, and helpful feedback as you contribute to your first template. +5. Request access to the `templates` repository by joining the #tech-requests channel in Slack and posting a request. +6. [Assign yourself to an issue](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#assignee) for the template that you want to work on. +7. Add the `Template phase:: Research` label to the issue. +8. Attend your template working group regularly to receive support and resources for your project. diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitlab/merge_request_templates/template-merge-request.md b/meta/reference/good-docs-project-template-1.5.0/.gitlab/merge_request_templates/template-merge-request.md new file mode 100644 index 00000000..b0a0f810 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitlab/merge_request_templates/template-merge-request.md @@ -0,0 +1,45 @@ +# Merge request summary + +{Describe the purpose of your merge request. For example: "Adds the abc template to the repository."} + +IMPORTANT: The next three sections in this checklist should be filled out by the template contributor at the time they submit this request. Merge requests can only be merged when all boxes are checked. + +## Which issue does this merge request fix or reference? + +This merge request: + +* Resolves: {#issue-number} {Choose this option if this MR will close the issue and link to issue} +* Relates to: {#issue-number} {Choose this option if this MR only references an issue for context but does not fully resolve it} + +## Working group and contributor details + +* **Additional template contributors:** {If you did not author the template alone, list the names of your fellow contributors here and assign them to this merge request} +* **Template working group:** {Delete any that don't apply:} Team Alpaca / Team Dolphin / Team Macaw +* **Template working group lead(s):** {List name of working group lead(s) that approved this template project to move to the merge request phase} + +By checking this box, I certify that: + +* [ ] My template project received one or more community review and was approved by my working group lead(s) to move to the next phase. +* [ ] My template project received one or more editorial review by the template editorial team and was approved by my working group lead(s) to move to the next phase. +* [ ] My template was approved by my working group lead(s) to move to the merge request phase. + +## Template deliverables requirements + +By checking this box, I certify that: + +* [ ] Template file is present. +* [ ] Template guide is present. +* [ ] Template resources is present. +* [ ] Template process is present. + +## Checklist for reviewers + +IMPORTANT: The rest of this checklist should only be filled out by authorized Good Docs Project template maintainers with merge rights. If you are the individual template contributor, do not fill out the rest of the fields or check the boxes. + +NOTE: Merge requests can only be merged when all boxes are checked. + +* [ ] Verify that all required files are present. +* [ ] Verify that this template project received all required reviews. +* [ ] Verify Markdown renders correctly. +* [ ] Verify the raw Markdown to ensure it is well-formed and follows best practices. +* [ ] Verify the files are free from grammar errors and typos. \ No newline at end of file diff --git a/meta/reference/good-docs-project-template-1.5.0/.gitpod.yml b/meta/reference/good-docs-project-template-1.5.0/.gitpod.yml new file mode 100644 index 00000000..176495cb --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.gitpod.yml @@ -0,0 +1,5 @@ + +vscode: + extensions: + - DavidAnson.vscode-markdownlint + - carlocardella.vscode-texttoolbox diff --git a/meta/reference/good-docs-project-template-1.5.0/.markdownlint-cli2.jsonc b/meta/reference/good-docs-project-template-1.5.0/.markdownlint-cli2.jsonc new file mode 100644 index 00000000..697ae12e --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/.markdownlint-cli2.jsonc @@ -0,0 +1,13 @@ +{ + "config": { + "MD024": false, + "MD033": false, + "MD034": false, + "MD036": false, + "MD041": false, + "MD051": false + }, + "ignores": [ + ".gitlab/**/*.md" + ] +} \ No newline at end of file diff --git a/meta/reference/good-docs-project-template-1.5.0/ADOPTERS.md b/meta/reference/good-docs-project-template-1.5.0/ADOPTERS.md new file mode 100644 index 00000000..4a11a8e0 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/ADOPTERS.md @@ -0,0 +1,31 @@ +# The Good Docs Project Adopters + +If you're using The Good Docs Project and want to add your organization to this list, see: + +- [Add your organization to the list of Good Docs Adopters](#add-your-organization-to-the-list-of-Good-Docs-Adopters) +- [Add a logo to our website](#add-a-logo-to-our-website) + +## Adopters + +{Your logo here!} + +## Success stories + +The following is a list of adopters of The Good Docs Project templates that have +publicly shared the details of how they use it. + +### [{Your organization name and link here}](https://example.com) + +{Tell us how you use our templates.} + +## Add your organization to the list of Good Docs Adopters + +If you are using The Good Docs Project templates and resources and would like to be included in the list of `Good Docs Adopters`: + +1. Open a new merge request against this repository. +2. Add a PNG or SVG version of your logo to the `images` directory in this repo. Name the image file something that reflects your company. For example, if your company is called Acme, name the image `acme.png`. +3. Optional: Add a new seciton to the `Success Stories` section. Include your organization name and link to your primary website. Add a paragraph explaining how you use our templates or resources to create better documentation. + +## Add a logo to our website + +If you would like to add your logo to a future `Adopters of The Good Docs Project` section on [thegooddocsproject.dev/](https://www.thegooddocsproject.dev/), follow the steps in the previous section to add your organization to the list of Good Docs Adopters. Our community will follow up and publish it to our website. diff --git a/meta/reference/good-docs-project-template-1.5.0/CODE_OF_CONDUCT.md b/meta/reference/good-docs-project-template-1.5.0/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..ae2a6e05 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/CODE_OF_CONDUCT.md @@ -0,0 +1,3 @@ +# Code of Conduct - The Good Docs Project + +You can access the Good Docs Project Code of Conduct on our website: [The Good Docs Project Code of Conduct](https://thegooddocsproject.dev/code-of-conduct/). diff --git a/meta/reference/good-docs-project-template-1.5.0/CONTRIBUTING.md b/meta/reference/good-docs-project-template-1.5.0/CONTRIBUTING.md new file mode 100644 index 00000000..dc7f3f8e --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/CONTRIBUTING.md @@ -0,0 +1,431 @@ +# Good Docs Project - Template contributing guide + +Welcome to the Good Docs Project. If you're reading this guide, that probably means you'd like to get involved and start contributing to the project. This document should hopefully help you become a full templateer (which is how we refer to the members of our community). + +One of the core missions of the Good Docs Project is to provide high-quality documentation templates to open source software projects and beyond. However, we also engage in many other similar initiatives around docs advocacy, docs education, and docs tooling. We value all contributions to the Good Docs Project initiatives, including templates and our other initiatives. The [Join the community](#join-the-community) section of this guide explains how to get involved in those other related initiatives and provides links for more information. + +## Table of contents + +[TOC] + +## What do we work on + +The template working groups create or improve templates for a variety of content types used in documentation projects. + +Each template project consists of the following required files: + +* **Template file** - The raw template for the content type. +* **Template guide** - Provides a deeper explanation of how to fill in the template. +* **Process** - Explains best practices for researching, writing, and maintaining this content type. +* **Resources** - Includes the resources consulted during the research phase of creating the template. Also includes high quality examples of that content type that served as inspiration for the template. +* **Example** - After a template project is complete, our Chronologue working group creates an example of the template. They test the template for overall usability. + +See [Template deliverables](template_deliverables.md) for more detailed information about each template deliverable. + +### Template packs + +A template pack is a collection of templates organized together by: + +* Common use cases or tasks +* Needs of particular user personas +* Popular or interesting documentation frameworks +* Maturity models +* Future criteria or needs based on user research and feedback + +The core documentation pack is our flagship template pack and it includes the core, fundamental content types that every documentation project needs. If you download one template pack for your project, it should be this one. + +From a contribution standpoint, we anticipate that our long-term contributors develop a specialty or area of expertise in some specific template packs over time. + +### The Good Docs Project tactic articles + +The Good Docs Project takes in requests from users and stakeholders about what types of content they would like us to provide. Sometimes we receive requests for content that doesn't make sense as a template and instead makes more sense as an article or blog entry. + +We call these types of articles **tactics** and publish them on our website under a section called [The Good Docs Project tactics](https://www.thegooddocsproject.dev/tactic). Articles written for this framework use the title format {Article Title} Tactic, such as the Docs Landing Page tactic. + +Tactic projects go through the same contributing process as templates, but we publish them on our website instead of in the template repository. + +### Template issues and boards + +All the template and tactics projects that contributors are actively working on or which contributors might work on have a corresponding issue in the templates repository. +Use the issue list or the kanban board to find a project to work on and track your progress as your project moves throughout the template writing phases. + +* [Template issues list](https://gitlab.com/tgdp/templates/-/issues) +* [Templates in progress kanban board](https://gitlab.com/tgdp/templates/-/boards/4801048) + +## Before you start + +Before starting, register for a [Welcome Wagon meeting](https://thegooddocsproject.dev/welcome/). At this 1-hour orientation meeting, you get an introduction to our project's goals, key concepts, and workflows. + +We expect all members of our project to be nice to each other and to follow our [Code of Conduct](https://thegooddocsproject.dev/code-of-conduct/) when interacting with other members of the Good Docs Project. + +### Time commitment + +Most of us participate in one of our working groups, which meet weekly or bi-weekly for 1 hour a week. To contribute templates to a project, all template writers must join one of the template writing working groups. Check our [community calendar](https://thegooddocsproject.dev/community/#calendar) or ask a member of our community for meeting times. We offer two possible template working group meeting times per geolocation (AMER, APAC, EMEA): + +* Team Alpaca for AMER and APAC regions +* Team Dolphin for AMER and EMEA regions +* Team Macaw for APAC and EMEA regions + +Working at a pace of 1-2 hours a week, most template projects take 6-12 months to complete. Keep in mind that we take what you can give. You and your family come first, then work, then volunteering. So, if something in your life prevents you from working on your project, that's okay. Try to let your working group leader know if you aren't able to continue working for a space of time. + +### People who are here to support you + +As you work on contributing templates to our project, various resources and members of our community are available to help you along the process. These include: + +* **Templateers** - Any individual who contributes to the Good Docs Project (including you!). +* **The template working group leads** - These templateers oversee our overall template development process as a project manager and provide assistance to contributors working on templates. The working group leads also usually review and approve merge requests submitted to the templates repository. +* **Template mentors and buddies** - New templateers are usually assigned a mentor or buddy to provide guidance and mentorship while working on templates. +* **Template peers** - Your fellow templateer peers are available to review templates during the research and community feedback phases. They include members of your template writing working group, but also members from the larger Good Docs Project community. +* **Template editorial team** - This group reviews templates as they're nearing completion to ensure our templates follow best practices for technical writing, have no major organization or structural issues, have no gaps or missing content, and that they're consistent with our style guide. + +### Template working group meetings + +The template working groups have these types of meetings: + +* **Writer's workshops** - At these meetings, each templateer gives an update on their template project and poses a question to the group about some element of their draft they would like feedback and advice about. +* **Co-working sessions** - Templateers meet with their template writing partners, mentors, or buddies to work together on their template projects. +* **Community review sessions** - When a template project is ready for review from the rest of the community, the working group leads schedule a dedicated session for everyone in the group to read and provide feedback about the template files. +* **Planning or retros** - At the beginning of a release cycle, we've a few meetings dedicated to planning our commitments or initiatives for the release cycle. At the end of the release, we always do a working group retrospective to talk about what went well and what we could improve in the next release cycle. + +## Definition of done + +A template project is complete when: + +1. It has progressed through all the [template writing phases](#overview-of-the-template-writing-phasees) +2. It has all the required [template file deliverables](template-deliverables.md). + +### Overview of the template writing phases + +Contributing a template project to our repository has these phases: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
#PhaseYour goalsDefinition of done
1Join the community
    +
  • Join our project by attending a Welcome Wagon meeting.
    • +
  • Decide which working group you'd like to work on based on your interests and experience.
    • +
+ 		Consider this phase complete when you join a working group.
2Adopt a template
    +
  • Join a template working group.
    • +
  • Work with a template working group lead and your group to decide which template or tactic project you work on.
    • +
  • Assign yourself to the corresponding issue for that template or tactic. Note that this requires a GitLab account and you need to join the template repository as a member.
    • +
  • Use the Google Docs attached to that issue to compose the drafts of the template file deliverables.
    • +
+ 		Consider this phase complete when you assign yourself to the issue tracking your template or tactic project.
3Research the template

(Research phase)
    +
  • Research examples and best practices for the content type you're creating a template for.
    • +
  • Collaborate and get early feedback on your research from your template working group lead and/or other templateers as part of a template writing working group.
    • +
+ 		Consider this phase complete when you have finished a draft of your Resources document.
4Draft the template deliverables

(Drafting phase)
    +
  • Use the Google Docs attached to that issue to create the drafts for the rest of your deliverables in Google Docs: template file, template guide, template process.
    • +
  • Meet with your working group or writing partners to workshop on and get advice on your drafts while you are working on them.
    • +
+ 		This phase completes when you schedule your drafts for review by other members of your working group or community.
5Get feedback on drafts from the community

(Community review phase)
    +
  • When your template deliverables are ready for review, your working group lead schedules 1-2 sessions in the community where other members of the project review and provide feedback on your template files deliverables.
    • +
  • Optional: Revise and refine your draft with subject matter experts and individuals beyond our community (such as Write the Docs or subject matter experts).
    • +
  • After making revisions, work with your template working group to determine when your draft is ready for the next 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.
6Get a review from the template editorial team

(Editorial team review phase)
    +
  • When your draft is in a state where you feel it's ready, you can work with your working group lead to request an editorial team review. The template editorial team comprises experienced members of the project who review your template project in Google Docs to ensure that it: +
      +
    • Follows best practices for technical writing.
      • +
    • Has no major organization or structural issues.
      • +
    • Has no gaps or missing content.
      • +
    • Is consistent with our style guide.
      • +
    +
    • +
+ 		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.
7Submit a merge request

(Final review phase)
    +
  • Convert drafts from Google Docs to Markdown.
    • +
  • Convert drafts from Google Docs to Markdown.
    • +
  • Ensure the Markdown format is clean. NOTE: This project uses EkLine.io to check content and format of Markdown files that you add or modify in the Merge Request.
    • +
  • Ensure the Markdown renders to HTML correctly.
    • +
  • Open a merge request against the templates repository. NOTE: You are responsible for educating yourself in how to use Git and GitLab, but you can consult your working group lead and fellow templateers for help.
    • +
  • Revise documents based on requests from merge request reviewers.
    • +
+ 		This phase completes when the template merges into the repository.
8Hand off to the Chronologue team for user testing

(Chronologue phase)
    +
  • After completing the previous phase, your template is officially part of the Good Docs Project and is available to our users.
    • +
  • After a template project is complete, our Chronologue working group creates an example of the template. While creating the example, the Chronologue group tests whether your template is user-friendly and can serve 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.
    • +
  • As additional users try your template out in the wild, they may report usability issues or provide feedback for improvements to the template.
    • +
  • Either the Chronologue writer, the original template author, or another templateer evaluates feedback and incorporates it into future versions of the template. If extensive revisions arise, the template may need to go through the same previous template writing phases again.
    • +
+ 		The Chronologue team considers this phase complete when they create an example for the template.
+ +Each phase has more depth in the remaining sections. + +## 1. Join the community + +To join our community, you need to register for a [Welcome Wagon meeting](https://thegooddocsproject.dev/welcome/). At this 1-hour orientation meeting, you get: + +* A brief overview of our project's goals and mission. +* A bit of information about our community and reasons to consider joining. +* An overview of our key initiatives and working groups that you might consider contributing to. +* An in-depth orientation to one working group of your choice. + +After registering for this meeting, you get an email with a link to join our Slack workspace. You are eligible to be a member of our repository after you attend a Welcome Wagon meeting. + +To become a full-fledged templateer, you need to join our communication channels so that you can talk to us: + +* **Slack** - Our Slack workspace is one of the primary means of communicating with members of our project. After joining our workspace, join the `#welcome` channel to introduce yourself. Consider also joining these Slack channels if you plan to work on a template or tactic project: + * `#templates` + * `#ask-a-community-manager` + * `#tech-requests` +* **Working groups** - We organize our project into several different working groups that meet on a regular basis to work on the project's key initiatives. One of the best ways to get started with our project is to join and meet with one of our working groups. See [The Good Docs Project Working Groups](https://thegooddocsproject.dev/working-groups/) for a list of our current active groups. NOTE: If you plan to contribute to our project by writing templates, you must join one of the template working groups. +* **Weekly meetings** - The project leaders hold weekly meetings to discuss project-level decisions. Feel free to join one of these meetings to introduce yourself to the project leaders and discover next steps for getting involved in the project. See the [community calendar](https://thegooddocsproject.dev/community/#calendar) for meeting times. + +As you begin to join our project, remember that this is a project composed entirely of volunteers. We love to welcome new members, but want to be careful not to burn out our core project contributors. This level of mindfulness helps us ensure that we retain our project's capacity to produce high-quality work. As such, we ask that you respect the time of our project maintainers and contributors. +(And expect us to respect your time in return!) + +We expect all members of our project to be nice to each other and to follow our [Code of Conduct](https://thegooddocsproject.dev/code-of-conduct/) when interacting with other members of the Good Docs Project. + +## 2. Adopt a template + +In this phase, you decide which template or tactic project you work on and assign yourself to the issue tracking that project. + +Be aware that: + +* Each template or tactic project relates to a corresponding issue in the templates repository. +* You use this issue to communicate the status of your template project as it moves through the different phases of the template writing process. +* The Good Docs Project managers use a kanban board that shows all the issues for the current template projects. This tool allows the templateers and project stakeholders to track the overall progress of each template and assist templateers whose progress has stalled. + +Links: + +* [Template issues list](https://gitlab.com/tgdp/templates/-/issues) +* [Templates in progress kanban board](https://gitlab.com/tgdp/templates/-/boards/4801048) + +To adopt a template: + +1. Scroll through the list of available template and tactic issues and see if one interests you and/or matches your skill set. Alternatively, if you have an idea for a template or tactic project that doesn't yet have an issue, and you have the support of a template working group lead, you can create a new issue for your project. + +2. Assign yourself to the issue. Note that this requires a [GitLab account](https://gitlab.com/users/sign_up). You must attend a [Welcome Wagon meeting](https://thegooddocsproject.dev/welcome/) to become a member of the templates repository. After you've attended that meeting, you can request access in the `#tech-requests` Slack channel. + +3. Notify your template working group lead that you have adopted a template project. + +If you claim a template or tactic project and later realize that you don't have the time or energy to complete the template project, let your working group lead know. + +### Guidelines for choosing a template + +Keep in mind that you don't need to be an expert on any content type before you adopt it. If you want to write a particular template or tactic article and you are eager enough to do some research to learn more about it, that's all the preparation you need and we welcome your efforts. Even if you don't have a ton of experience writing a particular type of document, you can still write a high-quality template that is useful to others. With commitment, research, guided mentorship, and feedback from our community, you can and create something that has value to others. + +With that in mind, when deciding which template project is right for you, scroll through the list of template issues and ask yourself the following questions: + +* Does something about this type of document or template intrigue you, spark your curiosity, and make you excited to research and learn more? +* Do you wish you knew how to create the best version of this type of document? Are you energized by the idea of researching best practices or gleaning insights from subject matter experts about this type of document? +* Do you have experience writing for this type of document which you would like to share? Would having a high quality version of this type of template make your life easier at your workplace or for your open source project? +* Do you feel like there is a strong need for improved versions of this type of document in the world? Do you see lots of bad examples of this document that frustrate you? +* Has the Good Docs Project labeled this type of template as a high priority for our project? (Keep in mind that you can work on any template that you feel enthusiastic about, regardless of priority. That said, we welcome work on our high priority templates.) + +If you answered yes to more than one of these questions about a specific type of template, that might be the right template for you to work on. + +### Priority levels + +The following table explains the priority levels given to different template or tactic projects: + + + + + + + + + + + + + + + + + + + + + + +
PriorityDescription
Critical
    +
  • A template project that's included in the core template pack. The core template pack is our flagship template pack and the one with the highest visibility and quality.
    • +
  • A template project or tactic that's in high demand from our users, meaning 10 or more users have requested it.
    • +
  • Any template work that's blocking other template work or which would improve our overall template processes or usability.
    • +
  • Any work to get a core template into compliance with our quality standards and/or deliverables.
    • +
+
High
    +
  • Any template or tactic for which there is high demand from our users, meaning 5-9 users have requested it.
    • +
  • The project steering committee or template leads have earmarked any template project for a specific release for whatever reason.
    • +
  • Any work to get a high-demand template or tactic into compliance with our quality standards and/or deliverables.
    • +
+
Medium
    +
  • Any new template or tactic for which there is moderate demand from users, meaning 2-4 users have requested it.
    • +
  • Any work the template roadmap adds but isn't earmarked for a specific release.
    • +
  • Any work to get a moderate-demand template or tactic into compliance with our quality standards and/or deliverables.
    • +
+
Low
    +
  • Any new template or tactic for which there is low or no demand from users, meaning 1 user has requested it.
    • +
  • Specialized template projects for a niche audience or area of expertise.
    • +
  • Any work to get a low-demand template or tactic into compliance with our quality standards and/or deliverables.
    • +
+
+ +## 3. Research the template + +Before starting the research phase, read the [Template deliverables](template-deliverables.md) for more detailed information about each template deliverable. Ensure you understand the purpose of each deliverable. + +In this phase, you research examples and identify best practices for the type of template you're working on. While you are working on the research phase, you should create a draft for the **resources** template deliverable file. The resources file is where you keep your notes about which resources you consulted and which examples you looked at for guidance. + +Our project composes rough draft of templates in Google Docs that the project leads own and maintain. The Good Docs Project owns these files so that we can maintain our project archive and history. With that in mind, the project has pre-generated Google Doc files for you to use as you are researching and drafting your template project. These files include a starting point for the structure of each file that should help you as you draft the documents. Each open issue attaches the pre-generated Google Doc files. + +The reasons we require your draft in a Google Doc are because it: + +* Is free (no license required) and easy to use. +* Is relatively straightforward to share with collaborators both inside and outside of the Good Docs Project (such as with the Write the Docs community). +* Allows collaborators to give feedback and advice in the form of comments. +* Tracks comment history for later reference. +* Has version control capabilities. + +### Recommended research strategies + +In our experience, successful templateers usually research their template by: + +* **Looking at lots of examples.** Start by searching for examples of that type of document they want to create a template for. The more examples you can look at, the better. While it's better to review good examples of that type of document, there is actually a lot of value in reviewing bad examples too. Consider keeping a spreadsheet to track which examples you used, what elements each one had in common, and what you thought was effective or ineffective. +* **Searching for guides, books, blog posts, conference presentations, or videos about best practices.** Search the Internet to find advice, tips, or expert research about how to create that type of document. Consider posting in a forum for resource ideas. For example, asking for helpful guides or insights on a community forum like the Write the Docs Slack workspace could be beneficial. Be mindful of, and respect copyright terms of source material. Don't plagiarize and offer attribution where appropriate. +* **Reaching out to experts.** When you find people you admire, who have researched your topic already, try reaching out to them. They often have a "how to contact me" webpage. Ask if they'd be okay with using their material. (They might need to republish under a different copyright.) Invite them to participate in the template working group. They might even lead it. If you feel shy about reaching out yourself, your template mentor or senior Good Docs Project member might offer to help. +* **Collaborating with others in a working group.** Work with your template writing working groups to discuss research ideas and findings. + +## 4. Draft the template deliverables + +After you conclude your research, you create drafts of your template file deliverables in Google Docs. See the [Template deliverables](template-deliverables.md) for more detailed information about each template deliverable. + +You can also look at examples of other templates in the repository to see examples of each template file. Be aware that some templates might be missing some files. + +Your working group helps you as you work on drafting your templates. At writer's workshop meetings, you can workshop your template by asking for advice or asking questions to get clarification about your template project and content type. + +When your draft is in a good place, contact your working group lead to schedule a community review. + +## 5. Get feedback on drafts from the community + +In this phase, you begin to share your drafts with community reviewers and invite feedback. Optionally, you might also consider sharing it beyond our community with other technical writing communities such as Write the Docs or beyond. The feedback and revision phase is arguably the most crucial and important phase in the template writing process, so your template project might spend the bulk of its time in this phase. + +To share your Google Docs drafts: + +1. Inside the draft, click the **Share** button and change the **Get Link** settings to: **Anyone on the internet with this link can create comments.** + +2. Copy the link to your Google Doc drafts into the issue that corresponds with your template in the templates repository. + +3. Notify your working group lead, who helps you schedule a community review session for your template with your working group or another templates working group as needed. + +When you've received sufficient community input and incorporated suggestions into your draft, notify your templates working group lead that your draft is ready to move to the next phase. + +> :triangular_flag_on_post: **NOTE: You can only move to the next phase (submitting a merge request) after the templates working group lead has approved your draft to move on.** + +### Giving feedback to others + +See our [Commenting guide for collaborative document reviews](https://gitlab.com/tgdp/governance/-/blob/main/DocCommentingGuide.md?ref_type=heads) for information about how to provide feedback to others. + +Also see [Conventional comments](https://conventionalcomments.org/). + +### Accepting feedback from others + +It's normal to feel nervous about sharing your drafts, especially if you're a new writer or if you don't feel as confident in your subject matter knowledge yet. But your draft can only become the best template it can be if you invite and incorporate high quality feedback into your drafts. Successfully accepting advice on a draft is a key element that distinguishes expert writers from novice writers. + +Sharing your work with reviewers: + +* Allows you to see your draft with fresh eyes the way a new user would see it. +* Can make you aware of key insights or perspectives that you hadn't yet considered. +* Can help you identify which parts of your draft need more careful thought, attention, and revision. + +As you receive feedback, try to give each comment the benefit of the doubt and consider it. Sometimes new writers may react defensively to feedback on their work, but remember that your reviewers have the same goals that you have: to produce a high quality template. But also keep in mind that you don't need to accept every suggestion. If you can make a good argument not to adopt a suggestion, that's important to consider as well. + +One other thing that might help you get more high quality reviews is to indicate what kind of feedback you're looking for, based on areas of the draft you think need some improvement. Do you need: + +* Global-level feedback, which includes advice on the big picture, general content, tone, clarity, and overall organization or flow of the document? +* Local-level feedback, which includes wordsmithing paragraphs or sentences and polishing up the draft for final revision? + +Remember to be positive and show appreciation when people take time to review your drafts. Providing feedback takes time and energy. Treat each piece of feedback as a gift (even feedback that you possibly choose to disregard). Happy editing! + +## 6. Get a review from the template editorial team + +The purpose of this phase is to ensure your template project meets the standards of the Good Docs Project and is ready for public distribution. + +When your draft is in a state where you feel it's ready to get merged in, you can work with your working group lead to request an editorial team review. The template editorial team comprises experienced members of the project who review your template project to ensure that it: + +* Follows best practices for technical writing. +* Has no major organization or structural issues. +* Has no gaps or missing content. +* Is consistent with our style guide. + +This review aims to be a final quality check to determine whether the template is ready to be officially included in the Good Docs Project. + +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 + +The purpose of this phase is to check that you format your Markdown correctly, render it correctly, and make it ready for publication. In this phase, you convert your template documents into Markdown and open a merge request in the `templates` repository on GitLab. + +If you aren't comfortable working in Markdown, Git, or GitLab, ask your working group lead for advice. + +Once you submit a merge request, your template working group lead reviews your template and/or works with other working group leads to review your template. Once the template has at least one approval from a template repository maintainer, it merges into the final project. + +## 8. Hand off to the Chronologue team for user testing + +Once it passes all reviews, your template merges in and you get a personal acknowledgement in our Slack community and in our next template release notes. + +:sparkles: :mega: :raised_hands: + +Great documents are never fully done, and there is always room for improvement. After a template project is complete, our Chronologue working group creates an example of the template. While creating the example, the Chronologue group tests whether your template is user-friendly and can support a real documentation project. It's possible that the Chronologue team identifies major or minor revisions that need updating in the template. + +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. Either the Chronologue writer, the original template author, or another templateer makes any necessary revisions of the templates. If the template requires extensive revisions, the template goes through the same previous template writing phases again. + +After a Chronologue example is complete and users begin to try your template in their own documentation projects, they may report usability issues or provide feedback for improvements to the template. If our project receives this feedback and you're still around to work on your original template, we encourage you to review this feedback and incorporate these revisions into future versions. If you aren't around to continue working on your original template or if you are too busy, we can find a different templateer to respond to user feedback on your behalf. + +If a templateer determines that a new version of a template warrants updating, they take the template through the same contributing process starting from the beginning. diff --git a/meta/reference/good-docs-project-template-1.5.0/DCO.txt b/meta/reference/good-docs-project-template-1.5.0/DCO.txt new file mode 100644 index 00000000..36fe7b6c --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/DCO.txt @@ -0,0 +1,36 @@ +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +1 Letterman Drive +Suite D4700 +San Francisco, CA, 94129 + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. diff --git a/meta/reference/good-docs-project-template-1.5.0/DEI.md b/meta/reference/good-docs-project-template-1.5.0/DEI.md new file mode 100644 index 00000000..c9dbeae3 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/DEI.md @@ -0,0 +1,3 @@ +# DEI policy + +To read our DEI policy, see [DEI.md](https://gitlab.com/tgdp/governance/-/blob/main/DEI.md?ref_type=heads) in the Governance and Community repository. diff --git a/meta/reference/good-docs-project-template-1.5.0/GOVERNANCE.md b/meta/reference/good-docs-project-template-1.5.0/GOVERNANCE.md new file mode 100644 index 00000000..04c927b5 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/GOVERNANCE.md @@ -0,0 +1,3 @@ +# Governance - The Good Docs Project + +To read our GOVERNANCE policy, see [GOVERNANCE.md](https://gitlab.com/tgdp/governance/-/blob/main/GOVERNANCE.md?ref_type=heads) in the Governance and Community repository. diff --git a/meta/reference/good-docs-project-template-1.5.0/LICENSE b/meta/reference/good-docs-project-template-1.5.0/LICENSE new file mode 100644 index 00000000..47fe16cf --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/LICENSE @@ -0,0 +1,7 @@ +# MIT No Attribution License + +Copyright (c) 2024 The Good Docs Project + +Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. diff --git a/meta/reference/good-docs-project-template-1.5.0/README.md b/meta/reference/good-docs-project-template-1.5.0/README.md new file mode 100644 index 00000000..5e89db24 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/README.md @@ -0,0 +1,215 @@ +# The Good Docs Project templates + +[![License: MIT-0](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/license/mit-0) [![CHAOSS DEI: Bronze](https://gitlab.com/tgdp/governance/-/raw/main/CHAOSS-Bronze-Badge-small.png?ref_type=heads)](https://badging.chaoss.community/) + +Does your project need docs but you don't know how to start? +The Good Docs Project templates can help. +Use the templates in this repository to create quality docs faster and easier for free. + +We are an open-source project working to provide templates for a variety of common content types used in most software documentation projects. + +## Table of contents + +[TOC] + +## Who the templates are for + +Our templates are for anyone who wants to make better software documentation. +This includes: + +* **Developers** who want to create good documentation for their software quickly and easily, but don't know where to start. +* **Documentation project owners** working in a docs-as-code model and who you want to provide templates to non-writers to help them write better documentation. +* **Technical writers** who want to standardize their documentation and draw inspiration from high-quality templates for their own templates or documentation projects. + +## About the templates + +Our templates are organized into **template packs.** +A template pack is a collection of templates organized together by: + +* Common use cases or tasks. +* Needs of particular audiences or stakeholders. +* Popular or notable documentation frameworks. +* Maturity models for documentation. + +If you are unsure which template pack is right for you, we recommend starting with the [Core documentation pack](#core-documentation-template-pack). +The core documentation pack is our flagship template pack and it includes the core, fundamental content types that every documentation project needs. +If you download one template pack for your project, it should be this one. + +Each individual template within the template packs contains a set of files: + + + + + + + + + + + + + + + + + + + + + + + + + + +
FileExample filename and purpose
Template filetemplate_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 guideguide_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.
Resourcesresources_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.
Processprocess_content-type.md

This document explains best practices for researching, writing, and maintaining this content type.
Exampleexample_content-type.md

See an example of the template in action in our model documentation project: The Chronologue.
+ +NOTE: Not all templates contain all these files, but our goal is to eventually provide these files for each template. + +## How to get the templates + +You can click the links in the following table to access the template files. +You can then download or copy and paste these files into your documentation project as needed. + +### Core documentation template pack + +The core documentation pack is our flagship template pack and it includes the core, fundamental content types that every documentation project needs. +If you download one template pack for your project, it should be this one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TemplateDescription
ConceptAn explanation of a concept, context, or background information about a product or its features.
How-toA concise set of numbered steps to do one task with the product.
READMEInformation users need to know about your project, including how users can engage with the project and get started with the tool.
ReferenceDescriptions of specific components or characteristics of an application.
Release notesCommunicate new features, improvements, bug fixes, and known issues about a product to users and stakeholders.
TutorialInstructions for setting up an example project using the product, intended for the purpose of hands-on learning.
TroubleshootingA list of common problems (referred to as "symptoms") experienced by users, an explanation of the causes, and steps to resolve the issue.
+ +### Open source community docs template pack + +The open source community docs template pack includes the fundamental content types that every open source project needs to have a healthy and productive community. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TemplateDescription
Bug reportThe bug report is an issue template that your users can fill out to provide you with higher-quality, actionable bug issues for your product.
ChangelogChangelogs document significant product changes in reverse-chronological order. This template offers a more technical, comprehensive alternative to standard release notes.
Code of ConductA Code of Conduct helps you govern your open source or developer community to ensure it remains healthy and open.
Code of Conduct response planUsed 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 recordUsed 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 recordUsed 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 guideA CONTRIBUTING document tells users how they can contribute to your open source project and join the community.
Our teamHelps you clearly communicate who belongs to your open source project or organization and how contributors can contact or work with them.
READMEInformation users need to know about your project, including how users can engage with the project and get started with the tool.
+ +### Miscellaneous documentation template pack + +These templates help you create additional content types beyond the [Core documentation pack](#core-documentation-template-pack). +The templates in this pack help you create content you need as your documentation project matures. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TemplateDescription
API getting startedAPI getting started guides help new users with the process of creating a minimum working example with your API.
API referenceAPI references are technical manuals that provide API specifications and integration instructions to help your audience understand the service.
Contact supportA 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.
GlossaryA 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 guideExplain all the necessary steps to install the product and set it up for further use.
QuickstartA 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 guideA 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 systemUsing this template, writing teams can ensure they consistently use and translate the same terms across all the documentation in their system.
User personasUser 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.
+ +## Provide feedback on our templates + +Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Project%20README%20on%20Gitlab) if you would like to provide feedback on our templates. You could also [open an issue](https://gitlab.com/tgdp/templates/-/issues). + +## Contribute to our project + +See our [Contributing guide](CONTRIBUTING.md) for information about joining our community and contributing to the templates project. diff --git a/meta/reference/good-docs-project-template-1.5.0/SECURITY.md b/meta/reference/good-docs-project-template-1.5.0/SECURITY.md new file mode 100644 index 00000000..8ecca26a --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/SECURITY.md @@ -0,0 +1,3 @@ +# Security reporting + +To read our SECURITY policy, see [SECURITY.md](https://gitlab.com/tgdp/governance/-/blob/main/SECURITY.md?ref_type=heads) in the Governance and Community repository. diff --git a/meta/reference/good-docs-project-template-1.5.0/STYLE-GUIDE.md b/meta/reference/good-docs-project-template-1.5.0/STYLE-GUIDE.md new file mode 100644 index 00000000..1d0b0c82 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/STYLE-GUIDE.md @@ -0,0 +1,1434 @@ +# The Good Docs Project - Style Guide for Documentation of Templates + +This brief style guide for Good Docs Templates provides the 20% high-value writing tips which address 80% of the value. +For more comprehensive advice, refer to the Google Developer Style Guide and the Documentation Style Guide for GitLab. + +## General recommendations + +Apply the following recommendations as you see fit. + +### How to apply the recommendations in this style guide + +Each section contains: + +* Recommendations: follow these recommendations when writing templates for the Good Docs Project. +If there isn't a recommendation on this style guide, then fall back to one of the parent style guides. +* Checklist: before submitting a merge request, use the checklists to verify your deliverable. +Reviewers use these checklists as criteria to accept or reject an MR. +* Sources: one of the parent style guides where you can find similar guidance and examples, if at all. + +### Write for the audience + +When you write, ask the following questions: + +* Who am I writing for? +* What assumptions can I make about the audience when I write for them? In other words, what does the audience already know about the subject and what does the audience need to know? +* Can I anticipate questions the audience might have? +* What's the best outcome for the audience? What do I need to say to get this outcome? For example, to use a Good Docs Project template, one needs to download the template file and ideally follow the instructions on the guide of that template. +We want people to use the template and the guide together because of clarity (best outcome) and that's why one can find the following instruction at the top of a guide: "​​{Before using this template, read the accompanying…". + +#### Checklist: Does the topic target the audience appropriately? + + + + + + + + + + + + + + + + + + +
Guideline + Check +
Write for the audience. + Does the template target one or more of the following personas, as defined by the Good Docs Project? +
    + +
  • Developer-writer + +
  • Doc system owner + +
  • Reader of end-user documentation based the Good Docs Project templates +
    • +
+
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. + +
+ +Sources + +* At the time of writing, Google doesn't have any specific guidance. +* At the time of writing, GitLab didn't have any specific guidance. + +Please, let us know if there are any updates so we can update this section. +[Contact the Good Docs Project.](mailto:gooddocsproject@gmail.com.) + +#### Voice and tone + +The current voice and tone of the Good Docs Project projects is mildly casual, serious, but not overly serious, and warm and approachable. +It makes sense to use the same voice and tone when writing templates. + +See the diagram for visualizing the voice and tone spectrum for the Good Docs Project. + +![alt_text](images/voiceNtone.png "Voice and tone of the Good Docs Project") + +Sources + +* [Voice and tone | Google developer documentation style guide](https://developers.google.com/style/tone) +* [Tone of voice](https://design.gitlab.com/brand/overview/#tone-of-voice) in the GitLab Design Lab + +### Be consistent + +Always refer to a feature, a concept, or an object with the same term. +For example, avoid using 'username' and 'user ID' interchangeably, or avoid using 'user' and 'reader', or avoid referring to Microsoft 'Teams' and then refer to 'teams'. + +#### Checklist for consistency of terms + + + + + + + + + + +
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? +
+ +Sources + +* [Write for a global audience | Google developer documentation style guide](https://developers.google.com/style/translation#be-consistent) +* [Writing for localization | GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/#writing-for-localization) + +### Abbreviations + +Spell out an abbreviation in the first occurrence of it on a topic. +Remember that a topic is a self-contained section of a documentation as in DITA topics or a documentation type in Diataxis. +You might have to spell out the same abbreviation across topics of the same documentation because you can't assume that people will have read it on another topic, even if that topic is the 'Getting started' topic. + +Exceptions: acronyms that are established in the industry, for example, WWW, TCP/IP, URL, and others. + +Avoid creating unnecessary abbreviations. + + + + + + + + + + + + + + +
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. +
+ +#### Checklist for abbreviations + + + + + + + + + + + + + + +
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? +
+ +Sources + +* [Abbreviations | Google developer documentation style guide](https://developers.google.com/style/abbreviations) +* [Acronyms | GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/#acronyms) + +### Plain language + +Plain language means that you write with words that the audience can immediately understand when they read the text the first time. + +Apply the following principles. + +#### Write short to medium sentences most of the time + +In general, short sentences are easier to write and easier to read. +Sometimes, medium sentences are required for complex explanations. +Long sentences might require the reader to read instead of scanning, be mindful and choose long sentences only if absolutely necessary. + +Every word must have earned its place in a text. +If you can cut a word because it is not justified in the text, cut it. + + + + + + + + + + +
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. +
+ +Source of the example: [Wordiness Made Spare article | Plain Language website](https://www.plainlanguage.gov/examples/before-and-after/wordiness). + +#### Write in the simplest tense + +Typically, the simplest tense is present tense. + + + + + + + + + + +
Do + Don't +
To register a user, configure the system first. + To register a user, you will need to configure the system first. +
+ +##### Avoid passive voice when writing instructions + +If you want users to perform an instruction, tell them so. + + + + + + + + + + + + + + +
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. +
+ +#### Write for easier translation + +Clustering words might be difficult to translate. +Do not cluster more than 3 words. +You can break a cluster of words using prepositions such as 'of', 'for', and 'with'. + + + + + + + + + + +
Do + Don't +
Readme documentation of the Terra service OR Readme of the Terra service + Terra service readme documentation +
+ +Don`t use metaphors, figures of speech, slangs, or jargons. + +#### Checklist for plain language + + + + + + + + + + + + + + + + + + + + + + +
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? +
+ +Sources + +* [Write for a global audience | Google developer documentation style guide](https://developers.google.com/style/translation#write-short,-clear,-and-precise-sentences) +* [Writing for localization | Documentation Style GuideGitLab](https://docs.gitlab.com/ee/development/documentation/styleguide/#writing-for-localization) + +### Capitalize consistently + + To keep the documentation that you are writing consistent, use capitalization consistently. + +Typically, style guides have many rules for capitalization, but to keep this style guide concise, use the following rules: + +* Use sentence case for: + * Titles and headings + * Lists + * Table elements like headings, labels, and captions + * Image legends +* Match the capitalization of the UI when referring to it. +* Check the capitalization of the product that you are writing about and use the same capitalization that the product website uses throughout the document. +If the product or feature that you are writing about is in your project, then define the capitalization and use it consistently. +* Do not use capitalization unnecessarily. +Use 'cloud' instead of 'Cloud', 'service' instead of 'Service', 'project' instead of 'Project', and so on. + +#### Checklist for capitalization + + + + + + + + + + + + + + + + + + + + + + +
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? +
+ +Sources + +* [Capitalization | GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/#capitalization) +* [Capitalization | Google developer documentation style guide](https://developers.google.com/style/capitalization) + +### Information organization + +The most important information comes first in a page, topic, section, or sentence. + +![alt_text](images/importance.png "Order of importance") + +Source: [https://coolerinsights.com/2021/02/writing-social-media-guide/](https://coolerinsights.com/2021/02/writing-social-media-guide) + +When users read the most important information first, you make them focus from the first line. +Users can decide at any point if the topic is not of interest, choose not to read it and still leave with the main message. + +Also, since the first sentences appear in search results, it makes sense to have the most important information there because that's what users will see in a list of search results. + +So for pages, topics, and sections, put the most important information first, followed by additional details, and then nice-to-know information. +This way of presenting information is also known as inverted pyramid, as depicted in the diagram. + +#### How to write sentences with the most important information first + +In sentences, information that clears any doubts about the context is as important as the main message. +So, in sentences, put contextual information like goal, location, or condition first. + +If these things come at the end of the sentence, there is a great likelihood that users might need to read the text twice: the first time for the meaning of the sentence, and the second time to add the context. + +##### Goal + +If you are writing about a goal that the user is trying to achieve, then write the goal first. + +Example 1: The goal is to request a template. +Users who are not interested in requesting a template can plain skip the text about what's involved in the process of requesting a template. + + + + + + + + + + +
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. +
+ +Example 2: The goal is to edit system-defined metadata of an object. +Users need to know why they are performing instructions before they do. + + + + + + + + + + +
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. +

+ +##### Location + +When you tell users to follow instructions, tell them where this is going to happen. + +Example 1: Tell the user where things happen in the UI. + + + + + + + + + + +
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**. +
+ +Example 2: Tell the user where things happen in the command line. + + + + + + + + + + +
Do + Don't +
1. On your **home directory**, type command. + 1. On the terminal, type command. +
+ +##### Condition + +If a condition applies to a subset of the audience, write it first, so users to whom the condition doesn't apply can skip the text. + + + + + + + + + + + + + + +
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. +
+ +#### Checklist for information organization + + + + + + + + + + + + + + + + + + + + + + +
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? +
+ +Sources + +* [Sentence structure | Google developer documentation style guide](https://developers.google.com/style/sentence-structure) +* [Procedures | Google developer documentation style guide](https://developers.google.com/style/procedures#introductory-sentences) +* GitLab N/A + +### Links + +A helpful link is up to date, not broken, it empowers users to choose to follow it BEFORE they do, and is placed where it is needed and not where it can become a distraction. + +#### How to write up-to-date links + +When linking to another topic, whenever possible and in particular to an external site, use a low-risk link or a medium-risk link. +These links have a lower risk of being outdated or broken than linking directly to an internal document in an external site. +This is particularly important in The Good Docs Project documentation, where writers are volunteers and might not be around when the link needs updating. + +The following table explains the types of links and the risk of the link to be outdated or broken, how to write that type of link, and an example for each type of link. + + + + + + + + + + + + + + + + + + + + + + +
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`_. +
+ +When you write the resources deliverable for the template project, try to use medium-risk links, when possible. + +When linking to internal topics, it is less problematic to use high risk links than when linking externally. +That is because the likelihood that internally changed links will be updated or noticed early is higher than when a link changes externally. +For example, you can use a link to a template deliverable of a Good Docs Project template. +See the +[resources section](#resources) of the template deliverables. + +#### Accessed on + +With each external link, Give the reader an indication of when you accessed the link: + +Accessed on _date on which the link was accessed_. + +#### How users can choose to follow the link before they do + +When creating links, unless the link text is self-explanatory, create links with context. +Tell people why they'd follow a link before they click on it by adding introductory information with the link. +It is just a small sentence for you, but it saves people the trouble of following the link and scanning the page to find out why the link is there and if they did want to read the page. + +You can add context to links using the following ways: + +* Write a descriptive phrase that provides context for the topic that you're linking to. +* Write link text that portraits the content of the topic that you're linking to. +Ideally, the link text would match the topic heading on the target page. + +See some examples of not so helpful links and how to fix them. + + + + + + + + + + + + + + + + + + + + +
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. +
+ +Sources + +* [Link text | Google developer documentation style guide](https://developers.google.com/style/link-text) +* GitLab has examples of standard text for commonly used link texts: [Standard text in links | GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/#standard-text) + +#### Where to place a hyperlink + +Links can be distracting, especially if placed in places where people don't need them. + +* For instructions that the user must follow to complete a step, place the link in the step where it is needed. +* For supporting information, create a section called 'Related topics' at the bottom of the page and place links with supporting information, related topics, and nice-to-know information in there. + +Source + +* [Links | GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/#links) +* At the time of writing, Google didn't have any guidance about where to place links. +Lots of recommendations about writing links. + +#### Checklist for links + + + + + + + + + + + + + + + + + + + + + + +
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? +
+ +### Lists + +The simplest guideline for lists is: use numbered lists for a sequence of instructions or anything that requires order. +Use bulleted lists for everything else. + +Other recommendations: + +* Introduce the list with an introductory sentence. +* Use parallel phrasing. +* For inline lists, use the Oxford comma. + +#### Introductory sentence + +To clear any assumptions about the content of the list, write a complete sentence to introduce the list. + +Example 1: No introductory sentence X introductory sentence + + + + + + + + + + +
Do + Don't +
Administrators can manage VMs with the following features: +
    + +
  • Super VM + +
  • VM center + +
  • VM Advantage + +

    +Proposals limitations +

    +Consider the following limitations for proposal description and active proposals at a time: +

      + +
    • There is a character limit of 20,000 for the description of a proposal. + +
    • One address can have a maximum of 10 active proposals at a time, across multiple spaces. +
      • +
    +
    • +
+ 		Enable administrators to deal with VMs with the following features: +
    + +
  • Super VM + +
  • VM center + +
  • VM Advantage + +

    +Proposals limitations +

      + +
    • There is a character limit of 20,000 for the description of a proposal. + +
    • One address can have a maximum of 10 active proposals at a time, across multiple spaces. +
      • +
    +
    • +
+
+ +Example 2: A clear introductory sentence X Not so clear introductory sentence + + + + + + + + + + +
Do + Don't +
Administrators can manage VMs with the following features: +
    + +
  • Super VM + +
  • VM center + +
  • VM Advantage +
    • +
+ 		Enable administrators to deal with VMs with the following features: +
    + +
  • Super VM + +
  • VM center + +
  • VM Advantage +
    • +
+
+ +#### Numbered lists + +Use numbered lists for instructions or anything that requires order. + +Example 1: Numbered list for instructions + + + + + + + + + + +
Do + Don't +
+
    + +
  1. On the bottom of the **Fields List** pane on the left, click **Add a Field**. + 2. Search your field by address, zip code, latitude/longitude, or CLUs (common land units) that appear as outlined grids of land. +

    + 3. To organize your field information in your account, type a **Field Name**, **Client Name**, **Farm Name** and **Approximate Area** of the field. +

    + +

    2. +
+ 		+
    + +
  • Click **Add a Field** on the bottom of the **Fields List** pane on the left. + +
  • Search your field by address, zip code or latitude/longitude or by CLUs (common land units) that will appear as outlined grids of land. + +
  • Provide a **Field Name**, **Client Name**, **Farm Name** and **Approximate Area** of the field in order to keep your field information organized in your account. +
    • +
+
+ +#### Bulleted lists + +When the order of the items of a list is interchangeable, use a bulleted list. + +Example 1: Bulleted list for a series of items that can be listed in any order + + + + + + + + + + +
Do + Don't +
The retention policy is the following: +
    + +
  • Slack - 30 days for Chat, 4yrs for channels, 4yrs for files + +
  • Gmail attachments - 2yrs for active accounts, 6mths for non-active accounts +
    • +
+ 		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 +

+ +#### Inline lists + +When you want to write inline lists with 3 or more items, use the Oxford comma. + +Example 1: Use the Oxford comma when you want to list 3 or more items in a list. + + + + + + + + + + +
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. +
+ +### Parallel phrasing + +Use the same syntax or structure for list items. + + + + + + + + + + +
Do + Don't +
Things I should eat: +
    + +
  • Vegetables + +
  • Beans + +
  • Fruits +
    • +
+ 		Things that I eat: +
    + +
  • I eat chocolate. + +
  • Nutella + +
  • The other day I also ate ice cream. + +
  • Cheesecake is great! +
    • +
+
+ +#### Checklist for lists + + + + + + + + + + + + + + + + + + + + + + + + + + +
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? +
+ +### Tables + +Markdown tables work best for simple tables. +Because of the many limitations that Markdown tables have for complex tables, prefer bullet lists over tables whenever possible. + +Use a table in the following cases: + +* The information consists of two or more parts whose relationship is best captured in a table. +* The tabular format brings out or highlights information in such a way that lists can't capture. +* The table saves a lot of words because there is a clear pattern established by the table that avoids repeating words. + +#### Introductory sentence + +Just like with lists, to clear any assumptions about the content of the table, write a complete sentence to introduce the table, unless the table comes right after a heading and the heading is sufficiently descriptive. +For example, the checklist tables in this document. + +#### Table header + +Tables must have a header. +Use sentence style to capitalize the header. + +#### Checklist for tables + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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? +
+ +### Notes + +Use notes sparingly. +Too many and the topic becomes crowded. +A rough guide is one note per topic. + +Put notes where users are likely to see them or when users are likely to need them. + +### Where to place notes + +* Right before an instruction or a text where the note applies, not after. +* Before tables, images, or graphs. +* At the beginning of a section or topic, not after. + + + + + + + + + + +
+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. +

+ +#### Types of notes + +Use the following list to add notes, ordered by from least important to most important: + +* Tip: Information that might help a user. +* Caution: Crucial information, proceed with caution. +* Warning: Negative consequences of an action, including data loss. + +Guidance for notes in template guides: {ALL CAPS: tip} can be deleted by the users of the template when they fill in the template. + +#### Checklist for notes + + + + + + + + + + + + + + + + + + +
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? +
+ +Sources + +* [Notes | Google developer documentation style guide](https://developers.google.com/style/notices) +* [Note | GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/#note) + +Add some guidance for the verb form to use in specific topics - Google has it. + +## Structure and information organization + +The structure of a template has two parts: one that depends on the specific subject of the template and can differ from template to template, and one that adheres to the Good Docs Project that is common to all templates. +The structure provided by the Good Docs Project consists of boilerplates and template deliverables. + +## Template deliverables + +This section explains file deliverables that template authors need to write as part of each template project. +To understand the larger context for these deliverables, see[Template Contributing Guide](https://gitlab.com/tgdp/templates/-/blob/main/CONTRIBUTING.md). + +### Purpose and use case of each deliverable + +Currently, for a template project to be considered complete, each template project must have these file deliverables: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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." +

+ +Each template deliverable is explained in the following sections. + +### Template file + +Naming convention: template\__content-type_.md + +where: + +* template is a constant. +* _content-type_ is the specific subject that the template is about, for example, template_memo.md is a template for memos. + +The template file is the basic template for the type of document you are creating. +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. +The template user will copy this template and begin filling it in or editing it as their starting point in the writing process. + +#### Content and formatting guidelines + +Each template must have this content: + +* **The template title** - The type of document this template is for. +For example, "Tutorial template" or "README template."" This title must be formatted with the heading 1 weight. +* **Introductory comment** - Include an embedded writing tip at the start that tells users they should first read the accompanying template guide before they fill in the template. +Put introductory comments in {curly brackets}. +* **The template sections** - Each section of the template should begin with a heading with the heading 2 weight. +The recommended content and some embedded writing tips fall under the headings. +* **Embedded writing tips** - You can provide some lightweight writing tips that provide some tips or hints about what kind of content the template user might choose to put in a section of the document. +Put embedded writing tips in {curly brackets}. + +🚩 **NOTE: The basic content of the template depends on the type of document you are creating a template for. +Different types of documents can have widely varying content needs. +While similar document types are likely to require similar structures, other document types may be structured quite differently.** + +#### Frequently asked questions + +**Q: Is it better to include all the possible sections that someone could possibly include in the template file or should it just have the most common sections?** + +A: While this is mostly a judgment call on your part as the template author, it might be better to err on the side of being comprehensive. +Don't forget that in your template guide you can indicate whether it is common or recommended to include this section or not. + +**Q: Can I use heading 3 weights for sub-sections?** + +A: Yes, but try not to go much deeper than level 3. + +### Template guide + +Naming convention: guide\__content-type_.md + +where: + +* guide is a constant. +* _content-type_ is the specific subject that the template is about, for example, guide_memo.md is the guide for the memo template. + +The guide provides a deeper explanation of how to fill in each section of the template. +This guide explains the key decisions that the template user needs to make during the writing process. + +The guide might also optionally include a checklist of the required components for this type of document. + +#### Content and formatting guidelines + +The template guide must follow the same basic structure: + +* **Template guide title** - The type of document this template is for and the words "guide." For example, "Tutorial guide" or "README guide." This title must be formatted with the heading 1 weight. +* **Introductory comment** - Include an embedded writing tip at the start that tells users they should first read this guide before they fill in the template. +This comment could also mention how to get the template file. +Put introductory comments in {curly brackets}. +* **Why do I need this type of document?** - Provide some of the information about the purpose of this type of document and how it helps your documentation project. +The header for this section should be formatted with the heading 2 weight. +* **Content of this template** - This header marks the beginning of the part of the guide that explains how to fill in each section of the guide. +It should be formatted with the heading 2 weight. +* **About the {insert section name here} section** - Next, include each section as they appear in the template with the heading 3 weight. +For example, if your template includes a "Before you start" section, this heading should say "About the before your start section." And then it should provide guidance about what kind of content goes in that section and why that section might be included in the final document. +If the section is optional, indicate why some documents could benefit from that section or why it might be left out. +If the template user needs to make a decision about the content in that section, provide guidance about what should go into that section. + +### Resources + +Naming convention: resources\__content-type_.md + +Where: + +* resources is a constant. +* _content-type_ is the specific subject that the template is about, for example, resources_memo.md is the resource file for the memo template. + +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. + +The resources file has a number of advantages: + + + + + + + + + + + + + + + + + + +
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). +
+ +#### Content and formatting guidelines + +Each resource file must have the following sections: + +* **Template title resources** - The type of document this template is for + "resources". +For example, "Tutorial resources" or "README resources." This title should be formatted with the heading 1 weight. +* **Sources consulted** - Include a bulleted list or table of the sources you consulted while researching this template. +Include a link and/or full citation so that others can find it. +Explain how that source influenced the design decisions in your template. +* **Examples** - Include a bulleted list or table of the examples that served as inspiration for your template. +Include a link and/or full citation so that others can find it. + +### Process + +Naming convention: resources\__content-type_.md + +where: + +* process is a constant. +* _content-type_ is the specific subject that the template is about, for example, process_memo.md is the process file for the memo template. + +This document explains best practices for researching, writing, and maintaining this content type. +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. + +#### Content and formatting guidelines + +Each resource file must have the following sections: + +* **Template title process** - The type of document this template is for + "process". +For example, "Tutorial process" or "README process." This title must be formatted with the heading 1 weight. +* **Researching _content-type_** - Explain best practices for researching this content type. +* **Writing _content-type_** - Explain recommendations for writing this content type. +* **Maintaining _content-type_** - Explain best practices for maintaining this content type over time, such as evaluating its effectiveness and keeping it up to date. +It can also include knowing when to archive that content type if appropriate. + +### Template example (optional) + +Naming convention: example\__content-type_.md + +where: + +* example is a constant. +* _content-type_ is the specific subject that the template is about, for example, example_memo.md is an example file for the memo template. + +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. + +## Format + +To write templates and deliverables, use Markdown. +Suggested guide for Markdown: [Markdown Guide](https://www.markdownguide.org). + +## Related topics + +Accessed on March, 3rd, 2024: + +* [Google Developer Style Guide](https://developers.google.com/style) +* [GitLab Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide) +* [Docs for Developers, Chapter 1 Understand your audience](https://docsfordevelopers.com). +* To help you define the audience, see the Google Technical Writing course, [Audience](https://developers.google.com/tech-writing/one/audience). +* For information about DITA topics, see [DITA topics](https://developers.google.com/tech-writing/one/audience). +* For information about plain language, see [Plain language](https://www.plainlanguage.gov). diff --git a/meta/reference/good-docs-project-template-1.5.0/SUPPORT.md b/meta/reference/good-docs-project-template-1.5.0/SUPPORT.md new file mode 100644 index 00000000..85bc94c0 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/SUPPORT.md @@ -0,0 +1,10 @@ +# Support + +For support with The Good Docs Project templates, click on the feedback form at the end of the specific template you are using. + +We monitor responses to the feedback form and will respond or take action as necessary. + +Alternatively, you can open an issue against any one of our repositories. + +For the templates repository, open a new issue at: +https://gitlab.com/tgdp/templates/-/issues diff --git a/meta/reference/good-docs-project-template-1.5.0/api-getting-started/guide_api-getting-started.md b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/guide_api-getting-started.md new file mode 100644 index 00000000..73dd8b4c --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/guide_api-getting-started.md @@ -0,0 +1,85 @@ +# API getting started 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 getting started guide is a document that walks the user through how to create a minimum working example with your API. You can also think of a getting started guide as a "Hello World" tutorial that includes a complete series of steps or actions that show the user how to use your API. + +| | Getting started guide | Tutorial guide | +| :---- | :---- | :---- | +| Target audience | Domain experts who know the problem space and want a quick setup or overview of your product | Beginners who are new to the problem space and require in-depth and comprehensive guidance | +| Content | Basic steps and essential information | In-depth analysis and broader explanation of concepts | +| Purpose | Help users get started | Provide a comprehensive understanding of the problem space or product | +| Scope | Immediate actions | Immediate actions and comprehensive explanations | + +## Why do I need an API getting started guide? + +API getting started guides are helpful for the following reasons: + +* **Faster integration**: Getting started guides provide the user with a streamlined path to get started with an API without having to read through lengthy documentation to understand key steps to interact with your API, such as setting up an account, getting API keys and authenticating requests for specific endpoints, etc. They typically offer step-by-step instructions, code samples, and ready-to-use templates that help users quickly understand the API's core concepts and functionalities. By following the guide, users can accelerate the integration process and start using the API in their applications faster. +* **Reduced learning curve**: APIs can have complex documentation with various endpoints, parameters, authentication methods, and data formats. Getting started guides distill this information into a concise and simplified format, focusing on the most common and essential use cases. +* **Practical examples**: Getting started guides often include code snippets or sample projects that demonstrate how to interact with the API in real-world scenarios. These examples help users understand the API's capabilities and see how they can integrate it into their own applications. By showcasing practical use cases, the guides provide inspiration and guidance for users to start building with the API quickly. +* **Intended use**: API getting started guides allow for the correct and intended use of the API. Getting started guides also help prevent errors, increase efficiency, and streamline performance. + +## Best practices + +The key goal of a getting started guide is to achieve a basic core working function of the product or feature. Use the following practices when writing the getting started guide: + +* Keep it short and to the point. It should focus on the most important aspects of the API and provide only the essential information needed to get started. +* Provide a common use case with sample code. +* Number the steps and use headings for different procedures. +* Start the headings with a verb for example, "Make your first request", "Choose an endpoint for your request." +* Provide examples of sample return data, so the user can verify that they successfully completed the task. +* Include only one action in a step. +* Include guidance on how to handle errors and provide examples of common error messages. +* Include links to additional resources, so the user can learn more about the API. + +## Content of the API getting started template + +### About the "Introduction" section + +In this section, give a brief introduction or explanation of the API and define the intended audience the guide targets. You should also describe what the user accomplishes or learns by using the getting started guide. For example, to integrate the API into their own app, to build an app with the API or to test the API. + +### About the "Prerequisites" section + +In this section, include all the necessary tools or information the user needs to accomplish the objectives of the getting started guide. Examples include: + +* List of hardware requirements. +* List of any software dependencies. +* How to download (provide the web address), install, and configure the API. +* If your API requires detailed software setup instructions for dependencies, refer the user to the Getting Started Guide or Setup Guide for the API. +* How to get the required access keys or authentication credentials, if required. +* If your API requires detailed authentication information, refer the user to that document. + +### About the "Authentication" section + +This section is optional since not all APIs require authentication to use. Use this section to explain the requirement to get access to the API, which may include signing up for the API, setting up authentication, following the steps to get API keys or access tokens. + +### About the "Base URL" section + +The base URL is the root address of the API, which all API endpoints will be appended to. Provide a base URL at the top of the document to ensure all relative links are consistently referenced, and to simplify the process of updating URLs if the domain or root address changes. + +### About the "Make your first API request" section + +In this section, guide users through making their first CRUD request to the API. Provide clear, step-by-step instructions along with example API responses to help them understand the process. + +To improve usability, consider the following: + +* Code samples: Provide code snippets in relevant programming languages the user can run. The template contains placeholders for your code snippets. +* Comments and explanations: Include in-line comments within the code or provide supporting explanations after each snippet. +* "Hello, World" example: Create a "Hello, World" example that shows how to use at least one of the API endpoints. +* Common error messages: Highlight potential errors users might encounter, along with troubleshooting tips. +* Provide annotated screenshots with arrows, boxes, etc. Bear in mind that screenshots may be difficult to translate so ensure you use them only when relevant. + +### About the "Next steps" section + +In this section, refer the user to other documentation and features available in the API that can help improve the user's understanding and usage of your product. Provide links to: + +* Additional tutorials or articles about the API. +* The API glossary or any additional core concepts. +* Relevant resources, like blogs, troubleshooting guides, reference documents, videos, and how-tos. + +--- + +> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template. diff --git a/meta/reference/good-docs-project-template-1.5.0/api-getting-started/process_api-getting-started.md b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/process_api-getting-started.md new file mode 100644 index 00000000..0262a065 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/process_api-getting-started.md @@ -0,0 +1,55 @@ +# API getting started 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 do you know if you need an API getting started? + +An API getting started guide is targeted at users who have domain knowledge and need to quickly learn how to use an API. It provides a structured introduction to help them get up and running efficiently. + +You need a getting started guide for your API if: + +* The API has key workflows or setup steps that users must understand before making requests. +* You want to reduce onboarding time and improve developer adoption. +* Your API is part of a larger ecosystem, and users need guidance on integrating it with other services. + +## How to determine what content an API getting started needs + +The API getting started template covers the essential components needed for the documentation, such as authentication, requests and response examples, and code blocks. Use the following guidance to enhance the content further: + +* Identify the users (internal or external) and their domain, needs, and goals. +* Identify the primary functional requirements of the API--that's, the business capabilities the API enables. +* Test and understand how the API works yourself to know if you're not leaving out important information in the guide. +* Identify the most common use cases of the API and focus the guide on those cases. You can use some of the following tips: + * Review the getting started guide and documentation of similar APIs in the same domain or industry. + * Analyze your company's support requests and user feedback. + * Speak with stakeholders, such as developers, product managers, or business analysts. + * If the API has usage analytics or metrics available, analyze them to identify the most frequently used endpoints or functionalities. + +## Audience goals + +It's important to identify the audience and their goals so that the API getting started guide provides the most relevant information for the user. These documents are typically targeted for developers. With this in mind, provide information so that they can get started quickly with key information and links to additional information to expand their knowledge of the API. + +## How to introduce an API getting started guide + +Getting started guides typically describe the primary functional requirements of the API or the business capabilities it enables to help developers understand what they can achieve with it. Use the "Introduction" section to provide a clear overview of what developers can achieve with the API. Keep it concise but informative, focusing on key features and practical use cases. + +Refer to the [Resources document](https://docs.google.com/document/d/1s__uFWhkMwWy5qKqTXY4gDaJvC62wCuz499dnC_YyRY/edit?tab=t.0#heading=h.utjrcnv3sr22) for examples and best practices on structuring the introduction effectively. + +## How to write an API getting started guide + +* Include an overview of the capabilities of the API and its benefits to the user or business. See [How to introduce an getting started guide](#how-to-introduce-an-api-getting-started-guide). +* Ensure the steps in the guide are clear, concise, and complete. +* If the guide contains code samples, make sure to verify they work as intended and include their outputs as well. +* Include the desired end result from completing the guide so that users can assess whether they were successful or not. +* Test the getting started guide with someone who was not involved with creating the API. + +## How to maintain an API getting started guide + +* Update code samples as the API evolves. Consult relevant stakeholders whenever a new release occurs or changes happen and update the API getting started accordingly. +* Periodically review the getting started guide to ensure it remains accurate, relevant, and easy to follow. +* Incorporate a feedback mechanism from users to enhance the quality of the guide and improve user experience. +* Embrace versioning. If your API has different versions, ensure the quick start guide clearly specifies which version it relates to. + +--- + +> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template. diff --git a/meta/reference/good-docs-project-template-1.5.0/api-getting-started/resources_api-getting-started.md b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/resources_api-getting-started.md new file mode 100644 index 00000000..913eeb16 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/resources_api-getting-started.md @@ -0,0 +1,22 @@ +# API getting started 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 API getting started guides + +* [**GitHub Rest API Getting Started Guide**](https://docs.github.com/en/rest/using-the-rest-api/getting-started-with-the-rest-api): The GitHub Rest API getting started guide includes most of the necessary sections in a typical getting started guide. It also explains the steps involved in achieving the objectives of the document in a clear and concise manner. Additionally, the guide provides detailed explanations of the key elements that make up an API request, such as HTTP methods, paths, headers, and more. +* [**ClickUp's Getting Started Guide**](https://developer.clickup.com/docs/index): It's common practice for a getting started guide to span multiple pages or documents. The ClickUp getting started guide divides into four sections. These include: a step-by-step guide on setting up authentication for the API, a demo application demonstrating how to integrate the ClickUp API, a downloadable Postman Collection that allows users to explore and make requests to the API, and a page explaining how to test the API directly in a web browser. +* [**Facebook Graph API Getting Started Guide**](https://developers.facebook.com/docs/graph-api/get-started): This guide makes good use of screenshots to visually demonstrate how to use the Graph API Explorer tool, making it easier for users to follow along and understand the process. + +## 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 | +| :---- | :---- | +| [Tom Johnson's Learn API Documentation course](https://idratherbewriting.com/learnapidoc/docapis_doc_getting_started_section.html) | This course provides comprehensive explanations, examples, and processes for creating API documentation. We found the tips and resources in the API Getting Started section of the course invaluable in creating this template. | +| [ReadME's article on effective API quickstarts](https://blog.readme.com/the-most-effective-api-quickstarts-in-8-examples/) | This article provides a useful collection of examples of effective API getting started guides. The getting started examples referenced in the article were helpful in building the template for this guide. | + +--- + +> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template. diff --git a/meta/reference/good-docs-project-template-1.5.0/api-getting-started/template_api-getting-started.md b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/template_api-getting-started.md new file mode 100644 index 00000000..fdee0a25 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/api-getting-started/template_api-getting-started.md @@ -0,0 +1,105 @@ +# {Product} API getting started guide + +{For information about filling in this template, see the accompanying [[API getting started user guide](https://docs.google.com/document/d/1f-_BL2MhfzgoStdEmECw3VMTknFTGkkRavzw4jNFBTQ/edit#heading=h.hsi0enkkga6)].} + +{This template includes writing instructions and boilerplate text so that you can customize the API [getting started user guide](https://docs.google.com/document/d/1f-_BL2MhfzgoStdEmECw3VMTknFTGkkRavzw4jNFBTQ/edit#heading=h.hsi0enkkga6), use it as-is, or completely replace it with your own text. This text is indicated in {curly brackets}. Make sure you delete or replace the content in the curly brackets with your own text.} + +This guide walks you through getting started with the {name of your product} API to {explain what the user will do or accomplish in the guide, such as making GET or POST requests, using the API to create an app, and so on}. + +By the end of this guide, you will be able to: + +* {Objective 1} +* {Objective 2} +* {Objective 3} + +## Prerequisites + +Before you begin, ensure you: + +* Are familiar with {explain the relevant concepts or experience the user needs to have to use the API, such as the REST API experience}. +* Have the following tools installed or set up: + * {Software Prerequisite 1} + * {Software Prerequisite 2} + +## Authentication + +Making a request to the {product name} API requires authentication. Follow these steps to access to the API: + +1. {Sign up for an account} +2. {Request for an API key} +3. {Additional steps as necessary} + +## Base URL + +The base URL for all requests to the API is: + +```text +{https://api.example.com/v2} +``` + +## Make your first API request + +This section demonstrates how to make your first API request to the {product name} API. +To make your first API request: + +1. Select an API endpoint. See the API reference document for a list of endpoints. +2. Use cURL or Postman to make a request. + +### Request + +The following is a sample POST request that sends some sample data to the `tasks` endpoint using cURL: + +```bash +curl -X POST "https://api.example.com/api/1.0/tasks" \ + -H "Accept: application/json" \ + -H "Authorization: Bearer ACCESS_TOKEN" \ + -H "Content-Type: application/json" \ + -d '{ + "data": { + "workspace": "WORKSPACE_GID", + "name": "Sample task", + "assignee": "me" + } +}' +``` + +{The above example code is a boilerplate so ensure you replace it with your own.} + +### Response + +The following is a sample JSON response from the API: + +```bash +{ + "status": "success", + "message": "Task created successfully.", + "data": { + "id": "TASK_GID", + "workspace": "WORKSPACE_GID", + "name": "Sample task", + "assignee": { + "id": "USER_GID", + "name": "John Doe" + }, + "created_at": "2025-02-01T12:00:00Z", + "updated_at": "2025-02-01T12:00:00Z", + "due_date": null, + "completed": false + } +} +``` + +{The above example code is a boilerplate so ensure you replace it with your own.} + +## Next steps + +Congratulations on making your first API request! For additional information, check out the following resources: + +* {Link to other relevant documentation such as API Reference} +* {Link to other features that are available in the API} +* {Provide links to additional tutorials and articles about the API} +* {Provide links to community and support groups, FAQs, troubleshooting guides, etc.} + +--- + +> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template. diff --git a/meta/reference/good-docs-project-template-1.5.0/api-reference/example_api-reference.md b/meta/reference/good-docs-project-template-1.5.0/api-reference/example_api-reference.md new file mode 100644 index 00000000..1e604557 --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/api-reference/example_api-reference.md @@ -0,0 +1,4 @@ +# API reference example + +The Good Docs Project has an official example of this template in action. +You can view this example at the Chronologue documentation site: [Chronologue API Reference](https://chronologue.dev/octavia/api/api-reference_chronologue) diff --git a/meta/reference/good-docs-project-template-1.5.0/api-reference/guide_api-reference.md b/meta/reference/good-docs-project-template-1.5.0/api-reference/guide_api-reference.md new file mode 100644 index 00000000..718d8b2b --- /dev/null +++ b/meta/reference/good-docs-project-template-1.5.0/api-reference/guide_api-reference.md @@ -0,0 +1,271 @@ +# API reference 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 `guide_api-reference` document provides extra writing tips describing how to fill in each of the sections within the [`template_api-reference.md`](/api-reference/template_api-reference.md) file. + +## Overview + +API (Application Programming Interface) references are technical manuals that provide API specifications and integration instructions to help your audience understand the product. The audience can vary based on your product user groups, and they can be technical or non-technical. + +Accurate, concise, well-structured API documentation facilitates efficient adoption of APIs and increases the overall user experience. + +The [`template_api-reference.md`](/api-reference/template_api-reference.md) is designed to help you build the API documentation efficiently and keep it consistent in both format and appearance. While auto-generating API documentation that follow the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification/) is also a common practice, you can use this template when manual edit is unavoidable. + +This template is primarily for documenting [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs. Adjust as needed for other types of APIs. + +## Document structure + +The template assumes that your API documentation set includes references for many API endpoints, which are organized into groups. The template includes three parts: + +* [API overview section](#about-the-api-reference-overview-section) +* [API resource reference section](#about-the-api-resource-name-section) +* [API endpoint reference section](#about-the-api-endpoint-name-section) + +## Before writing the API references + +You may follow these guidelines to help you write better API reference documentation: + +* Familiarize yourself with how to make requests to APIs. If possible, try making some API calls in a testing environment or platform, such as _Postman_. +* Interact with your API developers to learn about the APIs that you are documenting. Understand the data models and the logical connections between the API endpoints. +* Discuss the logic of grouping the API endpoints. Although grouping the endpoints by resource type is a common practice, as used in this template, it is also possible to group them by use case or other characteristics that better suit the user's needs. +* Conduct some user research about how the audience of your documentation would use the APIs. Identify the programming languages that your audience would most likely use to interact with your APIs. +* Explore the possibility of auto-generating the API references. +* Optimize the visual presentation of the API references by applying a customized stylesheet, such as using syntax highlighting, table of contents, multi-column layout, etc. + +## About the "API reference overview" section + +The _API overview_ section in the API reference describes the API components which apply to all endpoints in the API. This section includes information on topics such as protocol, authorization method, versioning, status code. + +### About the "Introduction" section + +Use the _Introduction_ section to provide a high-level overview of your API set, including: + +* Key features +* Use cases +* Communication protocol +* Content types +* Structure + +### About the "Base URL" section + +The base URL is a common segment to which the API endpoint paths are appended. Defining the base URL in this section reduces the effort to duplicate the segment in each endpoint reference. + +The base URL may differ for different groups of users or in different environments. If multiple base URLs are available, list them in this section and clearly describe the conditions of using each of them. + +### About the "Authorization" section + +Use the _Authorization_ section to specify the authentication and authorization requirements of using the APIs, including the authorization type, request schema, possible error codes, and examples. + +**Tips**: + +* Only use this section to describe the technical specifications of the API authorization, such as parameters and token expiration. Details of how to authenticate can be documented in a separate how-to guide and be referred to as a link here. +* Provide an example of the authorization request or command. You can use random strings to replace the actual secrets. +* If there is more than one authorization type applicable to your APIs, describe and specify the use case of each. If one of the options is preferred, highlight it. +* If different permission levels apply to different API endpoints, document the requirements in the reference for that endpoint. + +### About the "Version" section + +This section is optional. If applicable, use the _Version_ section to describe the versioning, compatibility, and lifecycle policies of your API set. If migration guides are available, provide the links here. + +You can create separate documentation sets for each version of APIs. + +### About the "Pagination" section + +This section is optional. If applicable, use the _Pagination_ section to describe the options and default values for dividing long API responses into pages. + +**Tip**: Your readers might not understand what "pagination" is, so embed an explanation in the descriptive text. + +### About the "Rate limiting and throttling" section + +This section is optional. If applicable, use the _Rate limiting and throttling_ section to describe the global rate limiting settings and quota of your APIs. If different quotas apply to different endpoints, also add this section in the reference for endpoints. + +### About the "HTTP status codes" section + +Use the _HTTP status codes_ section to provide the list of HTTP status code that are applicable to your APIs. It is possible that the APIs only return certain types of the standard HTTP status codes. + +**Tips**: + +* For REST APIs, HTTP status codes are used. If you are writing references for other protocols, adjust the table columns. +* In the `Description` column, describe the causes of that error, and provide related information or links about how to deal with the error. + +### About the "Errors" section + +This section is optional. If applicable, use the _Errors_ section to list the custom error types defined for the APIs. For easier navigation, you may provide each of the error definitions as a subsection. + +### Additional sections + +If other specifications are applicable to the whole API set, define your own sections here, for example: + +* Data conventions +* Retry logic +* Logging +* Monitoring +* License +* Contact + +## About the "API {Resource name}" section + +Use the _{Resource name}_ section to provide reference information for a subset of API endpoints that are grouped around a resource type. You can use this section to describe the data model of the resource type. + +The template assumes that the API endpoints are grouped by the resource type that they are interacting with. + +**Title** + +Substitute the document title `{Resource name}` with the actual resource name. The resource name usually uses the same naming convention as in the source code. + +**Short description** + +Provide a one-line definition of the resource in the opening section and explain how and when your users should use it. + +### About the "Data model" section + +Use the _Data model_ section to provide specifications of the resource entity in the table: + +* **Attribute**: the field name or property name defined by the resource. +* **Type**: data type of the value. +* **Required?**: whether the attribute is a required field or not. Use a distinctive font to highlight the required attributes. In this template, capitalized letters are used. +* **Description**: additional information such as whether the attribute has default values, validation restrictions, and whether it is a non-editable field that cannot be updated with POST requests. + +If a cell is empty, fill in "N/A". + +### About the "Example" section + +Provide a concrete example of the data entity with valid values. Fill in as many optional attributes as possible. + +Use preformatted code blocks to make your code distinctive from other text blocks. + +If you are documenting in Markdown, many Markdown processors also support syntax highlighting, which adds color to keywords. Indicate the language mode of your example to take advantage of this feature. The displayed color schema depends on your processor and the rendering configurations. + +### About the "Endpoints" section + +List the endpoints that can interact with this resource type in a table with the following guidelines: + +* Capitalize the method names, for example "GET". +* Adopt a consistent naming convention for the APIs. In most cases, the naming convention used in the documentation should be consistent with the one in the source code. +* Add a link to each of the endpoint names that directs users to the corresponding endpoint reference. +* For endpoints that are deprecated but still in use, add a note in the "Description" column. Consider using the strikethrough format in each cell of the line to indicate the deprecation status. + +## About the "API {Endpoint name}" section + +The _{Endpoint name}_ section provides reference information for a specific API endpoint. It describes the specifications of an API endpoint, such as the method, URL, request, and response schema. + +**Title** + +Substitute the document title `{Endpoint name}` with the actual endpoint name. + +**Tips**: + +* Typically, the name of an API endpoint consists of the operation type and the resource type. For example, an API endpoint that creates a User resource can be named `Create user`. +* As in the API resource reference, the naming convention should be consistent throughout your API documentation. +* Use the singular form of the resource name unless the endpoint is designed exclusively for a bulk operation, such as `List users`. + +**Short description** + +Provide a one-line description of what the API does. Start the description with a verb. For example: + +* For "get" operations: `Retrieves a {resource}.` +* For "list" operations: `Lists {resources}.` +* For "create" operations: `Creates a {resource}.` or `Inserts a {resource}.` +* For "update" operations: `Updates a {resource}.` +* For "delete" operations: `Removes a {resource}.` + +Ensure that the description here is consistent with that listed in the resource reference. + +### About the "Endpoint" section + +Use the _Endpoint_ section to define the API endpoint. + +The name of the endpoint usually starts with a verb in the imperative mood, such as "Retrieve a user." By contrast, the description usually starts with a verb in the indicative mood, such as "Retrieves a user by userID". + +**Tips**: + +* Use preformatted code blocks to make your code distinctive from other text blocks. For example, in HTML, use the `
` 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 levelDefinitionExamples
High
+      
    
+        
  • The incident is extremely severe and/or there is a high likelihood the behavior will occur again in the future.
    • 
+        
  • Incidents that are harassing, dangerous, abusive, violent, offensive (especially to marginalized groups), or which threaten the physical and/or psychological safety of one or more community members are designated as high severity.
    • 
+        
  • Repeated medium- or low-level offenses by the same individual are also automatically designated as high severity.
    • 
+      

+    		
+      
    
+        
  • Sexual assault or unwanted sexual attention
    • 
+        
  • Violent threats or language
    • 
+        
  • Personal attacks
    • 
+        
  • Derogatory language (especially aimed at marginalized groups)
    • 
+        
  • Repeated inappropriate comments after a warning
    • 
+      

+    
Medium
+      
    
+        
  • The incident is moderately severe and is potentially disruptive to the community.
    • 
+        
  • The incident could possibly cause one or more community members to feel unwelcome or uncomfortable in the community.
    • 
+      

+    		
+      
    
+        
  • Mildly inappropriate comments or jokes
    • 
+        
  • Bullying
    • 
+        
  • Tone-policing
    • 
+        
  • Repeatedly dominating a conversation (such as repeatedly talking over another person or not inviting discussion from others where appropriate)
    • 
+        
  • Excessive profanity
    • 
+        
  • Sustained disruptions of community events
    • 
+      

+    
LowThe incident is minor in nature and doesn't pose serious harm or risk of harm.
+      
    
+        
  • Heated discussions or disagreements between community members.
    • 
+      

+    

+
+#### Impact levels
+
+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:
+
+
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+
Impact levelDefinitionExamples
High
+      
    
+        
  • The incident occurred in a public event, in a {Project name} meeting or community event, or on a community forum (such as on a mailing list or in Slack).
    • 
+        
  • The accused individual is a {Project name} leader or a high-profile community member.
    • 
+        
  • Incidents involving someone who was representing {Project name} in an official capacity while the incident occurred.
    • 
+      

+    		
+      
    
+        
  • Comments in the {Project name} Slack or mailing list.
    • 
+        
  • Comments or actions in a {Project name} meeting.
    • 
+        
  • Speaking or participating at a conference or fund-raising event as a representative of {Project name}.
    • 
+      

+    
Low
+      
    
+        
  • The incident occurred in a private conversation, message, or email. Also includes posts or comments made in a forum or context outside of official {Project name} channels, such as on a personal social media account.
    • 
+      

+    		
+      
    
+        
  • Comments in a private email.
    • 
+        
  • Comments in a direct message on Slack.
    • 
+        
  • Comments or actions made in a one-on-one meeting in person or virtually.
    • 
+      

+    

+
+### Recommend
+
+Once an initial severity or impact level has been assigned, the investigating moderator should send a private message to the rest of the community moderators through email.
+Moderators who have recused themselves over conflicts of interest should not be included in this email.
+It would also be appropriate to send a separate direct message on Slack to notify the other moderators to check for the email to ensure everyone is aware of the email.
+
+In the email, indicate your assessment of the incident's severity and impact level and your recommended response.
+See the [Code of Conduct](code-of-conduct.md) for the four possible responses to a conduct violation (correction, warning, temporary ban, permanent ban).
+
+Community moderators have an ethical responsibility to respond as soon as possible and work toward consensus.
+Delaying action in response to the Code of Conduct violation can possibly make the situation worse.
+
+In their response, moderators should indicate whether they agree with the incident severity and impact levels and the recommended response.
+If community moderators disagree with the original assessment, the moderators should indicate the nature of their disagreement. Where disagreements occur, the committee should work quickly to reach a consensus (ideally within 1-2 days) and may require a video conference discussion.
+If a consensus cannot be reached and has ended in a stalemate, the response should be put to a vote.
+In incidents where a tied vote occurs, the chair of the community moderators acts as the deciding vote.
+
+After a response has been recommended, the incident reporter should be notified of the outcome of the investigation and the recommended response before proceeding.
+
+### Respond
+
+Once the incident response has been determined by the community moderators, the investigating moderator should meet with the accused individual in person (either through an online video conference or by phone).
+The moderator may invite an additional moderator to attend the meeting if support is desired.
+
+Before this meeting, the investigating moderator should fill out the [Code of Conduct remediation record](code-of-conduct-remediation-record.md) and use this document to guide the meeting.
+
+In this meeting, the moderator should explain the nature of the reported incident and the specifics of the incident response (correction, warning, temporary ban, permanent ban).
+The accused individual will be given a chance to respond (within reason) and will be informed about the process for appealing the incident response.
+
+If a new Code of Conduct violation occurs in this meeting (such as a derogatory or threatening comment made to a community moderator or about another member of the community), it should be treated as a separate incident and should be reported as a new incident to the community moderators.
+
+If the individual wishes to appeal the incident response, the community moderator can send them a link to this document for information.
+Ensure that the individual is aware that they must still comply with the incident response plan even if an appeal process is underway.
+
+To protect the identity of the incident reporter, the accused individual must not be given the identity of the incident reporter nor will they be allowed to contact the incident reporter, even to apologize.
+If an apology is required as part of the response, the following options are permissible:
+
+* The apology can be delivered to the investigating community moderator who will then deliver it to the incident reporter.
+* The apology may be delivered in a public forum with permission from the investigating community moderator.
+
+During or immediately after the meeting, the investigating moderator should fill out the any additional notes on the [Code of Conduct remediation record](code-of-conduct-remediation-record) to ensure that all information from the meeting has been accurately captured.
+
+### Resolve
+
+The investigating moderator should implement the consequence(s) of the incident response, depending on what the response was.
+The moderator should also follow up with the incident reporter to let them know what the outcome of the report was.
+
+If a temporary ban was implemented, the community moderator who handled the incident should meet with the accused individual to ensure compliance before readmittance into the community.
+
+All documentation should be stored in the {describe where your documents are kept}:
+
+* The [Code of Conduct incident record](code-of-conduct-incident-record.md) form.
+* The [Code of Conduct remediation record](code-of-conduct-remediation-record.md) form.
+
+It is important to file this documentation to enable the community moderators to identify and prevent potential repeated patterns of abuse.
+
+## Handling incident appeals
+
+If an accused individual wants to dispute the decision of the community moderators, that individual is entitled to one appeal.
+An appeal can be requested directly from the community moderators using the same process of reporting an incident.
+That means that the accused individual can send a direct message to one of the community moderators to request an appeal.
+While the appeal process is underway, the accused individual must still comply with the incident response plan.
+
+When an appeal is requested, 2-3 members of {Project name} {team name} will review the incident documentation and the reason for the appeal.
+They will consult with the community moderators about the investigation and decision-making process to determine if the Code of Conduct was fairly and properly applied.
+They will then recommend to uphold, modify, or reverse the original incident response.
+Decisions made by the {Project name} community moderators are final.
+
+## Preventing conflicts of interest
+
+A moderator is considered to have a conflict of interest when any of the following conditions are met:
+
+* The moderator is the individual accused of a Code of Conduct violation.
+* The moderator has a close working or personal relationship with the individual accused of a Code of Conduct violation that could impede their ability to be impartial.
+* The moderator was personally involved in the Code of Conduct violation in some way (such as being the direct target of a Code of Conduct violation). Merely witnessing or being present during the incident does not necessarily qualify as a conflict of interest. Merely being part of a protected group that was targeted in a derogatory statement or action does not necessarily qualify as a conflict of interest.
+
+Moderators that meet any of these conditions should recuse themselves from all discussions and decisions about the incident where they have a conflict of interest.
+Another member of the community moderation team should act as the investigating moderator.
+The moderator with a conflict of interest should ensure that another moderator is designated to handle the incident.
+
+If the accused individual is a leader or prominent member of the {Project name} community, avoidance of a conflict of interest may not be possible as all moderators could possibly have a personal working relationship with the accused individual.
+In this situation, recusal is not necessary and moderators should instead make their best effort to remain impartial.
+
+---
+
+> 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) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct/guide_code-of-conduct.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct/guide_code-of-conduct.md
new file mode 100644
index 00000000..ee1f8767
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct/guide_code-of-conduct.md
@@ -0,0 +1,137 @@
+# Code of Conduct 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, 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/template_our-team.md) 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?
+
+A Code of Conduct is a lot like a good insurance policy: hopefully you'll never have to enforce it.
+However, if or when a problem occurs in your community, you'll be glad that your Code of Conduct is there to support you.
+
+A Code of Conduct has many purposes and benefits. It can:
+
+* Help you define and clearly communicate your organization's mission, values, and guiding principles.
+* Encourage members of your community to behave ethically and inclusively.
+* Make your community a better place to collaborate and work.
+* Demonstrate to prospective community members that your community is one that is warm, welcoming, and safe to join.
+
+But it's not enough to merely have a Code of Conduct.
+You should also have a clear plan for how your team will respond if a Code of Conduct incident occurs.
+Your response plan should include important details, such as:
+
+* How incidents are reported and documented.
+* Who will receive and handle Code of Conduct incidents.
+* How incidents are investigated and resolved.
+* How you will handle appeals or potential conflicts of interest.
+
+When you have a well-defined Code of Conduct response plan in addition to a Code of Conduct, it demonstrates that your community takes its ethical responsibilities seriously.
+It means that you are willing to do more than simply talk about your community values: you will actively live by them.
+
+Hopefully, as you create your Code of Conduct and your response plan, your community's leaders will have many important conversations about your community values and you will carefully think through the logistics of promoting and upholding those values in your community.
+
+## Maintenance strategy
+
+A Code of Conduct is considered a foundational document for a healthy open source community.
+For that reason, it is important to review your Code of Conduct and your response plan regularly to make sure it hasn't gone stale and still meets your community's needs.
+
+If you do have a Code of Conduct incident, consider holding a retrospective meeting shortly after resolving a Code of Conduct incident to make sure your Code of Conduct and response plan was effective.
+
+In addition to retrospectives, 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.
+
+## Content of the Code of Conduct template
+
+The following sections provide guidance about how to fill out each section of the Code of Conduct template.
+
+:information_source: The Code of Conduct 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 "Opening statement of purpose" section
+
+The first section in the template is where you'll put your opening statement of purpose.
+Your opening statement should include information about your core values and the purpose of your Code of Conduct.
+
+### About the "Expected behavior" section
+
+An effective Code of Conduct can help your community feel more warm and welcoming if it starts with a section outlining the positive, prosocial behaviors you'd like to see in your community.
+In the *Expected behavior* section, you can list the specific behaviors and attitudes that best support the ethical values you mentioned in your opening statement.
+
+### About the "Behavior that will not be tolerated" section
+
+The *Behavior that will not be tolerated* section is extremely important, so you should definitely include this section in your final draft.
+Due to differences in culture and upbringing, some community members might not actually be aware of what behavior is considered unacceptable.
+For that reason, you need to clearly explain the specific behaviors that are not allowed in your community.
+
+As the authors of the [Code of Conduct book](https://frameshiftconsulting.com/resources/code-of-conduct-book/) state: "People often overestimate the level of shared values they have with other people in their community, which is why it is helpful to state your community's values explicitly."
+
+### About the "Consequences of unacceptable behavior" section
+
+The *Consequences of unacceptable behavior* section is also very important because you want to be transparent about what actions your team might take when resolving Code of Conduct incidents.
+
+This section should include:
+
+* Instructions or links for reporting a Code of Conduct incident, such as a link to your Code of Conduct response plan.
+* A list of the possible consequences that could result from a Code of Conduct violation.
+* A statement indicating that compliance is necessary.
+
+### About the "Reporting an incident" section
+
+The *Reporting an incident* section should include clear instructions for reporting Code of Conduct violations.
+In this section, try to communicate that your moderators are approachable and that you encourage community members to reach out, even if they're not sure if the incident is a violation or not.
+Not all community members necessarily want to file an official report and may instead just want to discuss their concerns in private.
+
+### About the "Addressing Code of Conduct reports" section
+
+In this section, include a general statement about how Code of Conduct reports will be handled and adjudicated.
+This section could include:
+
+* A statement that complaints will be reviewed and investigated promptly and fairly.
+* A privacy policy.
+* The appeals process
+* A notice that an internal record will be kept for all incidents.
+
+Consider adding a link to your [Code of Conduct response plan](../code-of-conduct-response-plan/template_code-of-conduct-response-plan.md) to this section for more details.
+
+### About the "Where this Code of Conduct applies" section
+
+This section indicates the spaces in which the Code of Conduct applies.
+Include the main spaces where your community officially communicates with one another or where project leaders might represent the project publicly.
+Examples can include conferences, meetups, community forums, and social media platforms.
+
+### About the "Related resources" section
+
+Use the *Related resources* section to link out to helpful resources, such as  [Code of Conduct response plan](../code-of-conduct-response-plan/template_code-of-conduct-response-plan.md) and your [Our team page](../our-team/template_our-team.md).
+
+You can also include any articles that inspired your values as you wrote your Code of Conduct.
+
+## Additional resources
+
+In creating this Code of Conduct, the authors adapted or were inspired by the following resources, listed alphabetically:
+
+* [Ada Initiative](https://adainitiative.org/continue-our-work/conference-policies/)
+* [Apache Foundation Code of Conduct](http://www.apache.org/foundation/policies/conduct#code-of-conduct)
+* [Citizen Code of Conduct](https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md)
+* [The Code of Conduct Book](https://frameshiftconsulting.com/resources/code-of-conduct-book/)
+* [Contributor Covenant 2.0](https://www.contributor-covenant.org/version/2/0/code_of_conduct/)
+* [Django Code of Conduct](https://www.djangoproject.com/conduct/)
+* [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/)
+* [No more rock stars: how to stop abuse in tech communities](https://hypatia.ca/2016/06/21/no-more-rock-stars/)
+* [Otter Tech Code of Conduct Enforcement Training](https://otter.technology/code-of-conduct-training/)
+* [Rust Community Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct)
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/code-of-conduct/template_code-of-conduct.md b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct/template_code-of-conduct.md
new file mode 100644
index 00000000..ae7f0bcf
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/code-of-conduct/template_code-of-conduct.md
@@ -0,0 +1,136 @@
+# {Organization name} Code of Conduct
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_code-of-conduct.md).
+
+---
+
+{Include your project's opening statement of purpose in this section.
+Replace your own project's name in the indicated placeholder text.
+You are welcome to customize or reword this boilerplate text as needed.
+Alternatively, you can write your own project's statement of purpose from scratch.}
+
+{Project name} and its members, contributors, sponsors, and leaders pledge to make participation in our community a positive, inclusive, and safe experience for all.
+{Project name} encourages contributions from everyone who shares our goals and wants to participate in a healthy, constructive, and professional manner.
+
+This Code of Conduct aims to support a community where all people should feel safe to participate, to introduce new ideas, and to inspire others.
+This includes everyone, regardless of: ability, age, background, body size or type, caste, disability (either visible or invisible), education, ethnicity, family status, gender, gender identity and expression, geographic location, level of
+experience, marital status, nationality or national origin, native language, personal appearance, race, religion, sexual identity and orientation, socio-economic status, or any other dimension of diversity.
+
+Openness and respectful collaboration are core values at {Project name}.
+We are committed to being a community that everyone feels good about joining, and we will always work to treat everyone well.
+No matter how you identify yourself or how others perceive you, you are welcome.
+We gain strength from diversity and actively seek participation from those who enhance it.
+
+These guidelines exist to enable all {Project name} community members to collaborate effectively.
+As such, this document outlines both expected behavior and behavior that will not be tolerated.
+The Code of Conduct isn't an exhaustive list of things that you must do or can't do.
+Rather, take it in the spirit in which it's intended.
+It's a set of guidelines to make it easier to enrich our community.
+
+## Expected behavior
+
+We expect our members, contributors, and leaders to:
+
+* Participate in the community actively and authentically. Your meaningful contributions add to the health and longevity of this community.
+* When you make commitments, do your best to keep those commitments. Other community members will trust you and build confidence in you if you fulfill your promises. If something may prevent you from keeping a commitment or if you discover you won't be able to complete a task on time, try to notify others as soon as possible.
+* Attempt collaboration before conflict. Seek out and be respectful of differing opinions, styles, viewpoints, and experiences.
+* Give and accept constructive feedback, gracefully. When expressing disagreement, be professional and respectful. Be open to learning from and educating others where needed.
+* Demonstrate empathy and kindness toward other people. Be considerate and respectful in your word choice, speech, and actions. Show respect with the terms you use to address others.
+* Look out for those around you in the community, especially if you are in a position of influence. Alert the {Project name} {link to your community moderators document [community moderators](../our-team/template_our-team.md)} if you notice a dangerous situation, someone in distress, or violations of this Code of Conduct, even if they seem inconsequential.
+* Gracefully accept responsibility and apologize to those affected by any mistakes, whether made intentionally or unintentionally. If someone says they have been harmed through your words or actions, listen carefully, make amends, learn from the experience, and correct the behavior going forward.
+* Focus on what is best for the overall community, not just for each of us individually. Ensure that leadership roles and opportunities are well-distributed across the community membership and not just centered in one person or the same few people. To help our community develop and build up leaders at every level of the {Project name}, ensure that you share knowledge with others as much as possible and be mindful of fostering healthy dialogue where no one voice dominates a conversation.
+
+## Behavior that will not be tolerated
+
+The following behaviors are unacceptable within our community, whether they occur online, offline, privately, or publicly:
+
+* Violent language or threats directed against another person.
+* Sexist, racist, or otherwise discriminatory jokes and language.
+* Deliberate intimidation, following, or stalking (online or in person).
+* Personal insults, especially those related to gender, sexual orientation, race, religion, or disability. This includes misgendering, name calling, and mockery.
+* Trolling (posting controversial comments in order to provoke others), insulting, or making derogatory comments.
+* The use of sexualized language, jokes, or imagery, and sexual attention, inappropriate physical contact, or sexual advances of any kind.
+* Bullying, tone-policing (attacking a person's tone rather than the content of their message), or repeatedly dominating a topic of conversation (such as regularly talking over another person or not inviting discussion from others where appropriate).
+* Publishing or threatening to publish others' private information without their explicit permission. Private information includes physical addresses, email addresses, and emails or other communications sent privately or non-publicly.
+* Deliberate "outing" of any private aspect of a person's identity without their consent except as necessary to protect vulnerable people from intentional abuse. This includes sharing personally identifying information ("doxing").
+* Excessive or unnecessary profanity.
+* Deliberate misgendering.
+* Knowingly making harmful false claims about a person.
+* Pushing a person to drink alcohol when they don't want to drink, or deceiving someone into drinking alcohol.
+* Marketing to our community members either individually or collectively without their express approval. Solicitations on behalf of your business should be restricted to designated channels or areas. For more information about appropriate ways to market your business to the community, ask one of the {Project name} {link to your community moderators document [community moderators](../our-team/template_our-team.md)}.
+* Repeatedly communicating with a community member who has asked you to leave them alone.
+* Sustained disruption of community events, including meetings and presentations.
+* Recording or photography at community meetings and events without explicit permission.
+* Advocating for, or encouraging, any of the above behavior.
+* Other conduct which could reasonably be considered inappropriate in a professional setting.
+
+## Consequences of unacceptable behavior
+
+Unacceptable behavior from any {Project name} community member, contributor, sponsors, or leaders will not be tolerated.
+We expect everyone to comply with requests to stop unacceptable behavior immediately.
+
+If any community member engages in unacceptable behavior, any community member or moderator should report the incident to the {Project name} {link to your community moderators document [community moderators](../our-team/template_our-team.md)}.
+The moderators will investigate the incident to determine the incident's severity and overall impact to the community.
+See our {link to your [Code of Conduct response plan](../code-of-conduct-response-plan/template_code-of-conduct-response-plan.md)} for more details.
+
+Depending on the risk and impact level, the moderators may respond by requiring:
+
+* **Correction:** A private, written warning from community moderators, providing clarity around the nature of the violation, an explanation of why the behavior was inappropriate, and what behavior is expected going forward. A public apology may be requested.
+* **Warning:** A warning with consequences for continued behavior. No interaction with the people involved is allowed for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media and it includes unsolicited interaction with community moderators. Violating these terms may lead to a temporary or permanent ban.
+* **Temporary ban:** A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with community moderators, is allowed during this period. Violating these terms may lead to a permanent ban. Readmittance to the community usually requires an additional meeting with a community moderator to ensure future compliance.
+* **Permanent ban:** A permanent ban from any sort of public interaction within the community.
+
+The action taken is at the discretion of the {Project name} {link to your community moderators document [community moderators](../our-team/template_our-team.md)}.
+Participants are expected to comply immediately, and further action may be taken in case a participant does not comply.
+
+Every community member is entitled to one appeal using the [same process for reporting a Code of Conduct incident](#reporting-an-incident).
+Community members are expected to comply with the requested action while appeals are being considered.
+After an appeal has been resolved, the decision is considered final.
+
+## Reporting an incident
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to one of the {Project name}
+{link to your community moderators document [community moderators](../our-team/template_our-team.md)}.
+If you would like to discuss your concerns or if you have personally experienced unacceptable behavior, please reach out to a community moderator as soon as possible.
+
+We encourage reaching out to a community moderator, even if you are unsure whether something counts as a Code of Conduct incident or even if the situation is merely something you observed and did not happen to you directly.
+
+Please reach out as soon as possible if:
+
+* You would like to discuss any concerns.
+* You have personally experienced unacceptable or potentially unacceptable behavior.
+* You want to report a situation happening to someone else.
+
+## Addressing Code of Conduct reports
+
+All complaints will be reviewed and investigated promptly and fairly.
+If possible, community moderators will recuse themselves in cases where there is a conflict of interest.
+See our {link to your [Code of Conduct response plan](../code-of-conduct-response-plan/template_code-of-conduct-response-plan.md)} for more details.
+
+An internal record will be kept of all incidents.
+However, all community leaders are obligated to respect the privacy and security of the reporter of any incident.
+In some cases, community moderators may determine that a public statement will need to be made.
+If that's the case, the identities of all victims and reporters will remain confidential unless those individuals instruct us otherwise.
+
+If you feel you have been unfairly accused of violating these guidelines, please follow the [same process for reporting a Code of Conduct incident](#reporting-an-incident).
+
+## Where this Code of Conduct applies
+
+These guidelines apply to all members of the {Project name} and to all {Project name} activities, including but not limited to:
+
+* Representing the {Project name} at public events and in social media.
+* Participating in the {Project name} meetings and events, whether virtual or in person.
+* Participating in the {Project name}'s related messaging forums, including our Slack workspace and mailing list and other {Project name}-related correspondence.
+* Interpersonal communications between {Project name} community members, whether virtual or in person.
+
+While this Code of Conduct applies specifically to the {Project name}'s work and community, it is possible for actions taken outside of the{Project name}'s online or in-person spaces to have a deep impact on community health if it concerns the {Project name} or its members in some way.
+The Code of Conduct moderators reserve the right to consider communications or actions that occur outside of official {Project name} spaces if they have a demonstrated impact on one or more community members.
+
+## Related resources
+
+{Include a list of links to related resources, such as your Code of Conduct Response Plan and the Our Team page where you list who can be contacted to report Code of Conduct incidents.
+You can also include additional information, such as links to articles that explain the rationale behind your Code of Conduct.}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Code%20of%20conduct) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/concept/example_concept.md b/meta/reference/good-docs-project-template-1.5.0/concept/example_concept.md
new file mode 100644
index 00000000..53541312
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/concept/example_concept.md
@@ -0,0 +1,4 @@
+# Concept example
+
+The Good Docs Project has an official example of this template in action.
+You can view this example at the Chronologue documentation site: [How Chronologue works](https://chronologue.dev/octavia/concept_coordinate-system)
diff --git a/meta/reference/good-docs-project-template-1.5.0/concept/guide_concept.md b/meta/reference/good-docs-project-template-1.5.0/concept/guide_concept.md
new file mode 100644
index 00000000..8f230883
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/concept/guide_concept.md
@@ -0,0 +1,253 @@
+# Concept 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).
+
+## What is a concept doc?
+
+A concept document serves as a comprehensive guide, offering clear, concise, and consistent information on a specific concept or process.
+It acts as a roadmap, logically organizing information to enhance comprehension and readability.
+By providing essential background information, it enables readers to align their existing knowledge with the tasks they need to perform and gain valuable insights into products, processes, or systems.
+
+For instance, a concept document called "Object-oriented programming" would offer a structured explanation of the core principles of OOP, helping team members gain a deeper understanding of this programming paradigm and serving as a bridge towards implementing OOP effectively in software development projects and facilitating the application of these principles in practice.
+
+Concept documents can be thought of as extended definitions of major abstractions, such as a mechanism or a function.
+They help explain the context and components of a product or service and how these elements fit into a broader framework.
+
+## Why do I need a concept doc?
+
+A concept document is important for conveying foundational ideas or processes.
+The key reasons why a concept document is integral include the following:
+
+* **Alignment and collaboration**: A concept document serves as a shared point of reference for businesses and teams, holding high-level ideas and enabling all stakeholders to align their understanding and expectations.
+By having a shared document that holds the ideas, it is much easier to communicate ideas and track progress.
+Having a central description of core concepts reduces repeated explanations through a document.
+It is much easier to have a concept document that can then be referenced when needed.
+* **Reader comprehension**: Concept documents are important because they provide foundational knowledge and background that gives readers context that will help in understanding more specific content.
+
+  Readers can see the connections and relationships between different elements, helping them make informed decisions about your product.
+  Decision-making is much easier to do if the reader understands the broader context.
+  A concept doc presents information at the appropriate level of detail to help readers:
+
+  * Proceed to other types of content, such as how-tos and reference, with all the foundational knowledge, background and context necessary to use the tool or system.
+  * Make an informed decision about using certain features of your solution and prioritize efforts throughout the development process.
+  * Know how certain concepts relate to the broader context.
+  They can see the connections and relationships between different elements and how they fit into a bigger picture.
+
+## Where is its place in the whole documentation?
+
+A concept document provides the necessary context and foundational understanding for new ideas, processes or features that are introduced.
+They act as a bridge between the overall ideas and the more detailed instructions or guides, allowing readers to understand the core of what is going on before they move on to more complex operations.
+It also acts as a primer for users who are not yet ready to dive into concrete operations or step-by-step guides.
+By presenting the core concepts and principles in a clear and structured manner, the concept doc gradually develops the reader's understanding.
+
+## How does the reader get to this document?
+
+In the reader's critical user journey through documentation, a concept document is usually in the early sections.
+While concept documents are commonly found at the beginning of documentation, they can also appear throughout when introducing new concepts to provide the necessary context.
+
+There are two main options here:
+
+1. Users start their journey with this document or land here from the search results.
+2. Users get there in the middle of their journey because they stumbled upon an unknown concept.
+In this case, the document serves as a middle layer (to make a decision about using this concept).
+
+Ryan Young in the talk "Is it (layer) cake: Thinking in content levels" calls this approach a layered cake (of content).
+Users use mid-level documentation to close the gaps between low (execution) and high (overview) level.
+You will use them to help users decide what to do next. Therefore, you can present integration guides, use cases, and broad concepts on this level.
+
+It is important to notice that users will not follow a defined flow through the documentation.
+They may jump through different levels of content as they need to.
+
+They may land in your concept document by clicking a link in the How-to document prerequisites or by clicking a link from a related concept document.
+
+Understanding these pathways is essential for tailoring the content to meet the varying needs of users who either start their exploration with the concept or arrive here as part of an ongoing information quest.
+
+## Contents of the concept document
+
+Sections which should exist in a concept template include:
+
+### (Optional) An introductory paragraph
+
+Optionally, you may begin the document with an introductory paragraph before diving into the definition.
+This introductory paragraph can set the stage, explaining the concept's relevance and importance.
+It provides readers with a context for what they're about to learn and what they can expect in the document.
+
+Apply the inverted pyramid technique here by starting with a high-level overview.
+
+You may skip it and jump right into the definition section.
+
+### Giving a definition
+
+Define the concept so that you and your reader will have a shared understanding of the language used throughout the document.
+Think of it as a glossary definition.
+
+This is a good moment to define the scope of the concept - define its boundaries, what you'll cover in a document and how deep into details you will dive and the extent of the details you will provide.
+
+It may be useful to define what is out of scope - what you don't mean by that concept and what won't be covered.
+If the concept has synonyms in other spheres or products, it may be useful to explicitly disassociate from them in this section of the document to ensure a uniform understanding of the concept.
+
+Provide an overview of how the concept fits into a bigger picture.
+This involves explaining how the concept interacts with other concepts [already known by your audience](#use-known-concepts-and-examples), provided you have knowledge of their level of understanding.
+Additionally, you can break down the concept into smaller, more digestible pieces.
+By doing so, you help your readers make connections, recognize patterns, and gain a deeper understanding of the subject matter.
+
+Sometimes, concepts are explained by using [analogies](#metaphors-and-analogies) that the user should be familiar with.
+For example, while explaining the complex topic of how electricity goes through wires, you could relate it to a more familiar topic, such as how water goes through pipes.
+It helps to bridge knowledge gaps.
+
+Also, when you give a definition, it may be useful to stick to problem-solution or benefit-focused language.
+
+### (Optional) A visual aid or a diagram
+
+Use a diagram to illustrate how the concept is organized or how it fits into a broader system; a decision tree, a flow chart, or a system overview diagram is best suited for these tasks.
+
+Usually a concept is best explained with one diagram.
+This primary diagram should be placed close to the top, typically under the description.
+Presenting the diagram early helps draw the reader in, and helps them orient themselves visually.
+
+Sometimes multiple diagrams should be used to explain different aspects of the concept, and these should be placed next to relevant annotations about it.
+
+To enhance the clarity of a diagram illustrating a process related to the concept, consider adding numbered elements within the diagram itself.
+Additionally, including a legend positioned at the bottom of the picture can explain the meaning behind each numbered component.
+
+Diagrams are most valuable when they simplify complex relationships, depict processes, or illustrate hierarchies.
+Be cautious not to overwhelm the document with unnecessary visuals if the concept is easily explained through text alone.
+
+### (Optional) About the "Background" section
+
+The background section may describe the prehistory of the concept if it is important for better understanding.
+You can provide relevant information and context that helps readers understand the following contexts:
+
+* Historical background (where the idea originated from, is there any legacy that made it work like that).
+* Industry context (any significant changes in the sector you're working in that influenced the concept).
+* Market and technology trends, any new disruptive technologies that appear (Artificial Intelligence(AI)), business trends (recession, remote work), or industry regulations (for instance, General Data Protection Regulation (EU GDPR)).
+
+It can describe how or why something was designed or developed, what decisions were made in the past and why.
+In addition, you can describe the alternatives.
+
+### About the "Use cases" section
+
+The use cases section is a good place to apply the StoryBrand framework (referred in the [Resources document](resources_concept.md)) to engage readers and add more storytelling elements.
+Storytelling helps engage users and memorize concepts by association with the story.
+Research in neuroscience has revealed that narratives, such as those applied in the StoryBrand framework, engage multiple areas of the brain and the distinction between reading and real-life gets blurred.
+Read more regarding that in the [Resources document](resources_concept.md).
+
+The Storybrand technique is a specific approach to storytelling that involves framing the story in terms of a protagonist who has a problem and needs a guide to help them solve it.
+The concept or solution being presented is positioned as the guide that can help the protagonist overcome their challenges and achieve their goals.
+By framing the concept in this way, the reader is more likely to engage with the story and see the product as a valuable solution to their problems.
+
+1. Make your user a protagonist of the story.
+2. Define what challenges they're facing, so you can craft a story that resonates with them.
+3. Set the stage for the story.
+Highlight the specific problem or obstacle that your target audience is encountering.
+Make it relatable and evoke empathy.
+4. Position your concept or feature as the guide that can help the protagonist overcome their challenges and achieve their goals.
+Outline the steps or key concepts that the user needs to understand to effectively use the product or feature.
+5. Illustrate how the user's life or business can be transformed by using a concept.
+
+For example, you're talking about the containerisation concept, and your "protagonist" is a system administrator in a large company, and they are experiencing numerous typical problems, such as slow deployments, difficulty scaling up service, or frequent power outages.
+So you act as a guide and introduce the "protagonist" to containerised applications, their infrastructure and how various aspects of these solve the protagonist's problems.
+
+By following this framework, you can create a concept document that captures attention, communicates the value of your product or feature, and motivates readers to take action.
+
+When using storytelling as a technique in a concept document, it's essential to strike a delicate balance between engaging the reader and ensuring that the concept remains relevant and comprehensible.
+A common pitfall for writers is becoming overly enthusiastic about their story, which can lead to an overload of information that might distract from the core concept.
+Thus, as you weave a story into your concept, always consider how it enhances understanding rather than overwhelming your audience with unnecessary details.
+
+### (Optional) About the "Comparison" section
+
+If the concept has few implementations, versions, or types, or it has a direct preeceder, you may put in a comparison table.
+This table helps answer questions such as:
+
+* What is the difference between this element and a similar element?
+* Why do I need to choose a certain option?
+
+| What                  | Why needed         |
+|-----------------------|--------------------|
+| {concept} type 1      | A reason to use it |
+| {concept} type 2      | A reason to use it |
+
+### (Optional) About the "Related resources" section
+
+Provide links or references to additional resources that can help readers explore the topic further or dive deeper into specific aspects of the concept.
+
+If you have many related links, split them into a few groups (for example, How-to's, Linked concepts, External materials, etc.), not more than 3-5 links each, to avoid overwhelming a reader with a wall of links.
+
+## Best practices for concept documents
+
+Within the realm of concept documents, there exist dozens of valid approaches and documentation techniques.
+Each author, armed with their experience, must choose the right technique tailored to the specific demands of the task at hand.
+
+Concept documents are more than just collections of ideas; they're a careful mix of clarity and detail.
+Crafting them requires skill in both technical and narrative aspects, making it a significant challenge.
+Choosing the right technique involves navigating communication intricacies to ensure that the document resonates with its audience, serving as a beacon of understanding in the vast amount of information.
+
+Here are the key practices for crafting an effective concept document:
+
+### Scope
+
+The scope of your concept document is a foundational element.
+It should be dedicated to a single concept and strike a balance between comprehensiveness and relevance.
+Here's how to define the scope:
+
+* **Dedicate to a single concept**: Ensure that your document focuses on just one concept to prevent confusion or information overload.
+If the explanation begins to explain another concept, it is advisable to start a different concept document and provide a link.
+* **Avoid instructional and referential information**: The concept document should also avoid instructional text and step-by-step guides which are different types of documentation.
+* **Select the right depth of understanding**: Dive deep enough to provide a thorough understanding without overwhelming the reader.
+* **Define essential information**: Consider what would be valuable to someone who has never encountered the concept before. Use this perspective to define the scope.
+
+### Structure
+
+A well-structured concept document is crucial for enabling readers to
+incrementally build their understanding of the concept.
+
+Consider the following practices:
+
+* **Inverted pyramid technique**: Consider using the inverted pyramid technique, where you start with a high-level overview and then gradually delve into the details. This approach helps readers quickly grasp the main idea and then explore further as needed.
+* **Definition**: Provide a clear and concise definition of the concept.
+* **Key questions**: Address the key questions of what, when, who, why, where, and how (5W and 1H), placing these explanations near the beginning of your document. One more technique is to answer the question "How can I use it" or "How it helps me" from the reader's perspective.
+* **Headings and subheadings**: Organize your ideas using headings and subheadings to enhance readability and accessibility.
+* **Chunking**: Break down complex concepts into smaller parts, and use abstraction to focus on the most important information.
+* **Real-world examples**: Include real-world examples and use cases to provide context and help readers understand how the concept is applied.
+
+### Language
+
+The language used in your concept document should prioritize clarity and simplicity, tailored to the audience's expertise level. 
+To enhance accessibility:
+
+* **Minimize jargon**: Strive to minimize the use of domain-specific jargon and technical terms to make the document more accessible, especially for new users.
+* **Conversational tone**: Maintain a conversational tone that fully engages the reader.
+* **Avoid implementation details**: Stay clear of delving into implementation-specific details, as your document should focus on the conceptual content.
+
+### Metaphors and analogies
+
+Metaphors and analogies are effective tools for enhancing the relatability and clarity of your concept document.
+When using them:
+
+* **When to use metaphors and analogies**: Use them when they enhance understanding, align with your audience's background, and bring clarity and context.
+* **When to be cautious**: Exercise caution when there's a potential lack of understanding due to cultural, age, or background differences or when they might complicate the concept.
+
+A List Apart style guide (referred in the [Resources document](resources_concept.md)) advises avoiding extended metaphors if possible, so think case by case whether your audience will understand them and if it adds anything to their understanding.
+
+Best practices for metaphors and analogies:
+
+* **Opt for universal metaphors**: Choose universal metaphors that are culture, age, and background-independent.
+* **Ensure alignment**: Ensure that the metaphor or analogy seamlessly aligns with the concept and enhances clarity.
+* **Understand your audience**: Consider your audience's familiarity with the chosen metaphor before incorporating it into your document.
+
+While universal metaphors are generally safe and reliable, they may not always be as engaging or memorable as more specific or popular culture references.
+The decision to use universal metaphors or pop-culture references should be guided by your understanding of your target audience, concept complexity, and the specific goals of your concept document.
+
+Analogies act as memory aids, turning abstract ideas into tangible mental images.
+These mental images can serve as reference points when your audience needs to recall the concept or explain it to others.
+
+### Use known concepts and examples
+
+Connect complex ideas with familiar concepts or examples to enhance understanding:
+
+* **Pick familiar comparisons**: Choose comparisons and examples that are easy to understand, considering your audience's background.
+* **Enhance understanding**: Linking new information to known concepts helps readers grasp the new information more effectively.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Concept%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/concept/process_concept.md b/meta/reference/good-docs-project-template-1.5.0/concept/process_concept.md
new file mode 100644
index 00000000..c08fbe77
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/concept/process_concept.md
@@ -0,0 +1,241 @@
+# Concept template 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+This document explains best practices for researching, writing, and
+maintaining a concept document. It extends and structures the
+information described in the template guide in a step-by-step way. As
+you explore this process document, you'll gain insights into crafting
+clear and consistent concept documents.
+
+## Before writing a concept document
+
+Before you begin working on your concept document, you may take the
+following preparatory steps to ensure that you are well-equipped to
+create a comprehensive and effective document:
+
+* **Learn about your audience**: Understand your target audience or
+    audiences, their familiarity with the subject matter, roles,
+    responsibilities, and specific needs or pain points. This knowledge
+    will empower you to tailor the document's content and language
+    effectively.
+
+* **Map out the concept**: Create an overview or map of the concept,
+    including its connections to other concepts, its place within the
+    broader system, and dependencies. This step helps your understanding
+    and may later serve as a visual aid in your concept document. See
+    the [Visual aid](#create-visual-aids-for-a-concept-document) section below.
+
+* **Explore the concept's background**: Gain insights into the
+    prehistory, background, and any limitations that have shaped the
+    concept. Engage with developers or project managers to grasp the
+    broader context in which the concept operates.
+
+* **Define scope and boundaries**: Clearly outline what the concept
+    encompasses and what it does not, research information within these
+    boundaries.
+
+* **Collect common questions and concerns**: Review internal chats,
+    external support systems, or public discussions to gather common
+    questions and concerns related to the concept. Look for inquiries
+    such as "What is it?" "Why do I need it?" "Why not use {Y}?"
+    "When shouldn't I use it?" to anticipate and address them in your
+    document.
+
+## A guide to naming your concept document
+
+There is a difference between the type of information and the actual
+document titles. The type of information is usually called Concept (used
+in GitLab and DITA frameworks) or Explanation (used by Diataxis
+framework).
+
+Both terms refer to the same document type: a high-level overview of a specific
+topic/concept/feature that helps a user to understand complex ideas and context.
+For the purposes of this template, they will be treated as synonyms.
+
+Within a documentation set, you have some flexibility in the title
+naming convention. Common title options include:
+
+* Overview of {concept or subject}
+
+* Introduction to {concept or subject}
+
+* About {concept or subject}
+
+* Understanding {concept or subject}
+
+* Background
+
+* Name of the {concept or subject} as a noun. For example: Payments. Note that GitLab recommended this option as the primary option in their contributing guide.
+
+Less common options include:
+
+* Crash Course
+
+* {concept or subject 101}
+
+* {concept} Tour
+
+Avoid using titles such as "Overview" or "Introduction" without any
+additional nouns that describe the topic of the concept documentation.
+Vague titles are less discoverable.
+
+In concept documentation, avoid vague titles like "Overview" or "Introduction" as they hinder discoverability,
+impacting SEO. These titles offer no clear indication of content, reducing visibility on search engines
+and hindering user experience, including omission from search result snippets.
+
+For SEO optimization, use descriptive and
+keyword-rich titles that clearly convey the main topic or concept
+covered in the document. This not only improves discoverability but also
+helps search engines understand the content's relevance to specific
+queries.
+
+**Note:** *Do not confuse a Concept document which is a part of
+technical documentation with two other types of documents that are also
+referred to as 'Concept Documents'. One of them is a Proposal or a
+Request For Comments (RFC). The other is a component of the Game Design
+Document (GDD). Both are commonly known as concept documents.*
+
+## Writing for varied audiences
+
+Before delving into the content creation process, it's important to organize your concept document in a way that caters to diverse audiences. Employ the following strategies to enhance the document's accessibility:
+
+* **Identify audience categories**: Categorize your potential audiences, including developers, managers, end users, and support engineers. Clearly define a few personas with varying levels of expertise and interests. A good example of defining personas can be found from the [The Good Docs Project](../user-personas/process_user-personas.md).
+* **Assess specific needs and goals**: For each audience category, evaluate their unique needs, goals, and expectations from the concept document. Understand how the document can address their specific concerns or challenges.
+* **Determine industry relevance**: Recognize the industry to which each audience belongs. Tailor your document to different industry contexts, considering that each sector may require distinct perspectives or applications of the concept.
+* **Audience's role and relationship**: Understand the role and responsibility of each audience in relation to the concept. Whether they are decision-makers, implementers, presenters, or evaluators, recognizing their roles will help you effectively address their needs.
+* **Contextual understanding**: Dive into the work situations and problems faced by your audience. Consider whether they are evaluating the concept, looking to understand its practical applications, or preparing presentations. This deeper contextual understanding allows you to frame the concept in a way that resonates with real-world concerns.
+
+When you are tasked with writing for multiple audiences, consider the
+following strategies:
+
+* **Chunking**: Divide your concept document into clearly defined sections or chunks. Each section can cater to a specific audience or address a particular aspect of the concept. This structure enables readers to easily skim and locate the information most relevant to them.
+
+* **Layering different depths of explanation**: This involves weaving two narratives into one: a high-level conceptual story for non-technical readers and the details craved by your tech-savvy audience. Start a section with a high-level, simple explanation geared towards non-technical readers, providing an overview of the concept, its relevance, and the benefits it offers. Use relatable examples, analogies, and visual aids to enhance understanding. Then progressively expand into detailed technical explanations for the benefit of your tech-savvy audience. Dive into the intricacies, technicalities, and specifics of the concept. Include code samples, in-depth analyses, and comprehensive details that cater to readers seeking a deeper understanding.
+
+* **Splitting into multiple documents**: If the concept is complex and the information for each audience significantly diverges, consider creating separate documents for each audience. This approach ensures that each group receives tailored, focused content that directly addresses their needs.
+
+## Write a concept document
+
+The process is described in the [template guide](guide_concept.md).
+
+## Create visual aids for a concept document
+
+Visual aids play a crucial role in concept documents by making complex
+information more accessible and engaging for the reader.
+
+Visual aids encompass various elements, including diagrams (such as
+decision trees, context diagrams, and flowcharts), small videos,
+comparison tables, and images. These elements are strategically chosen
+to complement the narrative and help the reader grasp the concept more
+effectively.
+
+If you go with a diagram option, regardless of the type it should
+represent relationships between key components, providing a
+comprehensive overview of the concept's structure and connections.
+
+| Diagram Type    | Value                                                                                                                                              | When to Use                                                                                                                              |
+|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------|
+| Context Diagram | Provides an overview of system components and their interactions.                                                                                 | Use when illustrating how the concept fits into a broader framework or ecosystem.                                                       |
+| Flowchart       | Represents step-by-step processes and decision points. For example, how the concept evolved or which decisions were made throughout the evolution. | Ideal for explaining sequential procedures or illustrating decision-making within the concept.                                          |
+| Decision Tree   | Depicts decision scenarios and outcomes.                                                                                                          | Effective when presenting choices and consequences related to the concept.                                                              |
+| Infographic     | Utilizes visuals and icons to convey complex information.                                                                                         | Suitable for providing a high-level overview of the concept, especially when visual appeal is crucial. Can be used to visualize numbers. |
+
+Incorporating visual aids follows principles of multimedia learning,
+notably [Mayer's spatial contiguity
+principle](resources_concept.md). This principle emphasizes
+the importance of keeping text and related visuals close together and
+aligned. By doing so, concept documents prevent overwhelming the reader
+with disjointed information and promote a seamless understanding of the
+material.
+
+Videos can be useful when demonstrating dynamic processes, showcasing
+real-world examples, or providing an illustration of the process (for
+instance, if some concept developed over time).
+
+However, it might be useful to use videos sparingly and ensure they add
+value to the document without overwhelming the reader, because watching
+the video takes time and your reader may lose context of an article.
+Also, videos are expensive to produce and maintain. But the good news is
+that conceptual documentation is slower to become obsolete than
+instructional documentation, because processes and interfaces change
+more often than fundamental concepts and approaches.
+
+Videos for concept docs should be concise and short. Consider including
+a white-board styled drawing to enhance information presented. Also,
+videos are hard to skim through which is a frequent scenario for the
+concept document.
+
+By incorporating these visual aids strategically, concept documents not
+only convey information more effectively but also enhance the reader\'s
+overall comprehension of the concept at hand.
+
+## Maintain a concept document
+
+To ensure that your concept document remains a valuable and reliable
+resource, it's essential to establish a maintenance plan. Consider the
+following best practices for keeping your concept document up-to-date
+and accurate:
+
+* **Version control**: Implement a version control system for your concept
+document. Use tools like Git or similar version control systems to track
+changes and reference previous versions.
+
+* **Regular review**: Set a schedule for periodically reviewing the
+concept document, especially when there are updates to the underlying
+concept or when new linked concepts become available. Regular reviews
+help ensure the document\'s continued relevance.
+
+* **Communication with stakeholders**: Maintain open lines of
+communication with relevant teams, such as developers, project managers,
+and subject matter experts, to ensure that the document reflects the
+most accurate and up-to-date information about the concept.
+
+* **User feedback**: Consider adopting user feedback as a valuable source
+of improvement. Solicit input from readers, stakeholders, and users to
+identify areas where the document can be enhanced or clarified. Things
+to test and gather feedback carefully are definitions, analogies and
+metaphors, and examples.
+
+* **Testing updates**: Whenever significant modifications are made to the concept,
+it's imperative to validate their effectiveness within the document.
+Ensure that any alterations in the context and components of the concept are accurately portrayed.
+Several techniques can be employed to gauge user comprehension:
+
+  * **Explaining in simple terms**: Request a reader to articulate the concept in their own words, leveraging techniques like "Explain Like I'm 5." This method often simplifies complex ideas for better understanding.
+  * **Real-world scenarios**: Present readers with practical situations associated with the concept and inquire about how they would apply their knowledge in those scenarios.
+  * **Feedback channels**: Offer readers the chance to provide feedback through surveys or dedicated forms. This feedback can uncover areas of confusion or misunderstanding, facilitating improvements.
+
+* **Visual components**: Ensure that visual aids, if used in the document,
+are also updated when necessary. Diagrams, charts, and other visuals
+should remain consistent with any changes to the concept they represent.
+To make it easier to keep them up to date, use the diagrams-as-code
+approach. It means you describe the diagram with a markup and the
+tooling takes care of the visual rendering, so that you don't need to
+store them as pictures and update each time. Read more in a Quick
+introduction to Diagram as Code referred in the [Resources document](resources_concept.md). Write diagrams using any notation
+of your choice or a notation that is understandable by your audience.
+
+* **Documenting changes**: Display document version. This
+documentation serves as a reference to understanding the document's
+evolution and the reasoning behind specific updates. Update the document
+to reflect any new insights or changes in the concept's context.
+
+Typically, it is sufficient to include a "Last Updated: {Date}" on a
+page, which may be provided by your Content Management System.
+
+Versioning documents can help a returning reader expect change. If
+versioning, consider using a MAJOR.MINOR.PATCH semantic versioning
+pattern.
+
+It may look somewhat like this:
+
+| Version | Date       | Description                          |
+|---------|------------|--------------------------------------|
+| 2.0     | 2023-06-01 | Added a new limitation               |
+| 1.1     | 2023-02-01 | Enhanced explanation of key concepts |
+| 1.0     | 2023-01-01 | Initial Concept Document             |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Concept%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/concept/resources_concept.md b/meta/reference/good-docs-project-template-1.5.0/concept/resources_concept.md
new file mode 100644
index 00000000..45c9a46a
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/concept/resources_concept.md
@@ -0,0 +1,56 @@
+# Concept document template 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+## Examples of concept documents
+
+The following examples have been selected as they are widely referenced and considered by us or others to include high-quality material we should look at.
+
+* [Google Document AI overview](https://cloud.google.com/document-ai/docs/overview)
+(Accessed 2023-09-10):
+This overview serves as a guide to the fundamental concepts of using Document AI.
+It also contains a short explanatory video on the subject.
+
+* [Introduction to the DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction) (Accessed 2023-09-10):
+This overview of the Document Object Model by Mozilla gives the definition of the DOM and all the linked concepts (like fundamental data types, interfaces), describes how it is
+built, and gives a few examples of how it can be used.
+It stands out for its comprehensive coverage and user-friendly approach.
+The inclusion of practical examples makes it an effective resource for grasping the fundamentals of the DOM.
+
+* [Introduction to infrastructure monitoring](https://docs.splunk.com/Observability/infrastructure/intro-to-infrastructure.html#nav-Introduction) (Accessed 2023-09-10):
+This concept document effectively introduces Splunk Infrastructure Monitoring by providing a clear overview of its purpose and capabilities.
+It also presents a well-structured hierarchy of its components and offers concise, actionable information on how users can get started and leverage its features, making it a comprehensive and informative reference for users seeking to understand and utilize Splunk Infrastructure Monitoring.
+
+* [Inside Ubuntu Core](https://ubuntu.com/core/docs/uc20/inside) (Accessed 2023-09-10):
+This concept document provides a detailed explanation of the architecture and components of Ubuntu Core, including Ubuntu Core 22 (UC22) and Ubuntu Core 20 (UC20), highlighting how they are built upon Ubuntu LTS releases and the role of snaps in managing system elements.
+It effectively uses a component scheme to visually represent the relationships between various components, making it an excellent resource for understanding the inner workings of Ubuntu Core for embedded devices and its use of snap packages for system management.
+In Ubuntu documentation it is specifically included into the Explanations section.
+
+* [About Autonomous Database Workload Types](https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/about-autonomous-database-workloads.html#GUID-E1C8C5F2-22FB-4225-A3B9-9E78277A5834) (Accessed 2023-09-10):
+This concept document provides a clear and concise overview of different workload types supported by Oracle Autonomous Database, including Data Warehouse, Transaction Processing, JSON Database, and APEX Service.
+It effectively explains the purpose and features of each workload type and provides architectural illustrations to enhance understanding, making it a valuable resource for users seeking insights into Oracle Autonomous Database offerings.
+Architectural illustrations enhance user comprehension, making it a valuable resource for users seeking insights into Oracle Autonomous Database offerings.
+
+## Articles and books
+
+| Source material | Best practice or section we've used |
+| --------------- | ----------------------------------- |
+| [DITA Concept type topics](https://docs.oasis-open.org/dita/dita/v1.3/os/part2-tech-content/archSpec/technicalContent/dita-concept-topic.html) (Accessed 2023-09-10) | This description of the concept type of DITA topic helped us to elaborate on this information type structure, because DITA is known for its structured authoring basements. |
+| Jared Bhatti, Sarah Corleissen, Jen Lambourne, David Nunez, Heidi Waterhouse Docs for Developers: An Engineer's Field Guide to Technical Writing Paperback -  Apressm First edition (October 2021) | Chapter 2. Conceptual documentation section helped us to understand how the Conceptual document should be structured and what are required and optional information. |
+| [GitLab topic types](https://docs.gitlab.com/ee/development/documentation/topic_types/concept.html) (Accessed 2023-09-10) | From GitLab's content type framework we have taken the idea that a content document should answer the question What is it, and also what is a good and bad practice for a concept document title. |
+| [Grafana Writer's Toolkit](https://grafana.com/docs/writers-toolkit/structure/topic-types/concept/) (Accessed 2023-09-10) | Grafana Writer's Toolkit helped us to understand which types of content can be included in concepts. |
+| [Diataxis Explanation type](https://diataxis.fr/explanation/) (Accessed 2023-09-10) | Despite that in Diataxis this type of content is called explanation, this framework's website helped us to understand the value and place of the conceptual information in the documentation and in which situation users need this type of documents. |
+| [A List Apart Style Guide](https://alistapart.com/about/style-guide/#metaphor)  (Accessed 2023-10-23) | From this style guide, we've taken recommendations regarding the use of metaphors and analogies. They emphasize the importance of selecting metaphors and analogies that are clear, culturally sensitive, and relevant to the audience. |
+| [Mayer's principles of multimedia learning](https://waterbearlearning.com/mayers-principles-multimedia-learning/)  (Accessed 2023-10-23) | From this article, we've derived the Spatial Contiguity Principle which emphasizes that effective learning occurs when text and visuals are positioned in close proximity on the screen. |
+| [Inverted Pyramid: Writing for Comprehension](https://www.nngroup.com/articles/inverted-pyramid/) (Accessed 2023-11-06) | From this article, we've taken a description of an inverted pyramid principle used to structure articles. |
+| [The StoryBrand 7-Part Framework: Your Complete Guide to a Clearer Message](https://www.mojomedialabs.com/blog/complete-guide_storybrand-framework) (Accessed 2023-11-06) | From this article, we've taken a brief overview of a StoryBrand framework used for storytelling. |
+| [Quick introduction to Diagram as Code](https://www.devonblog.com/none/quick-introduction-to-diagram-as-code/) (Accessed 2023-11-06) | Refer to this article to know more on diagrams-as-code approach. |
+| [Your Brains on Fiction](https://www.nytimes.com/2012/03/18/opinion/sunday/the-neuroscience-of-your-brain-on-fiction.html?pagewanted=all) (Accessed 2023-11-06) | From this article, we've taken neuroscientific research about the impact of stories on the brain, revealing that reading narratives triggers not only classical language regions but also various sensory and motor areas. |
+| [Ryan Young - Is it (layer) cake: Thinking in content levels](https://youtu.be/0OKRNQvZbL4) (Accessed 2023-11-06) | From this talk, we've taken a framework called a layered cake of content. It describes a tiered structure designed to cater to diverse user needs and navigational preferences. At the pinnacle are the high-level content pages, strategically crafted for orientation, guiding users through the landscape of possibilities with overview pages. Delving into the intricacies, the low-level content pages take center stage, focusing on implementation and offering step-by-step instructions. Bridging the realms of high and low, the mid-level content pages facilitate decision-making, providing a deeper understanding than high-level content without the exhaustive detail of low-level, incorporating integration guides and concept documents. |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Concept%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/concept/template_concept.md b/meta/reference/good-docs-project-template-1.5.0/concept/template_concept.md
new file mode 100644
index 00000000..8b48a7e1
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/concept/template_concept.md
@@ -0,0 +1,109 @@
+# Concept template
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_concept.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.
+
+A summary paragraph introducing a concept, explaining its importance or
+relevance, and providing an overview of the content that will be covered
+in the document (scope).
+
+Typical wording to use is:
+
+* This article explains the basics of {concept} and how it works in {the tool or context}.
+
+{Then include a paragraph with a definition of the concept you are explaining.
+If more definitions are needed, include those definitions here as a bulleted list.}
+
+{This section usually doesn't have a separate heading that explicitly says
+Definition; it can precede all the rest.}
+
+Typical wordings to use are:
+
+* {X} is;
+
+* {X} represents
+
+* {X} is connected to
+
+* {X} are organized {describe the way how}
+
+* {X} is similar to
+
+* {X} addresses the common pain points of ...
+
+* {X} solves the challenge of ...
+
+* By implementing {X}, users can ...
+
+* By using {X}, {specify users/target audience} gain ...
+
+* To use {X}, you create {Y}
+
+{Add visual aid to complement your explanations visually.}
+
+{Image goes here.}
+
+(Optional) Image/Figure: {Image title, which concisely explains the image or
+figure. It can be represented by annotations on the image.}
+
+## (Optional) Background
+
+{Use this section to provide a reader with a context, prehistory, or background information.}
+
+Typical wordings to use are:
+
+* The reason {X} is designed that way is because historically, ...
+
+* The idea of {X} originated from the growing demand for ...
+
+* Recent advancements in {X} and {Y} have opened up new possibilities
+    for ...
+
+* With the rise of {X}, the need for things such as {Y} has become
+    paramount.
+
+* Over the past decade, {advancements in technology} have transformed
+    the way ...
+
+## Use cases
+
+{Use this section to provide use cases and explain how a reader can
+benefit from a concept.}
+
+## (Optional) Comparison of {thing being compared}
+
+{Use this section to compare options or alternatives.}
+
+Table: {Table title which concisely explains the comparison.}
+
+## (Optional) Related resources
+
+{Use this section to provide links to documentation related to the concept that the user can read for more information.
+If you can name this section manually (it is not generated automatically or has a heading pre-agreed within a team),
+we recommend to use "Related concepts" or "Additional information" as more descriptive ones.}
+
+If you would like to dive deeper or start implementing {concept},
+check out the following resources:
+
+How-to guides
+
+1. Item 1
+
+2. Item 2
+
+Linked concepts
+
+1. Concept 1
+
+2. Concept 2
+
+External resources
+
+1. Resource 1
+
+2. Resource 2
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Concept%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/contact-support/guide_contact-support.md b/meta/reference/good-docs-project-template-1.5.0/contact-support/guide_contact-support.md
new file mode 100644
index 00000000..f098ea6b
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contact-support/guide_contact-support.md
@@ -0,0 +1,173 @@
+# Contact support user guide
+
+Thank you for downloading this template from The Good Docs Project! Before using the [contact support template](/contact-support/template_contact-support.md), 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.
+
+## About the contact support page
+
+A contact support page typically consists of communication channels, discussion forums, and links to other resources to assist users with issues that they are having with your product. Contact support pages are sometimes confused with Contact us pages or support portals. Though these documents help the users contact the organization and provide support, they differ in purpose and audience. The following table describes the differences:
+
+
+  
+    
+      
+      
+      
+      
+    
+  
+  
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+    
+      
+      
+      
+      
+    
+  
+
Contact supportContact usSupport portal
What kind of organization should use this content type?
+        
    
+          
  • Best for organizations with simpler support systems with only a few options or methods for contacting support
    • 
+          
  • Better for startups or smaller companies
    • 
+        

+      		
+        
    
+          
  • Best when you need multiples ways to contact your organization for a variety of purposes or needs, including sales or press contacts
    • 
+          
  • Valuable to all organizations, regardless of size
    • 
+        

+      		
+        
    
+          
  • Best for organizations with a mature support system with multiple options or methods for contacting customer support based on the customer's needs
    • 
+          
  • Better for larger or well-established companies
    • 
+        

+      
Who is their audience?
+        
    
+          
  • Current users of the product
    • 
+        

+      		
+        
    
+          
  • Potential users of the product
    • 
+          
  • Can also be targeted at new or first-time users who have recently purchased the product and need to get started
    • 
+          
  • Can also include people who want to contact the business for other related possibilities, including potential business partnerships or media inquiries
    • 
+          
  • Can also include existing customers who need support
    • 
+        

+      		
+        
    
+          
  • Current users of the product
    • 
+          
  • Can also be targeted at new or first-time users who have recently purchased the product and need to get started
    • 
+        

+      
What is their purpose?
+        
    
+          
  • Helps users connect with a support agent for more help
    • 
+          
  • Could possibly link to other resources for additional support, such as product documentation and community forums
    • 
+        

+      		
+        
    
+          
  • To help potentials users who want to try the product to get started, either by talking to someone in sales or downloading a free or trial version of the product
    • 
+        

+      		
+        
    
+          
  • To provide users with the tools to find the best solutions to the problems on their own
    • 
+          
  • If they can't solve their problem, the contact support page helps them reach either other users or a support agent for more help
    • 
+        

+      
What is the end goal?
+        
    
+          
  • Customer retention and success
    • 
+          
  • Help the customer solve their problem without feeling frustrated with the product
    • 
+          
  • Positive product reviews on review sites (such as Google Search Reviews or Yelp)
    • 
+        

+      		
+        
    
+          
  • Bring in new users and get them to try or buy the product
    • 
+          
  • Turn prospective users into customers
    • 
+        

+      		
+        
    
+          
  • Customer retention and success
    • 
+          
  • Help the customer solve their problem without feeling frustrated with the product
    • 
+          
  • Positive product reviews on review sites (such as Google Search Reviews or Yelp)
    • 
+        

+      

+
+## Why do I need a contact support page?
+
+Companies tend to have different approaches to solving technical issues with their product. So, providing a central location that contains links to different resources can be invaluable. For example:
+
+* It helps empower users to solve the issues that they are experiencing with the product.
+* It helps users know which communication channels they should use to request technical support and the amount of time it takes to receive a response.
+* A contact support page is an important component of a larger business strategy to improve customer experience and success. The contact methods used by a business can provide insights into the user experience, which can be helpful in improving the product. For more information about customer support strategies, see [the Contact support process document](/contact-support/process_contact-support.md).
+* It's efficient and cost-effective for the business because it empowers users to solve the issues they are experiencing with the product. If users are still struggling, then they can receive guided assistance from the support agent.
+* You can guide the user to contact the support team using the organization's preferred communication methods, especially those methods which have enabled customer issue tracking data. As a result, the company can possibly track trends in customer issues and use this information for quarterly reviews about the customer support strategy or to reveal recurring issues in the product that are impacting several users at once.
+
+## Best practices for contact support pages
+
+* Research your company's support strategy: When deciding the communication channels for your company/organization's contact support page, consider picking ones that best align with the customer support strategy. Consider presenting the most important or preferred contact support methods first. For more information about customer support strategies, see [the Contact support process document](/contact-support/process_contact-support.md).
+* Set standards for response times: Help users know when they can reasonably expect to hear back from a support agent.
+* Indicate support agent availability: When adding chat and phone numbers as a communication option, add contact hours to help users gain a better understanding of when support agents are available.
+* Offer self-serve options: Users tend to prefer solving the issue on their own before going to a support agent, so consider adding links to the company's knowledge base or product community forums.
+* Use plain language: Balancing technical jargon with everyday terms helps users understand what they are reading.
+
+## About the "Contact support" section
+
+The following information explains how to fill in the different sections of the contact support template.
+
+### About the "Contact support" section
+
+This section greets users with a statement or question to capture their attention and create a welcoming environment. For example, you could say:
+
+* Hi! How can we help you?
+* Welcome to our support center!
+* We're here to help!
+* Need help? Find the answers you need from our excellent support team.
+
+### About the "Our products" section
+
+This section presents the icons or names of your organization's products. The images are typically hyperlinked to other resources and presented in a row for easy navigation. For organizations that have only one product, it is usually at the center of the page and has other sources like its navigation next to it.
+
+### About the "Support plans" section
+
+This optional section presents the different levels of support that users receive. It is recommended for organizations that offer different tiers of support for their product, such as a free and paid subscription. This information is best presented in a table. For an example, check out the [Plans and Pricing table on Zoom](https://zoom.us/pricing).
+
+### About the "Contact details" section
+
+This section of the contact support page is the most important because it is where you list the different methods for contacting a support agent. This template lists the following contact methods:
+
+* Phone number
+* Text message
+* Email address
+* Live chat
+* Social media
+
+Delete any contact methods that do not apply to your company. It's best to pick the communication channels that suit your company's support strategies. When deciding the order in which you present the contact details, it should align with the customer support strategy. For more information about customer support strategies, see [the Contact support process document](/contact-support/process_contact-support.md).
+
+Additionally, always include a statement that indicates when the customer can expect a response for each contact method. If certain communication channels are only available at specific times, indicate those times for each one.
+
+### About the "More support" section
+
+This section is where users go if they need more self-help with their issues. Possible options include:
+
+* Slack or Discord channels
+* Knowledge base
+* Community forums
+
+Some companies might want users to choose self-help options before they contact a support agent. For example, they may encourage users to browse a knowledge base or community forum. If your company prefers this strategy, consider placing this section before the contact details section when using the template.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our[feedback form](https://thegooddocsproject.dev/feedback/?template=Contact%20support%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/contact-support/process_contact-support.md b/meta/reference/good-docs-project-template-1.5.0/contact-support/process_contact-support.md
new file mode 100644
index 00000000..220b93f5
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contact-support/process_contact-support.md
@@ -0,0 +1,55 @@
+# Contact support page process
+
+Thank you for downloading this template from The Good Docs Project! Before using the [contact support template](template_contact-support.md), 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 do research for your company's contact support page
+
+Before you start creating a contact support page, you need to know what your company's overall customer support strategy is and how this page aligns with that plan. To elaborate, a customer support strategy is a plan formulated by a company with the goal of making and keeping their customers happy.
+
+This strategy is often created by the customer success team, which begins by developing their goals and business objectives. Possible objectives or goals can include:
+
+* Resolving issues with the product quickly.
+* Improving the customer onboarding process.
+* Increasing customer product engagement and adoption.
+
+Developing an effective customer support strategy can sometimes be difficult. On the one hand, businesses want to provide customers with excellent customer support that helps them troubleshoot and resolve the issues they have with the product. But on the other hand, they also need to keep their operating margins for customer support as low as possible by reducing labor costs to prevent cutting into profits.
+
+Various factors might influence a company's customer support strategy, such as the company's size and overall business strategy. For example, Apple provides its customers with services like 24/7 customer support and many possible support communication channels, such as the support chat app. This company can afford to provide this high level of customer support because it is large and has a wide user base. Apple's customer support strategy is built around [their belief in establishing a strong bond with customers](https://cxjournal.medium.com/customer-experience-strategy-of-apple-revealing-the-secret-e33007e51c9b).
+
+By contrast, the startup tech company, Pieces By Developers provides support through Discord and a [GitHub repository](https://github.com/pieces-app/support) where people can post questions on the Discussions tab, open bug reports, engage with other users, and find self-help options. Unlike Apple, this company is a startup that needs to keep their support costs low. For that reason, Pieces by Developer has aligned their support strategy and customer experience around [building a strong community](https://code.pieces.app/blog/community-driven-support-with-pieces-for-developers).
+
+To gain knowledge about your company's customer support strategy, find the team at your  company who is responsible for developing the customer support strategy. Typically, this team is called the Customer Support team, but it could also be called the Customer Success team. Try to arrange a meeting with the lead or a representative from this team. During this meeting, use the following questions to learn more about the strategy:
+
+* Who does the company provide support to?
+* What are the company's guiding principles or goals for their customer support strategy and why?
+* In what order should customers use the methods when seeking support?
+* If you could change a customer behavior with a support method, what would you want it to be?
+* Which self-help options should customers be encouraged to use?
+* What kind of information do we need to get from customers in order to give the appropriate level of support they need?
+* Based on the Customer Satisfaction Rates (CSAT), how can we help our customers quickly get the help they need?
+
+## How to write the content for your contact support page
+
+Now that you better understand your company's customer support strategy, start thinking of ways to design a contact support page that aligns with it.
+
+Here are some other things to consider when writing the content for your contact support page:
+
+* Ensure that the contact methods align with the strategy that you learned about during the research phase. It's best to pick the communication channels that suit your company's support strategies. When deciding the order in which you present the contact details, it should align with the overall strategy.
+* Identify whether you need additional front-end support for this section of your website, such as design or development support to create an intake form for customer support requests. You might also need front-end support to add interactive elements to the page, such as a thought-bubble icon or pop-up chat windows.
+* Write your company's team time availability and phone number based on their location and timezone.
+* Consider dividing the support page into adaptive contact pages, with each page providing support for a specific product or a category of issues the customer might be experiencing.
+* If your product has an SLA (Service Level Agreement), make sure your company's contact support page matches this document.
+
+## How to maintain a contact support page
+
+As your company grows, its customer support strategy will change. To ensure this content remains fresh and up-to-date, stay connected with the person who aided you in the research phase by having regular or quarterly meetings.
+
+Consider using the following methods to evaluate whether your contact support page is still effective:
+
+* **Check out the feedback from users:** Consider reviewing the product reviews on social media, blog posts, the company's website,community forums. It would help you see current issues that the customer has with the product, making it easier to determine the company's CSAT (Customer Satisfaction Rate).
+* **Check the hyperlinks:** Test the hyperlinks and contact methods to ensure they work correctly and that they send users to the right communication channel or information. Remember, incorrect or broken links create a frustrating and difficult user experience.
+* **Develop strategies to work with limited resources:** If your organization or company decides to remove information such as the company's email address from the contact support page, find alternative solutions that can support and empower customers in troubleshooting issues. This could be done by providing a link to the community forums.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Contact%20support%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/contact-support/resources_contact-support.md b/meta/reference/good-docs-project-template-1.5.0/contact-support/resources_contact-support.md
new file mode 100644
index 00000000..acf04548
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contact-support/resources_contact-support.md
@@ -0,0 +1,84 @@
+# Contact support page resource guide
+
+Thank you for downloading this template from The Good Docs Project! Before using [the contact support page template](template_contact-support.md), read this document to see high-quality examples of contact support pages and review the resources below. Want to explore more templates? Check them out in our [templates](https://gitlab.com/tgdp/templates) GitLab repository.
+
+## Examples of contact support pages
+
+* **[Constant Contact](https://community.constantcontact.com/t5/Contact-Support/bd-p/contact-support)** - Constant Contact's support page provides different ways users can find assistance and solutions for their marketing issues, such as live chat, email, and community forums.
+* **[Hubspot](https://help.hubspot.com/?_ga=2.32288827.42970265.1714521684-601084526.1709179413&_gl=1*mpto06*_ga*NjAxMDg0NTI2LjE3MDkxNzk0MTM.*_ga_LXTM6CQ0XK*MTcxNDUyMTY4My42LjAuMTcxNDUyMTY4My42MC4wLjA.)** - Hubspot has a link to a knowledge base center at the top of its contact support site. It includes links to other communication channels like chat and social media at the bottom of their support site.
+* **[Apple Contact Support Center](https://support.apple.com/contact)** - Apple's contact support center is a centralized hub for customers to find information about their products. Like the HubSpot Help Center, it provides a variety of articles for customers to refer to and different ways to contact the company.
+* **[Balena](https://www.balena.io/support)** -Balena's support page provides links to the product's community forum, documentation, and open source code for developers who want to improve their features.
+* **[Zappo's](https://www.zappos.com/c/contact-us)** - Zappo's has a list of links that provide different forms of support.
+* **[Nintendo](https://en-americas-support.nintendo.com/app/contact/session/L3RpbWUvMTcxNDUxNjU2NS9nZW4vMTcxNDUxNjU2NS9zaWQvZlVYX2VnNWVVUFJTcWx3Z1lJREZxbHpVcER0dnVQRktPald5MnJhZlNLcVFrdFlSZDNNanJ4YzgzamNlWUo2Z29MaVpqT0NlX0VqWDBuODBObldNNCU3RXlMMGlIa21tQU9MMEcwRF9ZOWlrNTdwUUJickh5RVFKWnclMjElMjE%3D)** - Nintendo's contact support page contains a dropdown menu where users can pick a topic that contains content to help them solve their product's issue. In addition to having links to different communication channels, there is a section called "Contact Corporate" where businesses can contact Nintendo for potential partnerships and other queries.
+* **[Shopify](https://www.shopify.com/contact)** - Their support page provides two links for support, empowering users to choose the option that best suits their needs.
+* **[Mailchimp](https://mailchimp.com/help/mailchimp-support-options/)** - This support page provides users directions on how to gain assistance based on the type of plan they have.
+* **[Zoom Plans and Pricing](https://zoom.us/pricing)** - This company's support page provides a table of different services based on the type of plan users have.
+
+## References
+
+The authors want to acknowledge the resources that have been inspired or informed this template:
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+   
+   
+  
+
Source materialBest practice or section
Understanding customer support and customer serviceHiver 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 baseZapier 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 2024This 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 PageThis 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 RateThis 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 | FullviewThis 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 rateThis 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 - WhatfixThis 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 businessThis 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 practicesThis 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 SecretThis 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 DevelopersThis 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.

+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Contact%20support%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/contact-support/template_contact-support.md b/meta/reference/good-docs-project-template-1.5.0/contact-support/template_contact-support.md
new file mode 100644
index 00000000..b417dd73
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contact-support/template_contact-support.md
@@ -0,0 +1,110 @@
+{If you need more information about how to fill in this template, read the accompanying [Contact Support guide](../contact-support/guide_contact-support.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.}
+
+# Contact {company name or product name} support
+
+{Write a hook to capture the attention of users and set a welcoming, friendly tone. For example, "Hi! How can we help you?".}
+
+## Our products
+
+{Product icon}
+
+[{Name and link to product page}]({Hyperlink to product's documentation or landing page here})
+
+{Tip: If your company/organization has more than one product, consider placing the products and their hyperlinked information in a row.}
+
+## Support plans
+
+{This section is optional. If support is only provided based on certain subscription levels or there are different tiers of support, indicate which subscription levels or plans come with support, possibly in table form.}
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
Free plan or basic license levelPro plan or next license level
Free{Cost per month/annually}

+      
    
+        
  • {First feature}
    • 
+        
  • {Second feature}
    • 
+        
  • {Third feature}
    • 
+      

+    		
+      
    
+        
  • {First feature}
    • 
+        
  • {Second feature}
    • 
+        
  • {Third feature}
    • 
+      

+    

+
+## Contact details
+
+{Delete any of the following sections that do not apply to your organization.}
+
+### Phone number
+
+Our agents are available by phone at:
+
++x-xxx-xxx-xxxx
+
+{Replace placeholder text with your phone support phone number}
+
+Agents are available at {list available times and days that agents are available. For example: Mon-Fri x am-x pm time zone}
+
+{Tip: Hyperlink the support phone number for mobile users.}
+
+### Text message
+
+Text the {company name} support team at:
+
++x-xxx-xxx-xxxx
+
+{Replace placeholder text with your text support phone number}
+
+{Tip: Hyperlink the support phone number for mobile users.}
+
+### Email
+
+Email us at:
+
+{[your-support-email@your-company-name.com](mailto:your-support-email@your-company-name.com)}
+
+{Tip: Hyperlink the email.}
+
+You can expect a response by {list maximum response times here. For example, within 24 hours}.
+
+### Live chat
+
+Need a quick response? Chat with a support agent:
+
+[{Live chat}]({link to chat url})
+
+### Social media
+
+Connect with us on:
+
+{X (Twitter)} at [{@companysocialprofilename}]({link to social media url})
+
+{LinkedIn} at {https://www.linkedin.com/in/your-company-name/}
+
+{Add additional social media accounts as needed.}
+
+### More support
+
+Need more support? Check out these links below:
+
+* {hyperlink to self-help options, such as community forums, Slack or Discord, or a knowledge base}
+
+{Note that some companies might choose to put this section at the top of their contact support page in order to encourage users to solve problems on their own before contacting an agent.}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Contact%20support%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/contributing-guide/example_contributing-guide.md b/meta/reference/good-docs-project-template-1.5.0/contributing-guide/example_contributing-guide.md
new file mode 100644
index 00000000..290f8d5d
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contributing-guide/example_contributing-guide.md
@@ -0,0 +1,4 @@
+# Contributing guide example
+
+The Good Docs Project has an official example of this template in action.
+You can view this example at the Chronologue repository: [Chronologue contributing guide](https://gitlab.com/tgdp/chronologue/docs/-/blob/main/CONTRIBUTING.md)
diff --git a/meta/reference/good-docs-project-template-1.5.0/contributing-guide/guide_contributing-guide.md b/meta/reference/good-docs-project-template-1.5.0/contributing-guide/guide_contributing-guide.md
new file mode 100644
index 00000000..3b87d1f0
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contributing-guide/guide_contributing-guide.md
@@ -0,0 +1,198 @@
+# About the Contributing Guide Template
+
+> 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
+
+The contributing guide template provides a baseline for building your project's contributing guidelines and contribution workflow. This document will help you learn about contributing guides and how to use the template.
+
+## Why do you need a contributing guide?
+
+Contributing guides are important because they communicate your process for contributing, which can help you with the following:
+
+* Attract additional help with your project.
+* Ensure the quality of work that your contributors submit.
+* Make your project more inclusive because the contributing guide allows people to onboard themselves without assistance.
+
+You can tailor your contributing guide to focus on one or a variety of contribution types, such as the following:
+
+* Source code
+* Documentation
+* Outreach initiatives
+* Translation efforts
+* Issue management
+* Content strategy
+* IT support
+* Social media
+
+What you include in your contributing guide depends on your project's needs.
+
+## When do you need a contributing guide?
+
+Regardless of how big, small, new, or old your project is, you will need a contributing guide for the following reasons:
+
+* Your project is open source and relies on outside collaboration.
+* To attract more contributors to your project.
+* To enhance the quality of the contributions.
+* To establish processes, expectations, and guidelines for contributing.
+* To ensure that contributors have all the information and resources available to contribute; this gives your contributors a way to self-serve and help themselves, which reduces some of the maintenance burdens on the project maintainers.
+
+## Voice and tone
+
+Before you build your contributing guide, consider what kind of tone and voice you want to communicate to contributors. The "voice" communicates your personality, while the "tone" communicates your attitude. Ask yourself if you want your contributing guide to sound formal, humorous, or conversational.
+
+The following are some examples:
+
+* Conversational tone and voice: We're excited to have you join the project! Now that you've joined, check out the following ways you can contribute.
+* Formal tone and voice: Thank you for your interest in joining the project. The following are ways you can contribute.
+
+## Best practices
+
+Open source projects name this file in all caps to make it easier to discover: CONTRIBUTING.md.
+
+## Template overview
+
+Throughout the contributing guide template, you will see the following:
+
+* A variety of sections and subsections to help you provide granularity.
+* Boilerplate text that you can change. \
+**Note:** Boilerplate is the standardized text you can use and reuse within the template.
+* Placeholder text indicated in {curly brackets}.
+
+The contributing guide template is customizable; you can **reorder, rename, and remove sections** that do not apply to your project.
+
+The following sections provide guidance and context on how to fill out the contributing guide template.
+
+### About the "Welcome" section
+
+Introduce your project to your contributors with a welcome message. In your welcome message, list and explain how people can contribute and refer them to those sections within your contributing guide. Also, list contributions your project **does not accept** to clarify the scope.
+
+**Example:** Welcome to the Open Source Project's contributing guide, and thank you for your interest.
+
+If you would like to contribute to a specific part of the project, check out the following list of contributions that we accept and their corresponding sections that are within this guide:
+
+* To contribute to our templates, see the following:
+
+  * Templates Contributing Process
+  * Our Content Style Guide
+  * Criteria for the Templates Submissions and Reviews
+
+* To contribute to our content strategy, see the following:
+
+  * Content Strategy Contributing Process
+  * Share Your Content Strategy Ideas
+  * Content Strategy Workshops
+
+* To contribute to our style guide, see the following:
+
+  * Style Guide Contributing Process
+  * Our Content Style Guide
+  * Share Your Content Style Ideas
+
+However, at this time, we do not accept the following contributions:
+
+* Source code
+* Project maintenance
+* Translation
+* Issue triaging
+
+### About the "Overview" section
+
+Provide a brief description of your project's purpose and objectives that you want to highlight to contributors.
+
+**Example:** The purpose of The Open Source Project is to unify software developers who can collaborate to produce a high-quality analytics application for data scientists.
+
+### About the "Ground rules" section
+
+Inform your contributors about your project's behavior policies. Behavior policies are rules and expectations on how to behave and not behave when contributing.
+
+Provide a list of general behavior policies or share a link to your Code of Conduct if you have one established.
+
+**Example:** Before contributing, read our **Code of Conduct** to learn more about our collection of rules, standards, values, and behavior expectations that you must adhere to.
+
+**Example:** To be an active contributor, you must adhere to the following behavior policies:
+
+* Be respectful of differing viewpoints.
+* Kindly accept constructive criticism.
+* Do not use derogatory language.
+* Be empathetic towards fellow contributors.
+
+### About the "Community engagement" section
+
+Provide information on how contributors can engage with your project outside of their contributions; this can include sharing recurring meeting details, a link to your project's Slack space, an email distribution group, or a link that allows contributors to sign up for newsletters.
+
+### About the "Share ideas" section
+
+Describe how contributors can propose their ideas for the project. Ideas can be suggestions for process improvements, new tools to use, new documentation, and more. Ensure you mention where and how contributors can share their ideas and the review and approval process. Alternatively, you can share a link to a template or form that contributors can use to share their ideas.
+
+### About the "Before you start" section
+
+List and describe contributors' prerequisites before contributing to the project. A prerequisite is any condition that must happen before a person can contribute.
+
+**Example:** Before you start contributing, ensure you have the following:
+
+* A computer
+* A strong internet connection
+* A GitHub account \
+**Note:** If you do not have a GitHub account, follow GitHub's [Signing up for a new GitHub account](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account) instructions.
+
+### About the "Environment setup" section
+
+An environment is a workspace on your computer that contains a set of necessary programming tools, applications, and plugins to develop source code. This section is mainly relevant for people interested in contributing to your project's source code.
+
+Provide a procedure on how to set up the environment for your project. As you explain how to set up the environment, ensure you provide any conditional steps, especially if there are different steps for specific operating systems.
+
+#### About the "Troubleshoot" section
+
+Describe or provide an external link to a procedure to diagnose and resolve problems that may arise when contributors set up their environment. The primary purpose of this section is to help contributors understand why there is a problem and how they can fix it.
+
+### About the "Best practices" section
+
+List and describe best practices for contributing to your project; sharing best practices can ensure the quality of contributions. Best practices can include coding, managing local and remote repositories, and other general standards you believe would benefit contributors to follow for your project.
+
+For inspiration on best practices, specifically for coding, see the following articles:
+
+* [Coding Guidelines](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/CodingGuidelines/Index.html)
+* [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)
+* [Google Style Guides](https://google.github.io/styleguide/)
+
+Also, if you have a parent guide for best practices, provide a link to it in this section instead of listing all the best practices from the parent guide.
+
+### About the "Content style guide" section
+
+A style guide contains a set of standards on how to write and format content consistently. If you accept documentation contributions and have established a style guide, explain the purpose of a style guide and share an external link to it for contributors to review and reference. However, if your project does not have a content style guide but would like to establish one, use The Good Docs Project's [Style Guide](https://gitlab.com/tgdp/templates/-/blob/main/style-guide/template_style-guide.md) template as a baseline for creating one.
+
+**Example:** Read our [Style Guide](https://example.com/) to understand our guidelines for formatting and writing documents. The purpose of our style guide is to ensure consistency in the tone, voice, and structure of our documentation.
+
+### About the "Contribution workflow" section
+
+This section contains the following subsections to help describe your project's contribution workflow:
+
+* **Fork and clone repositories**: Identify repositories that contributors must fork and clone for your project. Also, since the process to fork and clone repositories is the same for most version control tools, such as GitHub and GitLab, feel free to link contributors to read the [Using the Fork-and-Branch Git Workflow](https://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/) article by Scott Lowe or to any Git guide.
+* **Report issues and bugs**: Explain how contributors can report problems with the User Interface (UI), application, source code, and more.
+* **Commit messages**: Explain how contributors can create and format commit messages. Feel free to link contributors to read [How to Write Better Git Commit Messages - A Step-By-Step Guide](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/) by freeCodeCamp; this article provides examples of both good and bad commit messages.
+* **Branch creation**: Explain how contributors can create branches and merge changes.
+* **Pull requests**: Explain how contributors can submit pull requests (PRs). You should ensure that you address the following:
+
+  * Your project's PR merge policies
+  * Who reviews PRs
+  * The estimated timeframe for PR reviews
+  * What can a contributor do if they do not receive a response
+  * What a contributor can do to get their PR reviewed
+  * The approval and review process
+
+* **Releases**: Explain your project's release process and cadence, such as if they are monthly, bimonthly, weekly, or continuous.
+* **Issue management**: Explain the general process for how your project manages issues, such as tagging and assigning issues.
+* **Text formats**: Explain what text formats contributors must use; this is especially important for documentation contributions. Text format types include a specific Markdown flavor, HTML, and JSON.
+
+## Additional resources
+
+* [Coding Guidelines](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/CodingGuidelines/Index.html) by TYPO3
+* [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) by GitHub
+* [Google Style Guides](https://google.github.io/styleguide/) by Google
+* [Using the Fork-and-Branch Git Workflow](https://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/) by Scott Lowe
+* [Giving Respectful Feedback](https://symfony.com/doc/current/contributing/community/review-comments.html#giving-positive-feedback) by Symfony
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Contributing%20guide%guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/contributing-guide/template_contributing-guide.md b/meta/reference/good-docs-project-template-1.5.0/contributing-guide/template_contributing-guide.md
new file mode 100644
index 00000000..c7dbf50c
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/contributing-guide/template_contributing-guide.md
@@ -0,0 +1,126 @@
+# {Project Name} Contributing Guide
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_contributing-guide.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.
+
+## Welcome
+
+Welcome to the {Project Name} Contributing Guide, and thank you for your interest.
+
+If you would like to contribute to a specific part of the project, check out the following list of contributions that we accept and their corresponding sections that are within this guide:
+
+* {Contribution type 1}
+  * {Section 1}
+  * {Section 2}
+  * {Section 3}
+* {Contribution type 2}
+  * {Section 1}
+  * {Section 2}
+  * {Section 3}
+
+However, at this time, we do not accept the following contributions:
+
+* {Contribution type 1}
+* {Contribution type 2}
+* {Contribution type 3}
+
+## {Project Name} overview
+
+The purpose of the {Project Name} is to {describe your project's objectives or provide an external link to an introductory document, such as the project's README file}.
+
+## Ground rules
+
+Before contributing, read our {link to the Code of Conduct} to learn more about our community guidelines and expectations.
+
+## Community engagement
+
+Refer to the following channels to connect with fellow contributors or to stay up-to-date with news about the {Project Name}:
+
+* Join our project contributors on {name and link to online chat}.
+* Participate in our project meetings on {specify the day of the week and cadence} at {specify time and timezone}, where you can provide a status update or raise questions and concerns about your contributions. Use the following link to join: {link to online meeting space}
+* Stay updated on the latest news and changes to the project by signing up to receive our newsletter. Sign up with the following link: {link to the sign-up page for the newsletter}
+
+## Share ideas
+
+To share your new ideas for the project, perform the following actions:
+
+1. {Step 1}
+2. {Step 2}
+3. {Step 3}
+
+## Before you start
+
+Before you start contributing, ensure you have the following:
+
+* {Item 1}
+* {Item 2}
+* {Item 3}
+
+## Environment setup
+
+To set up your environment, perform the following actions:
+
+* {Step 1}
+* {Step 2}
+* {Step 3}
+
+### Troubleshoot
+
+If you encounter issues as you set up your environment, refer to the following:
+
+* Windows: {share a link to an external page that shares troubleshooting steps or share the procedure as sub-bullets}
+* macOS: {share a link to an external page that shares troubleshooting steps or share the procedure as sub-bullets}
+* Linux: {share a link to an external page that shares troubleshooting steps or share the procedure as sub-bullets}
+
+## Best practices
+
+{Option 1} Our project has adopted the following best practices for contributing:
+
+* {Item 1}
+* {Item 2}
+* {Item 3}
+
+{Option 2} Our project uses the {name and link to resource for best practices, such as a coding style guide or writing style guide} as our parent guide for best practices. Reference the guide to familiarize yourself with the best practices we want contributors to follow.
+
+## Content style guide
+
+Read our {name and link to your style guide} to understand our guidelines for writing and formatting documents. The purpose of our style guide is to ensure consistency in the tone, voice, and structure of our documentation.
+
+## Contribution workflow
+
+### Fork and clone repositories
+
+{Provide instructions on how to fork and clone your repository. Alternatively, provide a link to a Git guide that explains the process.}
+
+### Report issues and bugs
+
+{Provide instructions on how to report problems.}
+
+### Issue management
+
+{Provide instructions on how to create, tag, and assign issues.}
+
+### Commit messages
+
+{Provide instructions on how to format commit messages.}
+
+### Branch creation
+
+{Provide instructions on how to create and/or name a branch.}
+
+### Pull requests
+
+{Provide instructions on how to submit a pull request. Share a link to an example pull request or include the pull request template you want contributors to use within this section.}
+
+### Releases
+
+{Provide a description of the release process and cadence for the project, such as the source code.}
+
+### Text formats
+
+{Provide information on what you need contributors to know and use to edit and create documents.}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Contributing%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/glossary/guide_glossary.md b/meta/reference/good-docs-project-template-1.5.0/glossary/guide_glossary.md
new file mode 100644
index 00000000..4c42c2d0
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/glossary/guide_glossary.md
@@ -0,0 +1,92 @@
+# Glossary guide
+
+Thank you for downloading this template from The Good Docs Project! Before using the glossary [template](https://gitlab.com/tgdp/templates/-/blob/main/glossary/guide_glossary.md), 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 glossary is a common reference document that organizes terms and their definitions. It is best practice for glossaries to only store terms that are specific to a particular industry, organization, or team. Terms or descriptions defined in an established dictionary typically shouldn't be included in a glossary.
+
+For example, a glossary explaining web application terms should not include agricultural terms unless they have a unique meaning or use for that project, team, or organization.
+
+### Glossaries and terminology systems
+
+A base glossary usually includes a term, definition, and abbreviation (if there is one). More complex glossaries can include additional information, including localization notes, related terms, term provenance, and more. These more advanced glossaries are called terminology systems and are covered in the Good Docs Project's terminology system [template and guide](https://gitlab.com/tgdp/templates/-/blob/main/terminology-system/guide_terminology-system.md?ref_type=heads).
+
+The table below has a non-inclusive summary of information types commonly found in glossaries and terminology systems.
+
+| Information Type | Glossary | Terminology System |
+| --- | --- | --- |
+| **Term** | Yes | Yes |
+| **Abbreviation** | Yes | Yes |
+| **Definition** | Yes | Yes |
+| **Alternative term** | No | Yes |
+| **Rejected terms** | No | Yes |
+| **Related terms** | No | Yes |
+| **Part of speech** | No | Yes |
+| **Provenance** | No | Yes |
+| **Notes for translation and localization** | No | Yes |
+| **Context sentence for translation and localization** | No | Yes |
+| **Modified on (date entry last changed)** | No | Yes |
+| **Description of modification** | No | Yes |
+
+## Why do you need a glossary?
+
+A glossary can be very useful to an organization. It can:
+
+* Be a "cheat sheet" for team jargon, helping onboard new contributors faster.
+* Lower miscommunication caused by the use of obscure terms, or terms with multiple accepted definitions that may overlap or conflict.
+* Help users better understand the language used in and about a product.
+* Integrate with web pages to provide hover-over popup definitions (if saved in a machine-readable format).
+* Improve accessibility of websites and pages.
+* Simplify translation efforts for international teams and organizations.
+
+## Before writing a glossary
+
+1. Evaluate whether a new glossary is needed:
+    a. Is there an existing glossary that can be revised?
+    b. Does the identified audience require a glossary based on their knowledge level?
+2. Identify your audience.
+3. Research the most appropriate glossary format for your intended use.
+4. Gather terms.
+5. Consider the information you need for each term.
+
+For more detailed information on the glossary writing process, refer to the [Glossary Process](https://gitlab.com/tgdp/templates/-/blob/main/glossary/process_glossary.md) document.
+
+## About the glossary template
+
+### About the "Term" column
+
+The term you're defining.
+
+#### Tips for gathering terms
+
+* Consider whether the glossary will be a private team resource or available to the public.
+* Select terms with a meaning specific to your audience.
+* Search your existing source documents for common terms and acronyms.
+* Consult the glossary's audience to find terms that aren't yet defined, or have unclear definitions.
+
+### {Optional} About the "Abbreviation" column
+
+The term's abbreviation or acronym (if it has one).
+
+### About the "Definition" column
+
+A short definition for the term, no more than one to three sentences.
+
+If the definition already exists elsewhere (for example, in an online dictionary), and that definition matches your team's use of the term, use the published definition.
+
+If an authoritative definition does not already exist, you'll need to write one. Reference the [Glossary Process](https://gitlab.com/tgdp/templates/-/blob/main/glossary/process_glossary.md) document for definition writing best practices.
+
+### {Optional} About the "Source" column
+
+A hyperlink to the definition's source, if you did not write the definition yourself.
+
+## Example glossary entry
+
+| Term | {Optional} Abbreviation | Definition | {Optional} Source |
+| --- | --- | --- | --- |
+| application programming interface | API | An API, or application programming interface, is a set of defined rules that enable different applications to communicate with each other. It acts as an intermediary layer that processes data transfers between systems, letting companies open their application data and functionality to external third-party developers, business partners, and internal departments within their companies. | https://www.ibm.com/topics/api |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Glossary%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/glossary/process_glossary.md b/meta/reference/good-docs-project-template-1.5.0/glossary/process_glossary.md
new file mode 100644
index 00000000..0d1d5b30
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/glossary/process_glossary.md
@@ -0,0 +1,118 @@
+# Glossary process
+
+Thank you for downloading this template from The Good Docs Project! Before using the template, read this document for good 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 Glossary
+
+Researching a glossary requires a strong understanding of your audience and how that audience will interact with the published glossary. For example, consulting a glossary in a printed book is very different from using one on a website.
+
+Knowing both your audience and how they will work with the glossary will help you determine which terms to include and the glossary's final format. However, it is also important to keep in mind during this research phase that your glossary will likely grow in the future. Be aware that as more terms and information get added, your glossary might take on a larger and more generalized audience.
+
+### Identify the audience
+
+As you put together your initial terms list, consider the following questions about your glossary:
+
+* Will it be publicly available or private to an organization?
+* Will it be for technical or non-technical audiences?
+
+Answering these questions will help define the style and content of the glossary terms' definitions. For example, you would not include technical details such as API specifications if the glossary is intended for a broad, non-technical audience.
+
+Consult the glossary's intended audience to create your initial list of glossary terms. The following individuals could be excellent resources:
+
+* Those who have recently joined the team, project, or organization and are still learning or have recently learned the vocabulary.
+* Those completely unfamiliar with the team, organization, or project.
+* Those who are familiar with the team, organization, or project and who have insight on which terms should and should not be included.
+
+Remember that a glossary should not define every term possible, just the ones relevant to your team, project, or organization. A glossary should include the following:
+
+* Terms unique to the team, organization, project, or knowledge domain.
+* Terms that don't appear in a standard dictionary, or which have a different meaning than their dictionary definition in this organization, project, or team.
+
+Keep in mind that your glossary's audience might change in the future, as your glossary grows. Therefore, it's advisable to consider a more generic audience when first creating the glossary. Remember that adding terms later, if needed, is straightforward.
+
+### Research the format
+
+When you have a good idea of your ideal audience and the terms they need defined, consider the following:
+
+* How will readers interact with the glossary?
+* How will the glossary owner update and maintain the glossary?
+* Do you need your glossary to provide hover-over popup definitions on your website?
+* Will you eventually share this glossary with other organizations using similar terminology?
+
+Readers interact with different content structures in different ways. For example, a reader interacts with a glossary saved as a table in a text document differently from one accessed through hover-over popup definitions on a website. So, you'd need to write and structure your glossary in a format appropriate for its intended readers.
+
+You should carefully consider the ease of post-publication maintenance. Remember that your glossary is very likely to grow in the future - either by adding new terms, more information about those terms, or both. Therefore, consider a format that's easy for both glossary contributors and owners to maintain.
+
+At this stage, look at as many examples of working glossaries as possible. The results of usability tests on your existing documentation or website, if you have them, are also valuable. These resources will help you identify the format that will work best.
+
+Tables in text documents and spreadsheets are popular formats for a new glossary. We've summarized some pros, cons, file formats, and possible use cases for both types in the table below.
+
+|  | Table in a text document | Spreadsheet |
+| -- | -- | -- |
+| **Pros** | - Reader-friendly. 
- Easy to share publicly on a website. 
- Easy to add new terms by adding rows. | - Easy to convert to machine readable formats.
- Easy to expand terms and term data by adding columns or rows. 
- Easy to sort and filter. |
+| **Cons** | - Requires manual sorting. | - Not always reader-friendly. 
- More difficult to copy into target documents such as Word, Google Docs, or Markdown. |
+| **Typical formats** | - Table in Google doc 
- Table in Microsoft Word file | - Google sheet file 
- Excel spreadsheet file 
- CSV file 
- JSON file 
- YAML file |
+| **Use cases** | Internal glossary for a single team or project. | Support hover-over popup definitions for a website. |
+
+### Make a glossary machine-readable
+
+When a glossary grows to include more term information than just abbreviations and definitions, it becomes a terminology system.
+
+A terminology system is a spreadsheet-based document that stores the same content as a glossary, but includes more information for each term. The additional data for each term can include but is not limited to the following:
+
+* Modification records
+* Translation notes
+* Related terms
+* Rejected terms
+* Alternative terms
+
+Both the Glossary and [Terminology System](https://gitlab.com/tgdp/templates/-/blob/main/terminology-system/guide_terminology-system.md?ref_type=heads) templates from the Good Docs Project have been designed to make adapting a glossary into a terminology system straightforward.
+
+To develop a glossary into a terminology system, we recommend converting the glossary file to a spreadsheet format (if not done already) and adding a column for **unique identifier or "key"** for each term:
+
+Ideally, this identifier will allow you to link directly to that term entry, instead of the general glossary page. It also makes the glossary more compatible with machine reading. The key can sometimes be the term itself, or a shortened version of the term. Adding this identifier will also allow a glossary user to order terms by their key, not just the term itself.
+
+## How to write a glossary
+
+To write a glossary, gather the terms you've decided to include and either reference a definition written by an authoritative source, or write your own. If you can find a more authoritative definition of your term, such as from a standards body, or your company-wide glossary, then reference that definition and provide a link to the original source in the **Source** column.
+
+If a term is unique to your team, organization or project, or is a common term that has a unique meaning in that context, you must write a definition yourself. Consider consulting subject matter experts in your team, organization, or project most familiar with the term's unique usage to capture it in a definition. Cite or reference the standard definitions as well.
+
+### Best practices for writing definitions
+
+A good definition should provide enough information to prevent a reader from confusing one term with another. It should provide a brief but thorough explanation of the term's meaning, with enough specifying detail to distinguish that term from similar terms.
+
+For example, defining a tiger as a large cat native to Asia is insufficient, as this definition could also apply to several leopard species. A much more thorough and accurate definition of a tiger would be: "a large Asian carnivorous mammal (Panthera tigris) of the cat family having a usually tawny coat transversely striped with black" (Merriam-Webster).
+
+A definition sentence should start with the term it is describing. Using the example above, you'd edit the definition to start with "A tiger is a large Asian carnivorous mammal…" rather than just "a large Asian carnivorous mammal…".
+
+Repeating the term in its own definition may seem redundant. But as a table-based glossary grows, it gets easier for its terms to get separated from its definitions, especially if the glossary is manipulated with scripting or queries. Repeating the term within the definition is a redundancy that allows the **Definition** column to remain coherent, even when removed from the **Term** column.
+
+The [ISO 704:2009](https://www.iso.org/standard/38109.html) standard recommend writing a definition in a way that allows the definition to replace the term in a sentence, and still retain coherency. While this is theoretically good practice, it may become unwieldy with terms requiring a lot of technical specificity.
+
+**More tips for writing definitions:**
+
+* Define one term at a time.
+* Use common terms in definitions that the audience is likely to understand.
+
+## How to maintain a glossary
+
+Appoint a single owner responsible for future glossary maintenance. Without a named owner, it is very easy for a team to think that other member(s) are going to keep the glossary updated, and no one actually does.
+
+Task the glossary owner with reviewing the glossary on a regular cycle, such as quarterly. They will be responsible for the following tasks:
+
+* Updating the definitions of existing terms.
+* Adding any new terms and their definitions.
+* Ensuring the new terms and definitions do not overlap with existing terms.
+
+One way to do this is to have the glossary owner consult with individuals who have used the glossary to find any missing terms or confusing definitions. Depending on your glossary's audience, these individuals could be:
+
+* New project members or contributors
+* New employees
+* Team members most familiar with the needed terms
+
+If done on a regular basis, glossary reviews and updates should not require a large amount of work. However, changes can pile up very quickly if the glossary goes without updates for an extended period.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Glossary%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/glossary/resources_glossary.md b/meta/reference/good-docs-project-template-1.5.0/glossary/resources_glossary.md
new file mode 100644
index 00000000..91ac6614
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/glossary/resources_glossary.md
@@ -0,0 +1,34 @@
+# Glossary 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 glossaries
+
+* [Github glossary](https://docs.github.com/en/get-started/quickstart/github-glossary) - This resource provided an example of a glossary in a published web page, with each term or heading linkable.
+* [Glossary - Fisheye Server 4.7 (Atlassian)](https://confluence.atlassian.com/fisheye047/glossary-981149994.html) - This resource provided an example of a glossary in a published web page, with each term or heading linkable.
+* ["My glossary template" (Open University)](https://www.open.edu/openlearn/pluginfile.php/402344/mod_resource/content/3/eco_1_glossary_template.pdf) - This resource provides an example of a glossary with a simple table-in-document format.
+* [Content Design Glossary Template (Atlassian)](https://www.atlassian.com/software/confluence/templates/content-design-glossary) - This resource provided an example of glossary that combined the table format and linkable header approaches.
+
+## 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 |
+| --- | --- |
+| ["Writing Definitions"](https://owl.purdue.edu/owl/general_writing/common_writing_assignments/definitions.html). Purdue Online Writing Lab, Purdue University. | Referenced for information on how to write term definitions.
 **Key Takeaway:** Write a definition using simple and common terms. |
+| ["How Do You Write a Good Definition?"](https://www.johner-institute.com/articles/regulatory-affairs/and-more/how-do-you-write-a-good-definition/). Johner Institute. | Referenced for information on how to write term definitions. 
 **Key Takeaway:** Use limiting characteristics to make a definition specific to one term |
+| [Benefits of a Terminology Glossary and Style Guide.](https://www.dynamiclanguage.com/benefits-of-a-terminology-glossary-and-style-guide/) Dynamic Language. | Referenced for the benefits of a glossary in a business use case. 
 **Key Takeaways:** 
 - A glossary unifies language about a subject. 
 - A glossary helps ensure consistent translation and localization. |
+| [The 6 Main Benefits of a Business Glossary](https://www.linkedin.com/pulse/6-main-benefits-business-glossary-george-firican/). George Firican. | Referenced for the benefits of a glossary in a business use case.
**Key Takeaway:** Appoint a glossary 'owner' responsible for ongoing document maintenance. |
+| [ANSI/NISO Z39.19-2005 (R2010) Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies](https://www.niso.org/publications/ansiniso-z3919-2005-r2010). NISO. | Referenced for existing standards on writing a term definition.
 **Key Takeaways:** 
 - Contextual information on controlled vocabularies relevant to expanding a glossary into a terminology system.
 - Write a definition with enough detail to avoid confusion with other, similar concepts|
+| [Tiger Definition and Meaning](https://www.merriam-webster.com/dictionary/tiger). Merriam Webster. | Source of the "Tiger" definition used as an example in definition writing. |
+| [What is an API (application programming interface)?](https://www.ibm.com/topics/api). IBM. | Source of the "API" definition used in example glossary entry. |
+| [SKOS Simple Knowledge Organization System Primer](https://www.w3.org/TR/skos-primer/). W3C. | Referenced for existing standards for term and definition concepts and organization.
 **Key Takeaways:** Contextual information on controlled vocabularies relevant to expanding a glossary into a terminology system. |
+| [ISO 704:2009 Terminology work - Principles and methods](https://www.iso.org/standard/38109.html). ISO | Referenced for existing standards for writing a term definition.
 **Key Takeaways:** 
 - Introduced standard that a definition should replace a term in a sentence without loss of meaning.
 - Contextual information on controlled vocabularies relevant to expanding a glossary into a terminology system. |
+| ["Create a well crafted glossary for software documentation"](https://indoc.pro/documentation-types/glossary/). Indoc. | Referenced for information on glossary research and planning processes.
 **Key Takeaway:** Term collection is the first step to glossary creation. |
+| ['"Speaking the same language"--the importance of having a glossary of "commonly used terms" or "jargon" when implementing a project management methodology and managing projects'](https://www.pmi.org/learning/library/clear-definitions-fundamental-terms-principles-490). PMI. | Referenced for benefits of a glossary in a business use case. 
 **Key Takeaway:** Glossaries are a tool for decreasing miscommunication and facilitating onboarding for projects or teams. |
+| ["Technique G62: Providing a glossary"](https://www.w3.org/WAI/WCAG22/Techniques/general/G62#:~:text=A%20glossary%20is%20an%20alphabetical,of%20a%20word%20or%20phrase.). WCAG 2.2 Techniques. | Referenced for benefits of a glossary in business use case.
 **Key Takeaways:** Publishing an online glossary is a web accessibility technique. |
+| ["Glossary maturity levels"](https://thegooddocsproject.dev/docs/glossaries/maturity-levels/). The Good Docs Project. | Referenced for information on glossary types and structures.
 **Key Takeaways:** Provided contextual information on evolving a simple glossary into a machine-readable and potentially shareable terminology system. |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Glossary%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/glossary/template_glossary.md b/meta/reference/good-docs-project-template-1.5.0/glossary/template_glossary.md
new file mode 100644
index 00000000..5e377ef2
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/glossary/template_glossary.md
@@ -0,0 +1,13 @@
+# Glossary template
+
+{If you need more information about how to fill in this template, read the accompanying [Glossary template guide](https://gitlab.com/tgdp/templates/-/blob/main/glossary/guide_glossary.md).}
+
+{This template includes 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.}
+
+| Term | {Optional} Abbreviation | Definition | {Optional} Source |
+| --- | --- | --- | --- |
+|   {Term}  |  {Abbreviation}   |  {Definition}   |   {Source}   |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Glossary) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/how-to/guide_how-to.md b/meta/reference/good-docs-project-template-1.5.0/how-to/guide_how-to.md
new file mode 100644
index 00000000..73d53e6b
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/how-to/guide_how-to.md
@@ -0,0 +1,174 @@
+# How-to 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
+
+The how-to take your users through a series of steps required to solve a specific problem. It shows your users how to solve a real-world problem or complete a task in your application, such as how to create an issue in GitHub.
+
+**Note:** A task is an action that your users can do with your product to accomplish a goal. Multiple tasks may be involved in achieving a goal.
+
+The how-to clearly describes a set of sequential steps your users must complete to accomplish a task. The how-to assumes that a user has basic knowledge of the application and has already read the quickstart and the tutorial.
+
+Do not use a how-to to teach concepts.
+
+How-tos are often confused with [tutorials](https://gitlab.com/tgdp/templates/-/tree/main/tutorial). How-tos are task-oriented, while tutorials are learning-oriented. The table below identifies the differences between the two.
+
+| Tutorial | How-to |
+| -------- | ------ |
+| Learning-oriented: Helps beginners or expert users learn a new feature in a hands-on way. | Task-oriented: Helps an expert user accomplish a task or troubleshoot an issue. |
+| Follows a carefully managed part from the start to the end. | Aims for a successful result and guides the user along the safest, surest way to the goal.|
+| Eliminates any unexpected scenarios and provides users with a successful finish. | Alerts the user to the possibility of unexpected scenarios and guides how to deal with them. |
+| Assumes that users do not have any practical knowledge and must explicitly state any tools, file configurations, conceptual details, and so on. | Assumes that users have practical knowledge of tools, file configurations, applications, and so on. |
+
+## Why do I need a how-to?
+
+A how-to is often used to help advanced users perform a task correctly. It can:
+
+* Demonstrate to your users the different capabilities of your application.
+* Guide your users to solve a real-world problem within the application through an ordered series of steps.
+* Help answer specific questions that users may have.
+* Make users comfortable using the application.
+* Improve the user experience, and help reduce costs by lowering the number of support requests.
+
+New users can also benefit from a how-to, provided the how-to is well-written and states any prerequisite knowledge required to complete the task.
+
+## Before writing a how-to
+
+Before you start working on your how-tos, identify:
+
+* The main use cases for your application.
+* The different scenarios that your user may encounter in the real world while completing a task. If this, then that. In the case of …, an alternative approach is to…
+* The surest and safest way to complete a task. By suggesting multiple ways to complete a task, you're asking users to think through the different ways and choose. Save your users' time and effort by eliminating the options.
+* The different error scenarios that a user may encounter while completing a task, and their corresponding solutions.
+
+## Best practices for writing a how-to
+
+* Address one logical goal (task) per how-to page. Try to avoid cases where only a subsection of the how-to is relevant to the user.
+* Prepare your users for the unexpected, alert the user to its possibility and provide guidance on how to deal with it. For example, include callouts such as a warning, caution, or note to communicate important information while completing a task.
+* Use conditional imperatives. If you want x, do y. To achieve w, do z.
+* Do not explain concepts.
+* Sometimes it's helpful to occasionally provide links to supporting pieces of documentation for more information.Especially, when the user might need a link to supporting background or [conceptual](https://gitlab.com/tgdp/templates/-/tree/main/explanation) information and/or [reference](https://gitlab.com/tgdp/templates/-/tree/main/reference) materials. However, avoid providing too many links within the guide. Keep your users on a single page as much as possible and provide links to additional resources at the bottom of the page.
+* Avoid over-documenting multiple ways of achieving the same task. If there is more than one way to complete a given task, pick and only document the most common or recommended method of completing the task. Additional methods should be omitted or mentioned by providing a link or reference document.
+* Avoid writing edge cases at the boundaries of your application's capability.
+* Always ensure that the steps provided in your how-to guide are technically accurate. Test your how-to instructions from start to finish so that you can uncover omitted steps, incorrect details, steps out of order, and information gaps that block users. If it's not possible to test it yourself, have a developer or subject matter expert demonstrate the step to you and record the session, if possible.
+* Re-test instructions after every notable product release to ensure instructions are still accurate and work end-to-end.
+* Lengthy how-tos can overwhelm users. Focus only on one task in your how-to and restrict to a maximum of 8-10 steps per task. If the task is too big and complex, you may break down the task into multiple logical sub-tasks with their own steps.
+
+## About the "Overview" section
+
+Use this section to provide the following:
+
+* A clear description of the problem or task that the user can solve or complete.
+* When and why your user might want to perform the task. For example, in a guide for creating a pull request, you might tell users that pull requests are used to let others know about the changes you have pushed to a branch on a repository.
+
+The how-to assumes that a user has basic knowledge of the application and knows what they want to achieve.
+
+Here are some examples:
+
+* This guide explains how to create an issue on GitHub. You can create issues to track ideas, feedback, tasks, or bugs for work on GitHub.
+* This guide explains how to resolve merge conflict using the command line. Merge conflicts occur when competing changes are made to the same line of a file.
+
+## About the "Before you begin" section
+
+{This section is optional}
+
+This section describes what your users need to know, or need to have before they attempt the how-to. By stating the requirements up front, you prevent your users from getting halfway through and discovering that they need to go and read other documentation before they can continue.
+
+Use this section to communicate any prerequisites for this how-to, such as:
+
+* Familiarity with the application
+* Software and tools needed
+* Environments to set up and configure
+* Authentication and authorization information
+* Other guides or information to read
+* Links to procedures or information, or any useful pointers about how to get what they need.
+
+For easy understanding, consider grouping prerequisites into categories such as background knowledge and software prerequisites.
+
+Optionally, provide cues that signal to a user that they're probably in the wrong place and offer more suitable options. For example, If you are a Linux user, refer to {link to relevant Linux how-to guide}.
+
+Here is an example:
+
+```markdown
+Before you begin, ensure you have:
+
+* A conceptual understanding of RESTful APIs.
+
+Before you begin, ensure you have:
+
+* API credentials for the v3.5 API.
+* Access to the Postman application.
+* (Optional) A development environment (IDE) that displays API responses formatted for readability.
+```
+
+## About the "Steps" section
+
+The steps section is where you describe what the user needs to do. Use an ordered list structure to document the how-to steps. How you write your steps will vary depending on your organization's style guide. The template organizes the steps in the following way:
+
+```text
+{Task name}
+
+{Optional: Provide a concise description of the purpose of this task. Only include this if the purpose is not clear from the task title.}
+
+1. {Write the action to take here. Start with a verb.}
+
+   {Optional: Explanatory text}
+
+   {Optional: Code sample or screenshot that helps your users complete this step}
+
+   {Optional: Result}
+
+{Optional: If needed, you can add substeps below a primary step. Make sure to indent the substep one tab space over if you're using Markdown.}
+```
+
+Here is an example step:
+
+```text
+Create pull request
+
+Pull requests are used to inform others of changes you have pushed to a branch in a repository. Once a pull request is opened, you can collaborate with reviewers and make changes before merging into the base branch.
+
+1. To create a pull request, do the following:
+
+   1.1. Navigate to the main page of your repository.
+
+   1.2. Under your repository name, click **Pull requests**. By default, all open pull requests are displayed.
+```
+
+If you're including code samples in your steps, make sure they are also indented correctly:
+
+1. Set your Git username for your repository.
+
+   You can change the name that is associated with your Git commits using the `git config` command.
+
+   ```bash
+   git config user.name "Dakota Everson"
+   ```
+
+### Tips for writing steps
+
+* For task names, start with a [bare infinitive](https://en.wikipedia.org/wiki/Infinitive#English) also known as plain form or [base form](https://en.wikipedia.org/wiki/English_verbs#Base_form) verbs. For example, "connect", "set up", or "build" and express the heading as a complete thought. Don't use the -ing form of the verb because it is harder to translate. Instead of saying, "Connect", you might say, "Connect to the VM instance".
+* For each step, optionally provide some background information about the task so users know what they're about to do and why. Continuing with the example, you might provide some best practices for creating memorable repository names.
+* Optionally, add a [code sample](https://developers.google.com/style/code-samples) or [screenshot](https://developers.google.com/style/images) after the explanatory text, depending on the type of how-to you're writing. Screenshots are a great way to show specific parts of the screen you are referring to in a step. Make sure your code samples work and are always up-to-date.
+* Remember to orient your users when walking them through each step. If they need to open a particular file or dialog box to complete the task, provide that information first.
+* Provide examples of sample output such as return data or a message so that the users can validate whether they performed the step correctly or not. For example, you might want to provide what a valid and expected result looks like on entering a command into a CLI.
+* Use plain language and define the terminology of any technical term next to it.
+* Include one action in a step.
+
+For additional tips on writing steps, see [Writing Procedural Steps](../writing-tips.md#writing-procedural-steps) from The Good Docs Project.
+
+## About the "See also" section
+
+It's likely that during explaining a multi-task process you will touch on other topics related to the current one, but not strictly required. This section is useful to provide your users with suggestions on further reading without interrupting the topic covered by the current document. An example might be setting up an email client, which requires working credentials for an active email address. The reader need not know how to install and run his/her email server to acquire that access, although this is potentially useful. The link to documentation on running a local mail server could therefore be included in the "See also" section.
+
+## Additional resources
+
+* Bhatti, J., et.al. 2021. [Docs for Developers: An Engineer's Field Guide to Technical Writing 1st ed. Edition](https://docsfordevelopers.com/).
+* [Diátaxis](https://diataxis.fr/). 2017. A systematic framework for technical documentation authoring.
+* Carey, M., et.al. 2014. [Developing Quality Technical Information: A Handbook for Writers and Editors](https://www.amazon.com/Developing-Quality-Technical-Information-Handbook/dp/0133118975/ref=sr_1_1?crid=ZJR527VZPRL6&keywords=developing+quality+technical+information&qid=1662901229&sprefix=developing+quality+t%2Caps%2C196&sr=8-1).
+* [Google Developer's Style Guide](https://developers.google.com/style/lists).
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=How-to%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/how-to/template_how-to.md b/meta/reference/good-docs-project-template-1.5.0/how-to/template_how-to.md
new file mode 100644
index 00000000..90dddb2a
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/how-to/template_how-to.md
@@ -0,0 +1,59 @@
+# Title
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_how-to.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
+
+This guide explains how to {insert a brief description of the task}.
+
+{Optional: Specify when and why your user might want to perform the task.}
+
+## Before you start
+
+{This section is optional}
+
+Before you {insert a brief description of the task}, ensure:
+
+* Prerequisite 1
+* Prerequisite 2
+* Prerequisite 3
+
+## {Task name }
+
+{Optional: Provide a concise description of the purpose of this task. Only include this if the purpose is not clear from the task title.}
+
+{You can use this format to describe your steps:}
+
+1. {Write the step here. Use a verb to start.}
+
+    {Optional: Explanatory text}
+
+    {Optional: Code sample or screenshot that helps your users complete this step.}
+
+    {Optional: The result of completing this step.}
+
+2. {Write the step here. Use a verb to start.}
+
+    2.1. {Substep 1}
+
+    2.2. {Substep 2}
+
+### {Sub-task}
+
+...
+
+{This section is optional. Include a sub-task only if the task is big and complex.}
+
+## See also
+
+{Include references and/or links to other related documentation such as other how-to guides, conceptual topics, troubleshooting information, and limitation details if any.
+
+* Reference link
+* Concept link
+* Troubleshooting link}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=How-to%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/images/importance.png b/meta/reference/good-docs-project-template-1.5.0/images/importance.png
new file mode 100644
index 0000000000000000000000000000000000000000..56f3ac6e0eb218a88808021718654ab7e7c6dd19
GIT binary patch
literal 188284
zcmZsB19)alvhW*YVp|hi6Wg|Jzp;(U#P-Ct?MyJy#I|ia`Sb1FfA8M?_B>CY?$g~>
zb*ieXsuiXnCk_vb0}B8E;3XwQlmGzG{?DWb4f$D9UxHc$0KoBC3JWVp3JVh{INF(6
z+L!_W5@AW|P#Vg^7+Km%#0>yYB_X@O&_sZekOfGA8!j;nl2l|sj*&P9y3QABjGEkX
zlJHD3@l)FHP6iCLM3-6v_4NY(s+W<6{g?f5zYorvY?g!ZRWB&O9jZ<(2h<#ZNIj7u
z4CdaPl&qLhVhsSL9XheamPYEiJ2~sO>dv3zlUy8IMfXmd+>|?f!$c61UBZE7=
z>&Wt>#)$q}2mxt7%&BGOW5W6MB0l{q{;eTIxm6JU`#s1hpdKt
z6bMGVp_s7OpvFmT>7)t9iCvS=&M@hPyAuv%j@``qhy_bmw1w{{G9comF{S8czsZDT
zf*11yQjtJvar&b@mTC>9(wTzOPD2H8!&t>Ix*__RKox7cg$QXRQosi&&!nAhAP*vd
zBWR8!iSB;BW;&rH{2DYdG%a^OV$;fIILT0MZrDx_`MQpP8qjEo(@9A*UJ3gJ(%W{1MSFNM0>@n5S5)n4p*;
zyvzF+>k>Ck4Mjw;^mpvECpe5(5@;+uV=+(0)D&2=IQ5$fh^~n#g
z>Emr+uzBf5f6D=QS>3v~dmdk6+$t7^@OP5sDJ>BAwN>{8q>F5JOKt}0cMslT&l3k2
z`zFMz01-4q91#L(P#EL0Ov^Z#0d*?OegKLBWO9J20sbO%lRv%z`ywJv53)T<1_P;H+Soff#uM
zhbYeQT2bdhCsPTBqPJYjVO;_*O#YdoH@emwrDPJx<8hPV)fmIJ`UzI-!cOZU<`+cw(v+$PwDF@m~cs?8Q5IZ8N{
zTrZG7NlBEaCaxqqBf+Q8C3cD9i&Y&WH!*ia;tZxG!HlCB;vOCxQXiTa%BI3WlMbgK
zi|;L#DW)y7DP&cqS8SuqF8!%uUB><``lo27xUO(zepb&SD
zgXyx_N>y{GO~`WVvgxwwvTmLD+1hFF{mB`(7?PNKBvMoffy0d8T)>{frozePq~Ze8
zYVA<%ud6+Yh&ZaRDKR|U*Xar6%F#1w#qIeGV!_eWICDJ5jrEx<6Rp!v%NEOrIa5wz
z?9sk^Mi(UZOPh|PN#|ViE&|xrO+A;0HUS(cMFS12!Ea9!G9^*lqTNg}&
zJE4Q(^6V4d6K`359-Qu`UT3$*1jf8#jAkdPgX?DNIu~Q>nS5~BD%rApnO#L)IvZ9S
z;=cR7-rYdo35})-+IjkUX+H|Tun*#o2OIf&+WRm7EfGf!YYwjh4I`hu?q(2CeNJS~
za!!}Q!Y1}F3L$7>L*h|kTgONa9y$18hFM-`H4E!hD-D~)wi@v**RA-={o2FD$y%D<
z>k&1PNTRGFff91N;X^Nq^NPxO2;!*u`FS+?*}o&h)3BY`k_ot}T+L70IX+qn9o%++
z+l5zjFvl=Es8%TJ6p*CJ6t3h^GCz}?nU;t&Q&&@kq$DMllBfCU?N`ejba!+IQzE;W
zetGsbz#LHE$oxrjcaDE1Jud(&{XW}2n^~&g61Qq)>xV;8NnIH;xL>*7x%qOXe(eRm
z9_aY1-udG8`t}^|A`%^&H?1oTJ*`uy$v*Q^RZU|4cg4d}+|o)tlp~7M{cgOIvQxT<
zR-TRGiOJ6J47pqA*#O!0I8~Oin(R@+cgdzbVh_}7oSVk281M91vFC_e!vJ|f(_bN_
zFv^HBGa2MR=h@b5pYx6;V1r=&(gP+o$1Kt;xt!Mjgw$))vrUMZ6_44b8S@pp%Pp*K
zwsP+)9+*zNbPko4bR3?&_CJjchz&SJ5PqP%N&~~R!U}fxL8~EfF}J@2e_6qd(ra*?
zYF6?+3T7^@3$J5{@Q7e|
zM}tixt=^^k&2sJuHYGf&ytKTqoO|JWwWW@At?SYTs1u|2t4KRNho?vr5c|PDB5W~F
zR&-Vn-p-$2a$TG6pQX=Ja2ULFY|pV~98SY8k`mOxsM{7{f0(^!r!>>ODZU}D?{&SrcHIWOhu{;Y5l;9@z22VQ%rX=(Sa&V^0^c$2&(;Ob
zd;C*rwnqFQ7&WGDodJ4wQ2xnq0Q{_pk{z@Ieh)!3b2U!T4;Y&9(CckT0sL3LnDbyi
zc6N}(c65U7oUUhgK%NDl-vi)$dzj1Ru9lEZV;T%S0g`UiRkT+W;HQjcK2Es(-U`92
zih1eu!oY{-9qHLpdh@xU2shP`G?SGDP=A)80pK7w0Eo{L$YLbl?3|5cJ@P&)VC*F{od5s~vcD3Dq!Q`nC;oX$6%A(%Ss5;4J0QKGiJg%t
zy*tqUFFXJqcdpMO(A3$G$Q@{7>%`^GOY)B%T%YB?su@U#{?WzRnwLaFR)I*^&e4>J
zjh>O7k%SMHh=_>C(Zq~PNkr_Q;GbW-Bo@xj_FN1MZf1|&tJ7%3YPAsHku-qz)zWd(%@rbWaIfq|G%~T
zFU5a@)c9XWc1DhWhy1se|AbU^GIbQT1AdZp=KEiD{S)}#8~+K&!|)g9|0aq55%WK4
zKjq8^%fs+5o$QNIUSjNKa2kA`O6^Na%R5WHBGlNaMW8WHH|#wgdu!
z^-XNr^{$n4S`9<+;ou5WI5HC#LJNDgZbvb@G^+m6V+HUpq+
zMw96bcAJ1bH6+JRRa{Nt)?O2Cs%Fm2a}&60)|kV$MB&ES6|(ZH=zW9HD3Os;R>?!UF82VKor+Ar~|t6IK@OJwt}Xi3PphQ9wBP~3j%YoFh$P_iqN|T9RuTe
z=kyUAH%tTYNgmwp(j=b2F|cjf>)C@z-FW
zrlC0-z|?Qpc)xF!v$)*+8z^U-}UgZD24{@2UOAy?SY;EKEQ($ZS}kLLwB
zlbzpDu2Z6zPj=h=VF=%icRSGscFF%!?VnN;rv=$s#ME>D^?t+uF_YzUuZhd;TJg4x
z*Q6>AZ#c@BaK|eaip7!+-hnvC@
zi{c;S_h0JyOJDBYD4|y;MY8FucMl^p)eY!0YKyzW32SZ|Uyeo`-sa+>)a$P-qX7-NucyV?uTafJ+T`w}phCtP;#%iCj=CaVRy}dmTmA9!p9{i>LH^EzTuZj9T(uMyu
znSYUNq6okWa`mo`A~YNOxwj6#EcQufocBTJfFbqTk+
z+jismz8Ux{5W;mgPJB7W@6|Y+(J(M6F_EJe1NvOT-K)pVYl7RD+9UbzmYS0f&IQ)r
zo2vETI*9MKSnYd9^I+Q&3!JBaUOhPN0Ykh6&YSeFA!Dr36JadQ&0BZBtX-@k3frPk
zWP8`Wpd#XNOg^D1lT_*d*}O+tS-*+KmOV%PryKYePbe_X7KqRNJ&eH0t4KABa&Bn+3gX;wEL+Wd2f|8XZ{4=zN^Bz>xL9L&&UUpl;X9AHIKVC2@2|1tateooNSx69
zUzl{21Jx41v^&jNBQ?SAdO2^$_sVkkjeUPt?YD+Gw|8)GfhQ<*hJ+Lp?sEX+^Goif
z_3ib5|AB64SDM!8wsw#pB8fx)S5qxLg};08C=pERe-4S71eDO`58Y1B#<5hUKHsNN
z{bx4oWr9bqjhC#m#s$4D5Rt(sLRS&r5PuFf$%xI9Qx1nUmxZ*9q;}UctKv-8pLTuo
z&35{3nTM$oprPDSq^p)bKa0tSkotgJtxqjpJ
z_V$C0$U+sdv~3~=1OZBIOa_v2%$
zg3c7nKlp^*g>@L(^tpm$4{{%5IN40*2-@bU;RQ$d;aigaH{)~_17&VFo)qE=Fu*n=
z^m}z+@Bc@{S-bFE@Vq}wBPL4;dx#L+z$C&DW|kdw+Zm?FW^I)|ycws+un*Mrz8YXl
zI-?KQSfUVf?$9@5=9HxWdn~;|3H`-*4%HM6oCp7Yw*|j7G2y+>;yQq?zPR}-sIsKQ
zqCAuAyWqyeRTrQZdeFe_{q^bmPX)u`u%)IKs`W)PvG5NQHfdk}NK(W9;=?3Bv5D})
zgdgPj-x~ZV&jX+cYLIOX?T5)yS_IVyk3yqr@F%!w#vUL-!4?ttdbOKuYT4J_`+T2g
zvY$O}52w1|R}{tZ8{6r{(fPajy-fqILKfNglUXQCOh6YQ+jM{W#s
zb(ds>{QZd?A9NcZS#cY5p!<2QT1KL?sOYyG@108fY2D~6_w;A*AO90=L3;5w;h?}Y
zNE2xZKvBxw%qXg>nq%wv^4)^I-4{&y+ZdP7VdH4deIH%mtpboT>WA7a#|mgl$_kgEox4<
z8M<>(0lm>2tN}OJh0~@MSlxO5bIs!*^L$~dSe{V)?E36*u3X&=w<*(<5+>#UdZ$n0
zlZ+R5;p=m#3TDvO((=yy*`zrGwbju0v+3#WzPTIt8Ox)^(aH5xFbC(JghBdigEhjA
zitQx6bbjn+e=K1bkj?kD`8|gC)lk{=k>9S5CwdF6XUmJb?#G|}Z895^0B&Ld-_?8O
z&a`VsSB0Wge9!Q4%@Fby|((j{b@hFva4(T*X3W~|1FN{h!vW_|0WyBVD(J
z3{N2(x25}Q4zIHQEnmMfP0q2|bibY1ovnLa+(jOKas9_^?s|9FcKIBO;lIR?T`3~H
z6mpo)cqul2G*i6tR|MZM1Fp6>xb7vXFB^v7H?0BZ`AWduu!%5w7x*0Py5E{EIC7&B
z?yz}%)}L0LChmB5_$ccoU;nO?7;qE#Xw2U*NGG08*L&}oUwn!*yLvJ8y=ybw);*%h
zjGM!C=>l{?Lmjqj)c&lE$;!^lh}m|(xqi-$e9fg(=o@#UxySh)S|^q)i!+l2-)luV
zxmhxKM}4z({x*m3?jW6n^hNtI8<(DLO`~3Qi%<6c(*3bg{b{528$s@WQkiTm)^uAp
zzWHOFn_Od*O_=xXF4=XOx~)2d=z5(sc8z{#Q`|7eN)0iP(F+?NT$WXFUIHCMIUoTT+6gJ;Y+C$+h^=)1e;<9JQ0h)HNg-S^tCn6UU|Dw8Zg19s%C2_y-CBV-H-5
ziLLr^uF?B-FFUwWEt`eoMa2u(!CGk@@(d>0zNI9UO^uh|x}Wa$T)x9(80AAF#5?Sc
zto=+gRFnp!zrCuYesp)Ika9cYC~{PejVN0GYziB}`=Tv=oq()xhN)765kK25=C>CQ
zX4>gj^6WPo?gc`kV^_+q1>-`jgBKshXFU_QN4{~>j4Dt+4aYBcw%7Y
zZf=73(iK-{wB*4diL@C0(Fa`vx9nvn;cr^gkXOd|3tHW)OT&V*yp4e{(}na!_hh=6
z@oH0u$P>_$D4qvxX(Da8rG-4qkjM$oCe=<@#Q1KnRB$%CbsKrUtM6|Q7k(ET4XLb_
z@t-p~{<<(!il5#g5P^HaL?@R7*2Lqt-aXR>+W^OI%(2QKiHRVCUY+`|dBa}$;nl{OCdZWwZOHtK876eNGPqdvfmswo5^qfr@NeXDd?8G314x&&3O
zE>mKE#8})xC^a;G7k?%k)!MJY#T!CpvEqT)3QzG@J|km^(cShRtAn&WHME%dEHH+t
zrWTbI5C^nB3DJ$A(=e9eCfn(crQ+d)j(vp$!PD0%iXvAPUlDNEes%L7(ON)H6N|ZH
z1&YTBLB5IV=qb)tC}-r`N4HLDzM1H>*O7SB(wlOqzBinouDNYA{hZlS`_~VhK%y7EYqLLdPz61-gR~
zS*Xz_Q^x_feDJD#7%*2Bus_TL%!4sy-_X)Zarh%JT;{&<#N_8kf!_|zEU<_=Xes*J
zk2-aR`YB?`3&l@~-rn#yv6L5>3%kXJQB
zQ2~Eh{ykAD&$0|*Jo?_PxV}Q80dYCRO@x9W5UgRW!KVXPpQLzlcQ=OxXs6PZ9
zpwY10^w61+=Jb858ZnZZNg5Y9||JoxA
zC@#GJBY#I$gHGRHVccBGB}8q6LXMj+ztQFX`aMCmP~?j7M3Ltx~DeSP54
zr~e(T1Ux{DmZn;pX({$YKz`|Kq_
zl#w)tJzieS3ND4{Mj}(h*da*8{bA6M!6ZN2%bf3Sa{L7otKyLij1Gj?gAwTZ!=4}>
zxkUGh26jqr9D}9Y{BG56VH@IV?Y>60Nj#6MRWN05fVIYP$CkuI8cdS
z=(>-@Y}1?}N!g)~Nw3kQbt8b>GD}HsmeJJ-?N2&1iCtyt(9%;>NK7FY=0|JR$vfnd
zIs*DYkZ7_KtGAD;v99tH1mP!wI+z2Px6rvwgf5mhy!7g`+^Mfl9xEE2F79TrC%;Gv
zhYb3gLrmVyi|=Xi~9kH^@8+4z_3VkLy_$@Fh4LE;LHy-j4}
zX)dWk>N&yGaW5|i2_q@*H~mj!>M(ugJ8N;IT|
zEF;N#-kWWm-(u<`^FudU`C1OoHFyTL%;8-^yhUG>x}|6n2UCj)Hfx`Z0G)eB-%j+Z
z7GtnsTFfKfjfZX(8oQ;}%%>5Winy!d$`cC+Ljg0oLPuDL^*!2}%K{n5D|DRXOu5bc
zL7KHC*vP(Mn$#!2Ux;!ign~YtTu%=}>{E(jAO2NMs=J?5a#$8Jj4Xk39J_N9EtIVZ6DhL7m9X_3mMUkA=MUD
zCRZuWG%KKKeQM{eW7iLLBl9|MJ$MbWeOPnLKKtB?B|oX*>z%69ZiYiThkJFsKMjK3
z|6I1s&CQ*oUe{;8{b@Fyp?LhqhP#7uu@>Szd2*5lyoxwzxSLMKItLj|BSWUHjTLR&
zDf3hi4+LAUHe#Gd`xr!n5K95^@lOe>SS8V_=(=eKDeSzqp;a4EHU*XbP_`5$t?_zs
zYr-dPk4_R`F$PsdbYfvopJ0nzVo*X+CbA_LS`GF-z51Qz3
zesH&v7BZ468Tx@v1KQUiI-R5HtV3wlJX}Al6e%wP5fPzBBLHrHFi{tq3>jM4!M0VgJ<*Zst>*Ce(oE=e{R7
zLXo*IJU%m4OOl8%paxRCEhr+C3Nc|T{fkMldia)0|Ar`tJEcbmcd$asBz%bVyO|*x
zyc+Yw=kWZhm6&yd9CF!~LlJPIk?qduD!~#9>uh8-ZciQ+E7L@PJUId|st!^l7_Nv2
z1Xs=OuN$EN%SiMe(G7w#Cl}>7pohi1LjEGw;pzU0B}p;RnAfPyzN2H#K@k9qk#O#S
zzG|+@R&+-st;%P1iQaCHO;BjR;~V0J?C;^F*w*3bCf@KoWGZCWaqG`GjKm{pGR{O(
z%|{ALmpP;~c;(}Z=(3V|EapZC7%drV$08<4gRt7pw7$Zsavqd_o$^K3b(t4#o>BEY
z`$lW@GXZftPdgf-Z&FcGQIp3W{1TT347}C
z$!{99ikb+9uEkDh@W`8+8+$r3af)z7De2E!e&Mu`Rg@X@
z7q{!*WB}$4av516VN~L*%*|PW2YRp!c*KFWZ;JgPXekJpvtj+Y&Imc|dmcao<)=1WJ1~HLh8LD;A!%u!=pHDg%$Qc)Dvfq0i%eBGjdeuB
zd4EevUGTdiScCxyMXEt)=6Ps4-4Y55s}|5w@c_wWJPbd4k!)1Pb84|s>28e#C%<&r+F~
z+2EtQe#nn9a+-nSWC>xbJ=)eIK4>W2P$iQH6soM8_c@`UXZ8H!Q)mIv2FZaW8sgle
zd@psYf}_erqE@TalElPWDTPVyJQ`7=5vl`Jz0Qm~QZAmQLp}?_AyJ+PyJ<(VcthPg
z(zYv}aJkUx;w^Z;uklk<9h+j*lGoD*B)Yb+lut)Uu_%an>B56~*}YA}rb3yahu6a7
zT!E{v(;qFV1OC2T+w~gvtnQlufyvgwL7u!RSWa;&u3hNe31GJFW!+n}ZJe}Rn=2`b
zIEqWL(K?8%xMg3}+FEzp>14%Eo?@`jJ7~HqXGf@pUL;5?Dzj67JE`r{9ZfJ8dh9%1a*N4aa#GB-te~Ig7BvY4Z>*c;bl8
zK!ga00+L~?-7?6OO?LNal&ruM-3Q`Yc=!cPeDOO7?u5=jeW9x}kkhhBP6QK`Lt*TL
zj}d^4#$=lm+xGX_2T}IpScoq3+?kSPvYVoko>EdQuXx`}G8`0zQ(-qPy*P?XSraLc
zM?0>qKl*kqr7oUY;cnrcrR2H9?jXL%)0hXNNI#>#&X|gl#V<=HdPCx9sVWGq0=Tw=k8eZS+OtTfwJWN;?TC+y#3c9=e+8lbZEQo|}_5Oh>CNeWvIIhmpSaUcyZ
zY1pCm!+Oo>ySJp+^KdVv!VtGFb#V`?C8u;j?k(WPZ1>m1G_bDc$RoBAO3mGLawkmg
zHsZWf@9^iK5x0ubz*T75CIx=q(q0i`BI({ZM!^(
zZR-c&UB~XOuc_l%z6ho?^kk@agtD@-YKn?mzI~2KLpwBs8_)C2r?)fm4;QMGHf-dl
zc!*xRLK0UXm1!&S^V{V4WbXEFl0{Sr<~(M@TU!JQ|))C^vjZ)tNO^K(mGigCNR
z5@v5M59J_?Mz#>F+y5EwIJgk@F}G!|HJ566d5FbDBpGQ>dIY7HV8gQiPAoij|2=Yp1`44)t=#xX`oE%R9BFsUW^DTAA
zBfU%^8QI{Li8pKF^>qbVU%4C
zZ$rqi1zPSQ6_3>7S3+G763XjGV9Y95R<>5{va>KrL5If*czIG{NV8z;ar_{d!>C&Q
za1$=^aIbpoZ7L?d1iU<>RHsI2{#Ch*w-Z4yHbe5Ajl+&5U_iQA_F%5Sqyf`lXbX)0WmE7-f+^sidR{Nw}Y)BtAl8
zsS}k`BApL)ozIFNTh}4zSGlNKr5E-fh~yzdiv!iXgA-`cLvD>wm~?rgnG1|4z*U34
z9An5_2dQ73dPdZYSC62j?NKvKvsfh*l)Cpn@QD~Gc?ycdEhiD;o6O&3_nyQp>)wvs
z`JcF;*G*%}!cb%cW(+ahk*P{(llhh50_n=~zlV^`d0i#+c^!Qro2JGd7`_ovNovaG
z&7Ossh86Yi=vdERnbp%xkt~|FzRao~i6BrBRrXESbk`1|7in==QR>Lymgt{}LQ$_{
z`WjbJpfBwAi+cfnQvD|^l>Bk_%-wWjyoX>33%#2iIE`7(_|3yrmK3%D}FV5Ne`Eh?ZRcVM{xck
z$j#ptG-vi*lGk+%IbB?mtH=n^=aQ?+g5UxaHCoq3=$g&dt?8&5I`#
z2#=blJgyS*#szb^DWemE*l~!7b-y>Ep>?v;^5!^|FWXe6&pTDYg@;#DvZ>AGb;l)k
zCCL2*E#4*;T?TU89mL6<>`Pheb*vt%RX2ii$)wsZ0}*hD&cZ^RV1o|@!nIwnYy(JI
zn$3eF`trWdfegiO%va9BLf$v#F&PihcuQQFQUT(Y?*Xh0teQ^7ol7I%)V_IDq33OC
z&kiTKHP^j8G^==o?V*9xSV)giKI`lzlvOq)H_}u(zH`sl6^?{&5jQui9!pDAL{gRa
z=JxprpaVvmO3kuFj1;m9ggy0w$})b!TDzZoldjg2+>kz)4u{*Mib1?ai^jHYU27*!
z@%Aq#355m+`~a0d`k`g5Q~O8Dx~$Y`w$F3UiA(0ty|#>iItxtkSSqF}Sy>8dr7^K>
z8gu!LR#zkoOj<6xs(&Q}5ZuFv2V(|f{yZg~fBvF>LKLM{d1X
zGw*0sPTQP2zHCJXwx^vFaXAvUy$ix9eN8#RER7C=AtmJ5+WGPmotZ;4tKd6j9O_kKwn@U?rKMsan=ohw=+6vdW@K$?5
zRe|*pMicvSD*D{H5-hCPn0#f?ONlb8dDxQC;xkMHT+^pM@i1fSwYpzg$qWt81EaLfaqcY+1(1l%
z+i&FgP}nveuL9zlbD#HAGkds+cot~bJ)n#mD)h}=?8cf@RHGVq(Y1^fOYeTV`|sTo
zXNw;0TQpTy#yz)MbK7%U8><=YLy
z>hp|97)#93<9qU3R*m}s=)9%nT#dn(@Pm8vD{X*oQihlj4wf}wH`(BND?I%BW@({y
z82S`D+RVj%Y)Xdr@=taYhxP;frBsIW_CHS4Qt&|czwQgQZ@i8Fb#byu?PMq0qU-Zw
zM}^nJIq^?wwB8H23zvIZ?#k{v&t^~~CiE|Y=5zUCT&;ryUVnD!YrUTw6Bw>UF?Dxo
zV3k>GSi?08cYurAk4xCAy1hek#`0aR0+D;g7y>LW>n}Di`4!A2>i()NHPW?vQMlGn
zK2IO@9UwlR=Mz|8g7$0%J%rAkIiB}Qi0w+7!jC2vZ`;qCl3h+JpkozcAXu8k*}1oR
zzf?F+6DRXqP@XB_pCBNhsVxV{^7iDRK-7-oV2n4rj3#TH?ZeLlh*nxWGv@#t+LUfj
zk$1Q}L(d4%7aP01f`P)sdz9
zLg{M0`8u=CF^@~+^t(TBG@_Cqk~x*pg3Lj7ws({%{Wprvb+Zk5tlE#?41GrWaFSz4
z64s>sWkx27n{(%g1h`7N;ki!@(w*-$;UJ%(3UR0o&!jMmX8fZ^#!i5JH!NpKxVCjh
zT;0?r(=Pp#+-XO}y~JQgj{yA3AEC1hnkQO4Hx+4YJ5}5j;i7Pb@q|P)Yx(W?_S;u%
zx4ScRm;#lW{tsNUFzxF~FGZ*}(qNM*bhYXq-kGYMPd~pcd}G||xsL!8`GydhCGa^#
zqsL%H8$sQ&*ju1qDusxxszFkXNnW%eZ*TYG_>_e&54P
z?VVoqJ2apE6A{(i^qZe-@*e=gd(F>IL)d~0`r)_0v
zTSKB5i*sE1qFs^nTnkYy3Ln%(>>*pU{cE*;G_D()q_h_B5L$
z*ANhHgi4dzD-Bmj{w=V
z`M?C|05hllkf@Pq&|qQ*RLd6iA=**MH
z!<%N=GvjsVPy|w%fDwEd8oMDZg=EOxYR_H4bhi&)wQkp-;!@`su;-QGjmNSixkX$}
zrprRdqG6M)6BGdClPnn8oqW%{AfY8H>~=x7VbIuPjQ+~=LDml4D+>`d;p7S=foEbA
z*PaT49~gA&Xu^W~z&6y{BD%2J4Bqa^{Qhrp?f0Ib`(1t8CW00jw9+a$&Jl9oJtYCn
zxNmftCep>cK=}=?;=OP4lX}ZF@CL!jG!P;)rxqlaRgUMqJ*0?+mTX1Ao|S2eh4{z1
z{ULc*qYOj!3W*vzvdPv|jAqe^gx
zO*NRO&dau*S3
zby=K^vH<6SZW_NJA(3{e5|gd8CO0Y>FB~cSaNzpu(Jf#(B(>ooGx$({uY5<1sSgOj
zH!R&|h6V3|W#F?<|ETJ8JUMIHn^Rw#D@IRaQ&by~BxY%iEvzJB>Ge8R$#W+vY1$B2
zL_0HG%!OJ4Ic!{7jTCZUeM=#yf`cbv2XIV)fUS3KTpCK8hK}SIhm>d&0
z7E;wTIRc@Qh=^wb_T+5*v^%WEXhj+xk4!ou`Sr9RrY@*Rr9SQ>nYFO0uu8j@vZ+eP
zZ0w>7XkE;2iJMH%Qr_nXsIf9qS&t-{F50m5-Y!^018w;kXN;cdOIYMUzO%_NIy^l{
z(7b>(Hj<|$#yggu^*qbvusRkia+4buV>IRzzZ=773xi&h3r75HJap)H?`jKPEG?=qdJ-E27*KgPc)7T
z*8(YF`EwbwOiBD_tl(Ls`B^2@d3{-9c_kKSL*C*^P1b49%k*YFpYc;)U}0PREO(Q1
zUFfTcB{-bAZC%-dUj0+U1sf!R<*vMS)4qhc9k=$vzjv`1e|~g
zv887F2#$HTEyKEN`5djju`bATodtWG04hKhAj~|)e)diD=Wiv|K$ivx>7tP~fHV-s
z5s%HokA?&Ag%sb%7JE|&pY3YbPP(=y<~YPEw4$F8(cQW)N}QfR_M!ur1Q-r(DE%Re
zo=g$JU8^FGGiN#MD6;(I-%N6B5x0!nRu;^~Zm~;w!X3sH{*5|DP#3n@Uj?~GvXh|H
zvl#Q1=P7tUzOd;j_y9N`^q?&_U`9jY6A-OdArjR=@t|@eK}bS^z3nbE_!F{WkHvtt
z7NzI12j)d{m^eghi(?mdQqi+gM%>nYi__~$enAsCM?zIHN7PXvSyU2OApn$6GlB#L
zA76UR$Otj}!oqzQ3?fOey*j;+=40g&}i#Qi@2lt630
zO98V?&8t_~s(bIXr4K(~g@8`=`x?MD_UmV(Pd~}}A9J|n4;;cH$w(lAbfgDhLOVYM
zKui=xuLFpy$zLHUs%|rfU|sgv$0nS6rWH`XQl(hy-K9&w5_JTzh*o^bZL*7wMxtZv0pd;Z#MEQK{(`Zoxzy)PEWk`34s(D!hh?t^imu$ke>3&B4gFF&aG(u8=~Fi7l(UG0E}~zkc=9oO<5Bt<
zTo($c2VIYzV&lL0O-uFesa!&X9K)ydh~GKgz*%rRVz7+PR{Lt)xWOu3e9>n9@sC!<
zK(I28*`fi%ZOY|WSn=3Vv`OlN^e<)Dyk@0seC8ROcl({*Mx?7XsLMk>-sY*WP3Se1
zm*}U+Ye2`LuTp%1*~$$tB{UwvqHuN4OhB42HLt>Fqs_)A@Lxkzq3yPXOf>I)pV3KVfyR
zz2S;l4O+^#rhi`>@~M-p=V6Cf0m>j%P)c8;X%-!7cIp@-t>VwZbGb|~d2BgY!s?!R
z-YOn{!j`--%ZljW3JG4Vj<&qi_B;Jd>vHr|%OAZD${Xbv9Zpen#fQ@2EURDL3(s2B
zt1nvZy9?dgoT{(2CbVdNSElG`?D?fwiRgsnK7fv}IuuDABlbF`o1}2lfQl69YRbL;
zQO8=@qyqts{pp11fa!$&P?8+M3W#DO?Hv5zwqV_Ep7j!d@d<0g8c|00^~A-3&bRU>k;$f0{a5{mM(W^z}C^g|BW2iY%WV
zDwhsYNy`G;0$?b>*RURoV!kXYk_8<|kv==gR99O*R#+r#Df#Cy@ZevrtN?(M8mx_7
z_SxG;oO&8cuis7rV!5EyTf_QQRx|Adn%l9aEk
zv5gCtSi`huY{>)nV?kPLKuSwf9t|k>Vf*c4y-qsQijSP)ph9)UMXNt#$IDfx=#Wph
ze!fTrzvSlCt8D$Wr)>3OPgwDqRX!cBDf)WyS$yCDHuBsvtZ2dnEQ45o7^sP+`%=?V*98%PSG%hD~41QNV^r%(8{F0Txug0BnbE;-gT{>xkjXwJ{E7(gQo*66#OcXYG
zr9IP*^e@yk$tzr|yeL4d_v>u_zyF6dzw$hFSC6Q>MMW?bjqwM_uwb+62{JZ1-S
zaHmUCw#5tx%X{^_rl_$Y`KbMSoqZu&n~w%&xU@mZ3u6RW)8NH(EO)K-|i}H=mi5
zUPqo_<;R>zo5ey*TdRNkQG5FdW;p@vvPu^majcE}?zb$bZ?B-op{AJv<=b12*oqIz
zQ5I_r_QYf}x}f&?=WWja{jc?)-mgy;SwpWOcGUNOL|q$=-eEA!fR4_F0XQy!&rG)^
z%%YT5;2s6v`Sdj!-?uw9%Y%Ux}NR{rlpN&2JH0!eW
zM4z7aX&i6LL9v
zCs^V5{W5@9x-)`KSg`Sd#5$3tQQ
z7NbHsU++cG39Z#NR=;YMZCJ1Xe`A0#*0V;GOAE@U?}Ytr$YFEub4+qa+Pl2`9Y
zm7lo7!9JQh
zH9&k50HFnoV?Uv-@
z>MV+jtv?p4+`+>vr$;X$Nl=QUAJ+&@i?Eu?O6bJxn;K3FX>U-{@BG)Wm&l_&H1qPp0GOf&~xjjfyQ^a(!&?y6^0*Z$X
zqa!Rs;v`0=r@AjcP)${8VPW$!EatOj*@77}sB`lzmqA4_^}I{(0oHrONb7<7PKr7!
zP_1cG7WYMtvQ|Al6kKiq68vkC+sB)4S|N49F_h|_IPgx23-XXdy{{B-
z<>N_sb|YFW#n9@p|Gt*$B_04~>a4l)IxB#qfmI>pfbVISF?$2zhWo$|!W1SlWkxAo
zvC-B(_K2-|db-(?CDzmZoGDLy!8Z^+4R}59{PV2n;6t(EvpzsB7g-fd+6ZDWi$JsW
z78Th6@h^U9Ew4Oh#qg4*OzKIunngzixE}3u&S!i;l-GA4^(6w@PEUE48whP(pj&yt
zI-F(=!Ip;}vsZ6rK*`{UlCpC2+sJQ!n|jj)eYC}zS1z}W_+u9$p91Pk+O4Nyup%I)
zIw7C;HBUa}Gg5LbX=N6v|H#o+IAR3W&OU%ejU>noatc%Lk}9)N_z>s!?`36Ln*rcK
zA;D(=z20HE3>-?sSpb`gnc}%-Hky|&vyHeJt(ozRtzWj(x=_!`(IH(14YTgl-=cwo
zafe{0P_wVpmsS}(Hm=7NX@k{NZm|;d=&+-YvBJIgu@+fX=e=zOl%Io8grIP
zLBH0|d)JoHR!abWzKB*j6`h>Iz~O++2O=uF=*NItGatG5z!x%DFB-WQZHU47+jFh%
z(T8jfIsU$13~tkKg;RW-O7gz!>w;HIt{ltbX3X#ag8<3nQMz~y3N{f
zACn7IJ@1F^KgmkQjRiR8(qD@XU|WNKtDj*cV-n53%}6
zmkOsn@(4IjViTY0AEa|ME2DK}x88cI-FDk;_WJ9uI|%;a4}WM=rcCjfKaZjI5h7=D
z7vsVBedfh3zW9&?6WHtjqiVd=Ad+IeCal`FOq$HL6ccSm7mzx()K
z$AB1LDW>mNKL#Lv<4u%tgZ07JsF7*(rA(W*0%i`n@FFWaInR#@sX9!mg2`2E`Ux7R{~AP
zt$gUO_@q8%U9b$70ceUyvp+zoJJW-ya;#u<)Gh{;sV|a1A887;7NAwv(u|*7xphUZ
zZV9JhOX*4p>oP=)WvB;OC>AWWxj+4>m2OyLHEPs!0He-2*9s3hn1v+61DMFjDvGOc
zfPow=v|)D#gsx{>m5PQE~
zvJh*EQXouLp5~PRVyy7*-gyVpnQN?^4y2Zjef+n-V?~D^L>Z8WOsD9nk{>$w^((FV
zoi}aOb1zxV>u+0E7HU=&7g`fm_X97x#KBQ6Rw3$kjaK{I3k)nD
zx9Vj}tOh^KLj0+_03`Y!Nj*7W60;H1F##(VfXYDmrXJ8YnqjT=@Re+>JwfAIH$M|7=Ro=-tcl;xv7W~WS|Ki`Rb><69L*qhIQeu_pzgqM|iUH`*
zgATQ_6Hc-sfK7^pV_Kl3_8KG!JpoK)DOZOSR>{^XEX24>ynN&J)&sp!!1MAcC)vpF
zd=~(RafZH01Igg)2_fkK9TA`50(#6?Ecy4Vtl{P7u--}4Hyna
zlK0+69&1HfoW@L-&r*mO?JNvHvFb9rQom-k?^05RUd{v5I`B|_UC&8w;!`XVmrL#7
zpj{d2nE{%4(+yUF>s~Pfj6w|n&;Kl-a~y4({>A|@`BJjmuYhy8Tr>fQYaf2d
zWL&JO_m<7tQJ8~||}vTIqlikZV10OFgignC&4C@p4ixA!-`W%(nRVZfTK
z0kqNxm_upm2(s`?@kPbWk$z>s>4Qb-ZU$&tx6(L!jxD_L7Hgv)tD}8a;ZiaA{Lfh_
zZlbAD*7sm+3VFz)9m~t}#%m4YrTcJI@pQb7cZ|tYPk-9J_{A^UamO7O
z8s>J2druJDc3Arm9;;Jiff%cYH%`MU@WeCLJm+n8hG@iha*{RTUp)I=EUN&`L(e?h
zEgkuTN4TX@3Pjcsq>p^t6^wMAPuFNV4aHD}#c1(ecbUC2hlP6iHuUhrZS8`0Y~^Y|
z3LX0x+$D;po{X|RfQBlNp~kFVP}~C5^)p|z4Np8~Yw?}ZP6kCvkLl#mXEMb)X@7t$
zK9*SRTIfv0iK{ijXnIz@@cw;-vr74OP}
z(x=nKs_E0e6@_-my8+w`Z4-dE0e`{$PCbQz(-iWuk1rgQh0R?a;J2-%-Znoo&DJrPXqh_)U!4Z4
zV}R6WukqIRcxFJDrp(1^@6({F7yN=BF3B=j@?8Qnqk>hcdBrl@{OBXL=GE6M#b7{-
zL+g9@#7cdL4W=FDu>#!yXR2Qgh_SRaEq>P;u
z3Kr(kzO@5J3)a1Qfc(2yTMAjMx&<&;)U&6JI`LF10b~}8po38-t+oV>sKmI4-v
zcJKheZ~Dt$Y}Nz!STAU+jJr*lYJ)%fXZ0@Z$
z+Qx;8tUv8%FxJNufVgh;Dw{iRo@=240X|)hM~@tEpz9~EUm0#gy9!^Clg_E>v8I7%mDQxDrJstkPJdQN0NX{pV5)a
z1OTt%z6Sxse|A7z$h)$s0Ad#Tq~vZB#mr=LI~SVSn*T5VY^^U$H})g3P5cfx{ZrQU
zB+3I>vX>OvB2yB)4IFXN`QbW6uT*A1KS_g25-AOGd3
z)_v-6_)<>{?pL_ggk;Hc4CY0J!Er14QlM2c7%4z%I2fc7!K;co2OY>)|1j~>)@rTl
zp-1fH>#t?a0=v|x{WEhn=HiR2U|*Fp)@T9ZP@o}x$G`BAW*{d(T=NKk__4>V6y2oW
zpoDrc;_`1=9#&c(6p5Dz5VuP&^fe)4sw*0>FhB(m*T3{KfcQ_=6+pbv0dYS7@fD%3
zD5VX$g&07LAwht6p#X7Z1>hOCk0GP%z{|g91*5U*muN6Z8_Lc{rmyRmA>F%#;1=Gt
z0>rmk8rQ>G#8-j);z0~ryW@tZ9e|8k-7s;ZQq}Lhj`yfD?-l(ccpq=GwvO2?`3zru
z_0_(p?!W^NwEz3R|FZ!D2KYj{kASsplKe;kvB2?LSXH#Z?l-^rjrC(%K;N*|t`pmA
z!V@KJ1LJFeACU#$dy76G)nv4E}5@l$N$>oaZPf<;zVTx#Q{
z9B;)~Pzv{%$c$>3>Jdfl4{UU*+V*B63VJys|7JRP))SpFdED&J|d)SG`Tdyg{LQm7_
zfGbAMtq!hGOq(}a#T~a=)pOHr?K-wuBb9xQU|R5m;{fCbxRP`0G=MyVJjjDOKXsJ8
z@3NYUkNQ!HS<1@QmNM+ThmPCd3(x?*_dGx>SqDI@{YC3vd&Mg5y~Ebeo@JW=u6>zO
z9dh^)fU{?<0>Dz;r@syV)EQQO^pTd=2bT)~QCgNjWRp2`DNvz~h-p3z$m*Ya7R&QP
z_Ab-(T9i0~&ate#k8Q@Cqo#&g1AOiJpK_e_I{rAO$(hy%5NlzN*GmV)E35%Py!g&L
zt&zG{&cLPu_k(?Y03bdRKs^RHG#U0KO=DK*-L%
zagvUVwTSf9`N=OcU0dnyK^vZ$W-D-mNCCK;u>SNKG28}DIS!xH+zXe1{Be7GUbVYP
zdxsvV`8{&~z<@Z2!)4-s1lnkS%`29&24T9*!|J?o-CFC5%gAU3B{^98>*vq2Sy=Fj
zk?GLkBdjMns|?pJ-}WmI;jaodw5tGIq3gNf4MJ$fLOk!PtE>eJaUr0k7c)lr?5NX>
ztJe~C7-#@I^*-bQbNc$jmE4wS=c!!?h||>Zc|X|=fY?Ep+M51_
z`jDdU)Q%`k@6NZSf4$FY7>ISjWv2y~o1v#M$Y6FOum2Ec!0;Vb-zgO)P^+v*vdux~
ztGs-FUI4Z%c`4Nwy;mF;n971fx8h@00b)pMSBwCNAAFyHIMj#0p!ic=i2(72byolK
zE87LcIk={!BnM`9b_XDa5suIfG*cQZ#Gh@weTILPgz|NEf>;@Eud)rJnQ4$G1Dq5IK~e&pY@o-}Ea3+gyhVP;4AT8d+Kp3#7a8|pQi3pPqnURo?~rTDqXKi
zepx^HzRI627ckp~rKu4g$~m{QO$^q;{?P09)HtQKF#E?TIE`$Zug;kdI{;CIN8Ol|hW5F}*|AJi9Z
zEw<{K-(y93$u>~OYM?&(%(Ja%3f980W3VW(s1Hl3?+q!1Dl4dGM9LQBN=M<{4;_Q*
zU|i<}O4<)8VgWiGA>GD#3+%Ojl7*OQ{5`@#jQ^mf39*oA#!2`9WmO5pK^xP0uDDVS!7#EO09&&bz{#x2U%h9!K%@UC0$#}d9f(F%CuJ~{KYjv
z%rto=+vrq2fQt-%h`9s%S^xbfuxP8?)<5tVmS?t910420d5ZNt@g%kh!`G1Q038rR
zM>7;!CEvgl`w}d~4GxI05aV*OLqM!ja!`zqEf%u+=VsVuEKZBwnFn}mwH^b9+K_WD
zveMJf#+P1JE0r#FY8eX)pPgo_SmC~T*;3pUSYXuyOZgdRTiG$kVbNtV9G0~(1ES25
zjzEaOG(=JY=bXb7vw#J4AIoh$tJW9aeWz97uA@A4LzX$?C)kL~{=sr_K}a!k<8>|r
zh^J>+h!LY(h<|2zqegq0lCjbV^^Us6wYCbw%#H8!A_g(jZOOyPef@gt3h0x6=1^wY
z3J*BIWh+1&*U(Ji$=bHd0WmxxS%Iv^ciy%Qcim+xUtyMr1*(094z#_`K9_di)9Plu
zVJ|)W2-bhx5*QSBn>y77UGh2KIVSkc#_dpT3ywAD63~WvT;-bCrcr>nnT2jSB}G;?
zX1Mh^g#51GY%3pUkue~*g;|dQ7y<^I#Wse023op|X?*gnp|=jrl*yksmudS}w)=9I
ziNE~GdazHrcCIL!dLkC$@3~u5ke^cD@v+MRG0A!Tf*%STrX^!tp(~l8PK6gxjcc(G&+Hr!@52I4EW`;Q
zMqD4#q53O8ymaYOd+@;r?fc*VzJI0o{PWMZuYL8aHU<|)eUxoaId(fB4h_0JyJ}mZ
zQHE!FFJEFgTI(lElD=Gb6$(!u?hq)BUfWMt_=n26lfouuX%2kn?bF}7gM
zX~25;>~;T#Ww*k{Vb$$>AUwU&KDBZ)b5VPEbUdqYn98yXFf`oiFQET#^^^rfC9vu?z+h~1BlnN
zuw}sB``PgGF0`84Z?W}Eb+2a-(#)<3hhKUri=Gbm!A4UKTj62dR7dKS$Fq&B(rkEz
z3r`C^<|`SnY{XqcUxVs(;QqcaE4QY_R^I&(izByK)6gL{-~<5iX{TBqA6qeY-S7oQ
z5DkEMWv~$6ewzd0t^nQ5Wj%12xB{1nBdEV|=cfXI5$6Ggt3eY=H-|-(O>^I}ihJ&~
zc~~Qg1YnEHZ1hE!S?>$J;6B>wI5luDCsUXn7o#pbea{iZJKX>
zuO#Fr3xDp`L7kI7sipvPXASDmcH$$gy(^aSkpM
zQ+Cc}A|~l%X?MuAjTxQ#S7+J$KV56Jix=X)!|V{N`}e>2G8X&wwb~b7wU-(26l~n&
zdz+UYeuRzv@}*%x607qw>j9!l<{*sL84eW)<-K~n&HDu|6Ej~zm*BrVu#fHa=`$#c
zv~6PNly&&RS5eG8`M|^IQ%+-%)?v744PZQ|uLxqDN0tE))9T&g836Gs0>rp#6;MaY
za61`=%R~-9I%?q&58FTO4nUmAxAYqSe0KxRzSUY?tu?Sk;4{C!#>zKUSU0&t4IE@+
zK6gHA7FcxLgWYOqV`?ax1=MVp)RgXZXdo#)mxmvAD{<2dQv8dt>L)xv2+0JR+EqfIXx6tUF1h3q|Mo;NKL5gVZupGF_Yt0V8z7FsYj)oJnE+1qL#|~`U&X?k
zZ+`Qe_6pPe!-fsB?|kPw4vghr5(D6Dn(?y^q&@++$WK0#ScsPah&N1s#R^xfwPqCk
zxNop`V~;Lug#UnTVRwZRI**dchuX-`UdUEgEbIX=s^?C#?U;A16ok~QMsV6CplRM*
zEL>08ELQ#2VL2Q#ZoIG5&tYZm+NYni1+!;cA#sM{JKXn=`U9C)*S1}ZVatVlMeaxdH6D8b<^TB0JOVVxYb9gbMQxgyP>;}i;#EF^u;66
z!~y`T*Vx*>{MjmBn8C-Fs#)QiveE1SAwXONIM30-CGt!LExl%y&HwMKu@Jv(wfL%O
zmyK}@4vMC-7*Jnu!=FzJW&EH62sUc*qRv-8$%uT>SiJ)YJqg$GvnYi35+VN?K#YaB
z2Mac;=tSg0ytf15BUval3O=IF#wmTkKPX-KRPWe_H~?Y?Z{n4XuYv8V*4}o#RW6uk
z8}M=&IAOAlxbSmU{{(wl;~KLJcYwz0m10c139QPjf7gdy|
zC4lD{Pe*`QzL>#6y#G&rhRgxPN-reHUkN-2UxPCT#LE_2BcSlzJ8!j0+6J~Ss|IjS
z{@(Z5%k^jg5Oqx?JSG=@&7Wvs@qq!c2uJkQ=CnV${D-Tbea_yw;RfRiBW$r&ZoOGE
zurKvXi+k(edfVpz^#QAA2CA4@teo-Vnc4c3l^%4U54;56v|qR971|-kAtAMG{nEI`
z%=^VJEsX`b0Uc0XUSbD*;X?eq`%|}{v)NBRh5J{l^(|w&F)ZyvE(9Rr51zw7+?z22
zJC&!`J1r8Eg%}^=S8n{Xb#JTM1u|WQLLX>c;hG2
zWkQC71~7oOS-bAK>wLYKwpr75yXTy9j=N2$zNt>?9QxW0BK?qWcMBlS2CiyR+0{qy
zwt63BSle-2d+oKp9fvH&ld+~~HKI0c&bUr|$imqplau_SMMUrZ=~^}+f8EMARI()+
zKC<8bN6Q=9pG87X*$OOmr2>Lu_F@zCQ`n>QXtwlWqjRQg)sYK;y491y(Nvi>=2z!j
z#U7N4-kxohDA2tQJTlTq*&B}
zq_FHrq3a7`)qlO)s-Jq;RxexPbOr!2yB>dvm7IKr;jrp)-M1Bs^2Xb4u?l^RgB>IE
z5rV!$3482R!1?jM#aWE*v{0&5KcyQu^7B^RAbjZ1`?%qT71%s+mc=j51Gr4g0uZ~)
z1Uzf&w!O8ej+Of#DImsLD899*uI`0rZ0Vn`v3j=e+R&QkfOyR3FSh14XIVA7CCpnm
z-(|b^p@&%c@vPRza@qul%S$ocj|7BC^`k_v7_p;gzD8{cvV$C{il?o0|8*C
z<0p$F0E3FEyEe&V%?ew1_dVt`$0WW&b9``e`Qf!z1NYjsP62YTT~a3)GUtjuAMWsOq=fO2U_s=PmdmD15ad;
z-U%ln(_#hz%h(y`DfG$XZjG%QG|;*qai9&+7aDu91tYS_>@5y$@g4@t_7A*aBqVvV4Peug7BCr4)m}r}2kBG%Rcc45y<(
zsmd%D7oyhcXqO2r#NC?!#MH%70Pz?s#BD69(+4#4d#_`s0kO)%3j>;77Vkxw_gR2g
zzVZ1C?Bu2-AKbTZyUXfcf6KbF3s4hZEG*e)tPMQ*I2MsjVCRTl$W3jZ+Q|%&)>tUt
znxWG_eSAgCs5ZxSL@dd`p`Sk%dk%=dg8p|}?0VL{=WvsmRM%SahBO_s)gOxr+J
zG2OTl>sloi!Uh(?>~+HN)_dwyI+x|PlC7bZyfxduh}UyCTT-2Kft4J49G!dEAKdR~lC^L+Usv6I}-d
z9j}OX*9Q1)72tW{Ijd&7um!kwas~kfOv!d*U*>**bFGHX?MY{+mBjL4Vp|)*bN6W#j~sZ~Nxk`@tM=>YAy49}
z>>Uc7R^xmC@ej84A>NY!v8MQIrn3j}|NIx*m94f-`9;3(<~RUx>#F5e`Sg?a246rd
zrmYPcKHPepaEg`V`)#b;PXUPK=NSO8I!rp(I(;E)nJr>-`*ncP5&=70BSwAo%eb)&
zuq`v5w|B0;(Tdpbw0Xcl>wUywHk=&*a`o|%B28aXuF%of*BlVfoN0@h`KV`?2?65G
z_z-9BGQkil5*hEQSVN6CKB$P=C2%(%?q1BQ)=Xg%P|5y7Qsg;mC
z7i{qFZRzxhd+oJXsP(O?ud4Ddy1)u<0H~9uI|9u@8%MvAUnXWh=mLoS+h8Ln4Y7j^
zp5t(^3**pPxom~)C6reZ7LztCGvR)HZRn@3wXBI#p$(CVjCO3>O+4sji*5a%pFRa3
zj?D|rh~V%x7Z{?=+IGPqUbxWqEL=c<`%25s%(QOjkF_2*+-M0SMlgV5l%Uvn4ax~d
zGMl4gqD%-7x43)_C=*=(G5zjGtP-)}x;!g{n;Z)p0q6%7yl(aD-m^AL#u+%b4JLbB
zDlt@5pD=yYu;LwC|0r4En&F)jV>NNuKpS<}U2H}M6McjPDB1u^3b;^E=km~#+F76&
zr@Br5`$xnfeiJHG$f_Af6Yu&0n@*gEJDRM5HmM+$d8mX;WXOoT^Us4LKf_XqX5p!#
z>05Q5_6tWT6EE63kH<8`WUHG#(}vuCzx!SUfSAE^n&YDa#A*hYGqeFM;Ex2xb{te4
zC9^rSaH;Jh>OkMp>fZ;=t8m=5_?yXGNMk$PAQ|!JiH@~AZ;^6(!6SK
zjSn7LXZ7Kc2QM}6)o7;y#L1(BC=)@ZJ)c3RY&FGm4>-hfs_R0TAoa}Ow2cov;!!3PcCEczFB_*Q6CXKcLUrLGKurH=o&N9uvFH;)PV
zr$7D4{_DT~%ih6sdgYZ@x`W+igsoA!)|hkC$<9C0x_|F4Xd~rF@4)o1;pacKQo_09
zGx<{c!X5kaKadDuG`zxh?Y;l_56r=bt&SAHsRM`FCvX`H+
zO~h)>tZM?y!wyU%^H}e`)^oymOB^|j^uE0<#6(s6(l!8?vdbxpT_Apr!Y?fmCyFEL
zA5@X=Bm@PB;Sm4R_qsUMWgpQHCk`A8_&&+P8ZE7sQ0;r2_
z5Iq8*zz>f*96qr7(n!@
zI%T3|*{K1saA54vOVtCyHe-$l@n5A4KZG{48b{N5G_*Nvcn3fUN}GlSq;L@6F?J6+
zTdf=bir7Z)OaQSWG{nUKu__a-Q_$*1-m>@;CK0+w72*80&wJHEY=}c#zvq=#S)b3|
zgm$(^(EcRsX<56$*8cPtmVwVgC9)>IcMltL=Uq7IjHx%Cqn2?r{?5CJd@~u~M-&Pi8uvfTI3U_U6Cl4nIo{5@bcSVLb)6|9jfcMj
zLwSr`WJshTpiHbnL!5(_+Y@uJff@)P4$11oO&=Y1YJ`&?9~B_h$kXFUn`_J>Z{y_1
z$tI+A<7V6X_!AZ(9(I^<5RWrxJe06*gkQ^%oEtodxYT)!J0*31a~+SCT=L(?ZXknI
zUOe*4-)Vwtw6OUI#tly{tr<^e0Epv=LmY%%`(QwgCAQ~kS1w>3ctUHJS;*SHa`>O%s
zt~cBDb*w?8A=c-+ckj06o_o%tPGrHqlsDp+zx-tn!dWo<(8;1geBAi<&?$
z64&Rqa<}WDH-TfFK!)%6{j(5dE8C`_ed{PA2?bvD@8O7)N!=BP8~iomRuYd?
zU|tKIQW}RzY1%?assn`m+P`#}W$}AyMv~>cqhR%g{Vk0QXx)bmvt+0jacHY>v!)Ey
z6W9=4FoH_@U#@oS5kQRSLPFm-Wg@B}4xH)$#5dkZ9O6l|LGg)zI40|2#Y*0t>G2l<
zVrh728v){%=h=o|{M53;IJLm*?KXM5^||75ziRz*IfTu##InOCy9q
zdFPL@!MA>nz9K#{4wpv(F;Nrt!Xb7*EXqWwhh3{x*tG}#$ucIv5kCU(R8=(`bzmWv
zbt2q=`FQhI+xGAy76&)F3O;KqAav|CfZ=H~Nfb;9Aj?rUIB7j25vz6z<*#;}p(Qb&gL~9vqZgu<1}8%Q~eB}PtMnwxFA
z_S)g!KVmItk@sWCA(*h8{i*9MZR!j*&cy3wjt1bLk{z4{@<3E59pSPv+X7{xgE+*k
zfahAGRgC+>7uk4E!)b~Tfh0tzdug7PzxtXT+_#gI>R}s%V_)9IS6CWUh!EMx;*b;C
zbjQ(G;rb?`OuS^P9)C2-Atnwn8e+vEjzin3_}ym$h|eSrvBuHSDNbYh{rPR3@{jIX
z($U+WXElR-D-_YAlSlZ_VQYMSu~pFS<I5lB)lCKgAC-HvZ)1`
zK>^0hC-JozwOD8<&zqNL4Gvw6ii!?LX}naeX@`#l5WhfLYyo0?S-7~zA-?C^T{OgM
zCXL$Ip_b4?hd$MVxxwZqTuIoqx8HFMu>kR5G{kLah&>MRsHjuj5kS1(YL>1bF~@9A
z%ux}SWGTe#Kj+)uL3vadSPz|E6TOBD0UGIOMR-lUw5j*{@r73_kd2BL-U1-rg|l%4
z3Rfei)}o-g;MO}V3;&EzCUL2WL#(<751x)c7$5G~D|3d=+Gt&l|J`5xy=3pvi=GUB
zz4g{x_Py_Y&ok1EVEieht~A6+D4b%-&7&pIlxHv(y8iy7c>R$8VpTMT`n}bTyV2us
zT)*vr!zx;YI47%E6cvVT)22;!HYtejxZ@7H{(1x^6I|yWDf=`na{P5p^Yc%}*R+*1
z5gmAGZvhaO0z$jvER@Lt+W)pYpeBs*RGtkly=aG)FSSxk&nfWe6gxQmQZ((O(A2U>
zdOL;*wT8(!0<~iI3(whsB`Yj(f2qY~Djnz5F5S6RvLe{CJRwgO1nEQ55U#e};`xo9ey*uf5nJ%keI7CkJ3
z1eD;yMdDsUK?f6`g*=cef#gw)W#<$NyyJ~8K)3qIIhKpb5NK-&W5(G)LQN$W7Lr~U
zhb07*obcrF9v1xrp55*RuUYk$EjT^ZTMCyFH6lz<|D^nU%Vv>Krly=hgDeSiztVPw
zi0LY`xhE!&FakJf-1))~R7*2BDwg#*HRgN8Azt$UPIVq-0vZM!;*p;T0CB(}mN~fV
z(M75p`8algBOjdn1?_Ui8e;AtLYs&yUiZoZ+w$*d=vYA72K2S=(@AlRCQpucEgLr2
z&Up)Ql3QyjfQ3Y;B}LaKxrVrP)oP-r%puA|
zsbz4D+O%{#`~C+kZQ?j7r@1u0_Jt{E?+9a}qm)Dt+jfyI`aLUsYlS7$RANS_o&_v~
zILalReF0ob5@QJbLh-0xz=q&Y&sZwgNTy9fqtCGcH(hI)7ZL@AUZgM%W-MH
zEYE(>Me4agi%b90_i|3v#!bHq*EZTd0?;=so=;G^P5^P7olO?byeqEZ-iw$wEY!Pk
zs#_`!@zXd2)>sDPDWPaM8PdMTST3S)%?tH$aIc+cVZ$u)9c2JY_}-;(`dctb#?!ai
zXN|xbGug7)c*W-`O|U>c2d3^|oC?-xoI0#wmUW>_-~hMgrQ<0RCkMp3IlpiJtEomw
ze4v!St*hU%vX`E*?P$j{3Deha$Z*TQ>KaSCcn0$lUjy1mQ?mmZ(?k@GL(p^f!xc})
z@vG0dW32nN*AYUIeinb*E6==(&M`?0%`rVX&=7C?@lT0E{04wH(E;&Acg6rQ=Smj6
zhjZmZ=s&N&M%?l?>kjBnIR~!tjklmNEvBD=joK{8LPnyAsuy1-^BRB{8iyhlXW)Q4
z=sWkpCx=$W=oBD3-4OudACQ=X?4kU)lE--@V937gifCdEq!n$YJ_!B>_vdd<@h52O
zpgHtf=d0;G`VQkma8_}t+fgLd;7Gdv-PJ_**hakeT5Dl`il&l|b~pp;Og8f&rC)!`
zQmCtb{oLv!D~+c_XQ*jv1(lMOvdrde{Zia);3Sf@!0Pz8_=grb(%v%?zoNh
z1bx@pMv<(YicR(Bu=uVw9-3ER8o@l1J*i8rb&EI2=BWpZu5ddN+
z6IgyW{y~X34%=bIM=P1?CVq!ZbvRafl!+)HR))`-CCdS#htS?eb$>KwfLBAKDubQ)zq5eaO6yLKK8<_$8R^VBk5R4#R{MC;S
z!d|hy&~NravwZg1XYB_+_<;jp#T@?P7r$u3*pxZ;P#bZ?&N=?IfB84~^N|5!-OH&O
zuWKU&zeB?l4f&#Tq-s~Pj)xz9*y9w>m@&hnPKb9R>V$sNwQL_AK3h+0!Q-!W;x9g7
zpK$MC7S9e$l3M{aWm`8{585Pc&=3Ie=PeayL?y;(A?@-$7TUdAH(NGgu#|nP`=_Bf
zpoNKNF_uv6#C#cPs6yMk-!?w>kR5(+113Yl@ZhOD{4N}G#!Yfjx0%NF_ryJ5heW4$$THKD6{5G@7jL2v5nhz6OyjdI_gLi(cX^uWwA*B
zjsc{54Jx)Qv{X28eTGVb`E>
zI3S*cQypbW`*q@>`;Q%7Aa7#NvCmKP{1*UX$@2)Cln9PDjjt`TozRj}Xurn3y{rd-
zxG&mECE#e^UuG4rudp4@y+~SCs5xvDdQBZ?{XTO8?ZF};E~3D&z$J@e^YZ1kclP7f
zuz#;Lpq1<;&gd<-k<_B6XLxHO?e@C={V$eLb*Z=q%#r#
zIshdB;_Y*uAf@bn0C9)aGFC@^iI8P*d}R)guy|-t#C5Ql<9<5pa3oqs#`r4%dZO3
z_yXA52p`x?raS>+C7j7(G$s`kTA%Ab8zk}2y)xhU!@Y7f>fUjH_}1GtTNS+R2Kpx@
zBh8Z00`{0R#d0T4amTTcl28By0zjH#U&cb_E>bPe(Px
z;*HBsKy46|qW;o9eFXVRALCHF*J_|AmAyXS_V1(bpoNTp3z`P?Ao;xWp`j!N?MS5}
zgy?Hoxg7cQlpWZ$8~KF8CSf6qZo&BxCtlZJdbz=7$w8Uso#q%93&SDaDnJYXcMUNc
zt#NmKi8RntnXk-!fUYQDO3?7;9JGIx<(5TTHTCXC!kKF=4@*D-SuS>K~l+kNT|Z
zBlgC71K_XrP)VIQP%8~{9bqQR;c?6Q&`cY|p{Y-c(&MB84nqOyhtec{#7IjVB4CUH
zAg??1KrYFvSQpTf7s?9Gxp5a
zdg*{z8^(Y`ya7v*0P!K_K{K1-Dc^a(QqWQ!0mR4-C84Upa=7z}*~q7IED3;dd=`3)
z80GPbJJ`f};mm2x7`I}&HBX3zNldg1e1M_
zDzEEnz5iPr9}7U-^~R-TQG+Tx$2Y$54O_BgiS>pX_azp^tJ!TA78Z8>`H|NeiavOc
zd=k9)I5hHcRr`dE*uZn@j7<<=b~k0
z!5~7wp5KseaoJ+)$pWn;7iWDLKn$J5L#SzF69cqafcTd`3IH(zG__Ap8}?}c@%iK7
z3HA>t6A0B{DhP_k0I~Ex0TkAfCxw_6>_F)7Gk}o;W=v}0`_*C!UBlv)g}{-9Pr`WU
z?PvmrllXvzSb(@w8qq*f;z>@b>y{es^$=$D?N*8Qb00hRPBh=*Aq(7TL#AXQ?a)Qi
zaN-;^ev)O5J`Zi)AmRJRHZ@limWWuszY*9H!z
zZo2Q|4>e%y@R7`$*mLajlRWKP?S{TCrwXl$d>GKX2(^kB=J4yJ_T5{0h4wI#e4PG04l+``oa>tId-rQ4s
zPdMU$TpttkwZKmWj-#uHKvIC_Fp&*Y;`tX^;mtR)n6nV#bQo6iS3oRi`>udk
z=5`%!cGpYIC+2_>pm^kr##Y<&;~!hY!j}kHN3;w;$p|v1Y+BR85U4#W4;5F^jfRH=h8Aqp6!knGk=NMOtU-UbW!)4Cb|3$5RM%
z-^%(|^5{cwr&p2vu+bvv88(*aDk&2HpZy0~gpISBOxN$Mt+aNcL6iWfO31L5!}$@$
zUJ;wJZkUnu5Uch5O4kQPn<*C#%8t#%EWjF#M7Do0C-~8cS03w
z-?ht1=g+sw9Gw3xPYQ65=mXRpGROCMiVVm{;!FZ7InAM65x^
zhNqd3n@L2X2xaG5DuB4pxbeujbJ1`rbEMjwQKM)qQst|~eKW|jw5mML91v^Fd~lly
z5Q}El@(O@>!9q)gjviT{itE^#MqLCSb!Mi$4U}&
z{2>6uhXLj-Xox2X5UbA>hgjp-ImG*kLbQwxIDojil1n3-*?@=HD7Db0%>u+n?m@2^
zkOIWIu#d)&RUligdEk4NKIQ^G(*5!~4P45XhFBK27$BA+fh{LVj-adPI>aN_W|@GZ
zTw80Lnwj(2nD{;f1yTbyI1sDSId}g9P93t&Y38affBho{fOX}ruk~IyOAlH4MSK1E
z&wp-DKowD3>jxiv(6O7c4+lpuhNEweJbfIn+Q$G8AKN%;=-5LMC)B8-PK+Ks+W9C-
z+Hoo_@yQzWWS<@BfluNK+NT2=MC<$S*}BL6U=?W7dojs#hXY1#z0Fe2C1Vp4v4g}M
zJD;3wr7PaDY_y@ROtk*jUT;0w%_hMcbs)=P(7p#A*9_ACL
zT2dj7IRX)Arb^Hd@4~#>i;3RA#2@y>uUhWSHw7AE=D*C8O>Zu@cYpqWEEOJCLqeQo
z6!a$B*=H>oK%5u_#GUcp^gH?7g1F_002M$Nkl}|nFzwJ2@t1Y%1&}Xe5{6;*3j)8bDXij`%3{azi;2a&#GQsV0&?1
zO$FGt^oKGr`6BDfW;1XgipS~cecSlk-&s7`$O_smrAMBf`}x~3Igcd+9iU6sZAZKO
z{<~KC+Cn?brnM8zQU1g!R)~o_b=28_61bNvMosUo1`t2!8sZ8TnfQVN8~a@VF&dQs
z5Ytbzfwa0Y4e>Tim~DXVEEW*-z$7=xu(ou18n79OHoBG(fyD?LwoWaiZD>?5%lBXm
z6r6juWsd|PLV*bZaCM$GUjp*VdRX!7Q?`nbYdvv5N@DR!VlgYa>87ZLSb&%Xi-ji$
zOBm}722!l6j;u$~5A-CBhrk2?UQt}aHO!fx{?r;45Sy8=>#*XCxa3mH0Td?<8G;r~
z8e--iZMWgsKf8%Li!s&8Vp-0-Y-LfFMyiAPCTNkud`aQnlW3E89(}s^urxGT$rHvx
zvlswZw3o;6bqfUJK86%D{(~{*v&omz01mSe0W_W-5GT=oQ3^@4ES0A@?7UMfL-Ijr
zLld^;q2F8Fu5DI}MaB9Q*adgofpaby)6lv_;xix^233q>)?3ow4W)Cx>
zXY-2?@uY3bX4?+%j@!P;s@X_IphAs=!jLg(GV>a(tz-pJdc+}K`S_zAJ3Wp2R8*2e
zc&u@3I13Jv#i<`UqUct=d8#I_#v5`jJ!M7~^tq?5L=+CTKxb
zI9)apqOYZFzcrB{CyoA$*I0u}mxSNN@QY_!3XZUe{fa1zo97Xhc&2RL`LizK!-_0`
zXQmBiakP?P$${`teR-8;=5F5_A0F
zQP&X1IK&g~ivr@zs8bzlK?fS*Dku}%!5BGEOqv;JjkKYx4lRsfMKB4gkyQtcJzfX1
zh%v}q)Uqf3`mO)#2bO()6cDSC1c*BUxvayAi@xg##UWm+Lad$fsxeChZfoTHc8x!^
zH+QLj+5zfXPA|f;+lEiekSngXi|+msn?2@)AKoj`*MGey)hl*%eXY+_BYj)PoSQp$
zu08(v-<|BU*ms}EX9lGJam)JmY!e!pLwomFPn-{X
z0SbG3`bH9PoP(9M3Bg!z2VZ{44lG<|@jFXMj1{)5@e{1~RhN-Dj>Hs9WR2q1jYNjP
z5$@2MRU~N$TmHa7Htg2hSu6-k)~%cI|_Uak?P7(D`(d%+R8#
zLjpgTfUb+;8Up8G!b{b>^rEeLVm9=Sc7!_-G0+AM{L-BO&O($~XonE?0>l2Gv;@jj
z6a#6*{h(OIR&HmpXe`}pEjxEvWakd6*|yc1Dr+&Lqa8p~k^1wZQ|e58nAbuDHSlu6WaJ+qYTSoHZ`VmC*?BG4Z5fL
z5IDzz6~bXIAr)_WqJt!222RX@!w1;Tg!Yg=bf_ib$t;amg!b0&1!^MFpf%T7)yvP?
zyH7u3*=&yD0d#5SkF`Pcky9qbnFkPS>`0T^RV#c#`^P?@-`xbrvu})Kny#$2UBCEu
zYbFkMJ7rY?bVpxvo#kFl8}=<=!$3RlBy8G}rD%u&#Bk#?)al$$IvYtjnu)#;p$**o
zzlD^@SZb=u%h`~0S{~ZT=iJi(^jf#rcr906OZ~D=Xt=$1}
zJb*aECIX04*>Gr%h5->FG@)_Gq%ews>bbM5_KhWkfGR@-g{=3GVU~aSRdAaD(BfJ*
zwFZFr(MK$wIpKg9r@F#>?=j02hnR72OgmDklN=ufAl79hC!(T|*RFkV(B#eHU+PzS
z$3uOBx!#>AeV*1?(=Hqf_wTpn9owyb<5uU~%OcT${1BBTf7nRNzxYy1A4f8e9?&Py
zjJCUWG$z-O#f%wk3gS)+h~epqL(FC-sFUh;@}mDKk@tO;ezriBY}k`@I74e|JC
zHt@cC0mRgWcGreEcBmVIcSk!!uh@cuK}ix6)ex`$0~%t+Wd+ua_WS}H2ZuOC9AW@5
z0u108M470Xk-$#?6ICimay=n8_nzE*XFvl<&4ZQHhO_LHCd#Fi~vW_fve
z9uVO(pZSdSg2S#uSWm~vaM{T|^B?~e|NPYf@yTvly9TBA>l%t9)&_t4;~!o9z5&yN
z!gh$9EeE?;%D9cY=BH(m{yYEhOyf4
zztx%{@*l#1N};dBzYU=g=>xdyjwVK?BWXHYFj?;S-G3u60fsnV^ki}Ei%Bt|JN#Kd
zv$$#UAm8=--`cLlONbqc=PbZx$QSOmd
z0O=E_TH!apMxFCjnlBcv9p<$(#fUWrHxU*J7wQsRlqIT!cJr=DLW@$p;!QiWVWUOx
z+U{VXujTUDMASG7-eD?{7!u$_%Ooy<-bov%;=%ORC%mF>Vt_agKwJwT4g-is-K4C3
zF%7YR!OWoF+Uj&E++SwUwGmT}2t
zl;e7P;U8;UyV^ElHAp$Q2PY#;|2_NIm~Y+dPDTlN065x63!eI@WB)z}#9Qagw$=kd
z9O5tlCbxJfG=emuShOh79_vnmC1Dy*%gwY5QcR~Y&JqE`iG|QA^1Cs%afswRIT321
zNdSy$6QfkB+9=j8!l~|=7cKEX8Ew#x=KDOdrIFT~`4$^fe4z2Kd9PPz1c*f+0oyk2Lf@^nN@TkIq
zNv}WPOxLCgUI}T4x1b@80peOLI^*wzLww044tUz=Z{dk}PL6|9-nwqJmA~?W?OeUu
zl1O))il(iAahiYK^>E$0BMUmLk}QjF1BiQIHAv+`8PjH35ui*?bpnHDfqh)O{I6t4@J_e(K?lv_ZJ;(37gf*Rm%Q@t0Bba~7Z*Ywp%9u;yJY7)#^t
zlT+Pr-!OUDH34E2BGqV!x3U4xMnO_bxyjvo+sJz#KmjrUIVP~m_1MJ42^g!5qwVZf
z;H|>g$wAf~6RDZTYmih*8e-xQGq!gK5EFK-4WQcyAU^Nr&spkamm&kWTj)I$!kNqu
zS-<>dbzii*4`N!LO|oZMWDfbpV)3)WIImRBpHB?orwL1iLr%{E_eAd{ZewVp)tp~|I(umMt2nB)GwvFp-->gTh
zX5A{Q2PEa?b+@963A;9(xTt`d2n#r~DG(Z68bcfQI0+gFU?hV61xp|w`6rryydV{9
zJ6hb@SLfOKMGGwpkdp$4%i_NKf9)T*C&dh<3_z|!R2QZajj^7^
zO_s9=&UP(ty>0vE!TUtB)QX8copjK7n8Ui?0>|{MVq})IWm?DtY=heQHGP2+Anr<;
zfK!Dg&pE^s1XuL!wWX2-
zCJv!5t%s6;v~GCM%J4>ShNpf2O`Jjip8xqfEty0uN-Zk~D0Qtg_&%;zzhhgUm}SkS
z%2WqPO3SpNm#`q$Cyq)
zfrT647%sP+FT8?wYLg{E!|5C}#0oCI)bb~xAp;6V5~7Ve
z+gJ!G`@mc>rV;s~p2eaX+Q+%Ke%A6Xo$2%&#dL1pAwawwK>TM*2DqgIUfO8q!S~z)
z-J^&Cb-$F&xK+&Oa6LR}w0!#*`wi0e0cbS#x)lv#Q**UtP6H6K8Bp7c#~jQeDyC9+
zI&vq`c03Ufvtb1J1x|HDnZP65ImAvO;Yz*`tJI(*B_WY)Xk{b3Y0g|9`}y>_=6M^k
zIl@LNEDaqCz0TG4QFA+i$|R{QHl+ywYJvOajt*;J;V(FU45^lHXRZta+~#gH6x8V@?W+R_MTcuA^l!@;IQ6^|FzjbfPQ~x;=K3PW`@5h-@r;e`wA;JfQA
z1rxV^6Db;q^Xw$+aW!$WnRA9Lh)`K+NcDq{1`rb(@%{IqzyXMb`UfSS9DG|hAV;4FqD;Wzwi-0T7v6fCWnOtXn)9F+il1Lcmc$G^YzA&b87mMrxG!%}K0`NqHf+rQcS^yxY0oZ}&L6>9BN
z6xZYL;p2eSJ{Evj4RbOutIwMOZR^&p^K^eJSFW_;;$pk&uDe`IoQG*HCaF$!{>Pz_
zbsrzv!60laVIf_yjJUzi!22z={JdN%#sru$bsA<=CcR_`U{4dWj-B^z07eUoNIg5*
z{^t;p0ls8nVLy*larm|6R!W$yBmki(6@9P28s{`ZW+6DF#gbX86DOY9mtO!7FShWm
zT>&5_o@%dauO?1$5eo{Fn#tO}bF0Cua50)UKsw6O8n
z;#f(LXu;qd8bUe;EfU(bdwEA!7F|u331pib8PE#1uHQfuhIzJc`4aA%WFFjGGa-tK
zzVc;wcITkw*1ZbU(#WimfpF3tseAy9C=>U8&+-nH9-&NpJOHtHzhq_Gwh3+7LOb;8
zeCPu0mT=xV&}ak(CqqNPsV<&=*XF7Gue|-kQEO@z9Y1GXi;bb2p^pDD4EMvTNx2T5&^_xKKuEASKhbK
zL9O;e3M18CDh=^lw&jW0)&wBV0T9;_xneX9HklI%Q$!XnIl>3Ai-Vq4yYngM)BXaz
z5jI^sEB;v!-&$iy69U1FQ&A^?xP{o=rC3hNm%agSkwv+8AIqC?kqtm&C`yL_G0Pw2
zDn4s$6w>9VJopX&JKGt1?eI5i%RM>BzLytTXva=#!mJt@R2XEco4|drVbI2^eMgA{
z;w=Kijc_};YJK4l8};B1EUp-;0S%+MAv3rSIbslZ96mss!iRnRHQTfHJxgqCU=u)c
zn#nV)4>6ZhaD?+kmiE_7kVeVJDebFy5F8r2e19B=xH}+0_i+p$_RR%yK=&6tI~etR
zAgv=j%*JJl?ftn=TVh4ECv;K&qbIi(_|F1T397uGAD!R+21*k0AdxwwEQL*MCghvY
z6B7fC~W>BaD<0mR8@$pIJw#GxvE9$TU}?=&|N~T~m87-lQR}!Fsw4K%CCnQib&|8JgS}0b<5sh`98f
zP94!ql68+3`22`BT+SMN(QUU|{xz3dd?srN
zW7YdkfY^by#sf3V?^E|1{hEIEm&_6U`&%Abiv@u7EPN$x@m8!oN~-qjUt=NWv%3j{
zdgq;YI$k@|x_%t6+Q%LctFe{-PpbIe{`R+a08{D|s1x_Gdsnb$#U|EqGC=IIg2DB7
zbub8JqHJbC-1pimRtoUS&C9W&@HbPZ14z(z1-HzkXMt-b)YyTi=UUl@_pJt6Nv`Q(mfXJxpdzymF?SEJz^_ela0D0}L#%1N%x4*zq=C*a)<4nEHsZ
z9G|Xw=zRSi0YaTzo2vnUGzmt+QDC5=wY*3}jY~g55+^2rSnHZKWEp$Z+N#Pehe1@A
zn{UNm{Gw&Zfr%K+0wCJ0t3>@%;R3^2a73AS2SA*!uxn^90}U}$1Ax#+q9JDE)5fN#
z4(h_@S&ut-tpseP4<2gg+5n!`t-JQK1awU
z;{AF`X71ZJHh_^fvKJnn^B8<&0pcd&KKHP5ZxJ9KXNmm^DGOjm6RI`a_j8>!Z$<&}
z0nZ{=pPg@`aEQqybdRC+RCD`~;92LX?bUw*)B$n=WatO}oyM0smp6PC2SDo#W8&Yt
zgXkE`Y!~1t3x}|JG-4TS0*8M7HZ((nN!P3N!J^s-ROuQYe5m(zXy|p~EY<-%G}DZ{PnHi)TSr
zsghxegy7V3E}%`W(zZ9izumQPF_9EXaA-%fMwE%Z@W8uGof2q?1-ey&k5ishmfA>%
ze@45bv5(Zm!md4M-Jw9}dIH3KZ;on+1&CuBVop^FM|4z*58cMmVLWz2cg#@yGtyA?=oFOd_OVSMVUZ8Np79ya6tUv_bvR^Vr!-y
z33?U<#FqhxQB*h}Rv|$vo)I9{Pjy6}11-DSF?y)O^x)7>oZ=%9c;u7d#E3Rk{=MWt
zqg!L@uoUfhicJ6wRf+N=hYiB;yS_+NkRq&Y`QG-y{81U2d%)r@9O8Ef)tLi@jxC7A
z5vij14jh|DDU!n(a)<>=(b6`&`l@sK^J({ZECuoBjj=&ryBnX7qUcl}F0bDuyc95a6@r}1_Goj8h8CUh(M<&XcA)mj)61gwYxjf1Q)<5}>C^5(O
zC-^Pa7R3rr>etuKzfXxdihUjhRG-+Ifeevsi5`08mJiy`+n&EJFH}#cQ;{ZR5!?zO
zo@)j*q=`1HM4@s44$65~1BkP*z(&Wa_ZaJ)m+w136(00mU?I^pfaJ_wZBG7HM+|4_
zSr6eeMFo>1-R#-3J;U(0apUYOU-^nhmQa}7Gd=!)K-{IJVh!EpBX4ZISEE;B>bdvc
zdp(O?ety1v2S9w)RaZH6;`nnv4h`G&K0egf48pb@+pKy1D|P@-T#6G*HjW=dnsbWC=VD8P*FQ71#$#UPz8=`d*%m#ILzYE2hZ1D*OHQ1LPoJ^Sv17oYTLNRwmdn@
zD!1&$Ndl0AbIc%|{qo`WCH3t~Qv{$!P70lRAVCzn)itjC<%;}e>PI91`CM<|zAE#a
z;wv9`d=AkpR#<&gy|ppf246JRvM;_I?d>?Uk>6bsVhJCv%mz{niLRIO8vq*f9(!0Pn3yN7894;2Aw}Rvo6(I_U
za{;L`m4^Wb;t;2f7iD4)YasV^CWr3(bcc9zfV?)GEbA66?E;9C0K`M0fVdxmUED<$
z3{3eABy>3Z>g$-0Ny5S=K!CXC6_=tRox**w_(M66Q;y;ERK8+~9eC+ACevXg^
z_I&Ge*%V97?r!C?=32v+?N&~RrtHyY*>GZDC-z6HNpt{da$y8}zqM`MV&$_Rvs%pR
z(h#Qtct+pM!l}q3{R+9BOoc)3w3i+ah|yfp_M_qdWfG-B^on3WFg`TA=`<}8!DfmN
zw4mq<9V*lp6kceI@lY&lEmR$V_~tj>u`Q3zA|O9bnrNaEiGw@*v($^lGl3{99t7Xd
z_tHM_kLo}XXp{kZwH0gvHrSR&2th{7>r6PSb%eMYaQ&6mW9Ae~?mv*Ku}DzYHk>)d
zA>Q~L9AdoOleu0i86D64=YL@y(>Bo|CK#ZNn~wMnIm{ByY5f{2dv&oLrr(p%Xm(KN
z?o%dMKWRMSAqR6({lK9=+`mc*4pB&=8sg&saR^Ol_H+R8O+=be5Pbl#9QAaMK@Ebw
zqSfJ(HWF6uRmRf`ws-wT##g8H>($>fN8;2tqzK-3Dk0+%d9b-wTRI@-PI%pcl_7}@
zcZ3aS1CB?fn{liIVCSOXNWyWm;I6M(;?NN^D%TN*SpBEl;L!p1`&h~Zndt-`
zx>*}wHZNxih&M+8aVz7nin^Xl^p-3#Hzvtk&%OER^l>FQs1Xw#ue>_x5o>fmM_m~}
zV*NH4>zvR3K$`I({VKE=luDb)iIH<7%ysWG%^5W2N*q!5%4@d%SHD8WMc~>7$(@GX
z%4T&W$u)3F4GIY=5KvwKWbmz(fFwxF5e393AmZ5Qd88k>;|jTm5TG)euctmd>JLhe
zM*3v+tS2nDw$YLSw(UdDvVor`GS3A#f3w-~$TG-MSJrAA)3zPlpmersL6-{h2|;<&
zwiB6z;^x4@g=l?itg%;b>pp3+^}UvOYza-?tL^65qeK
zT?o$btfC$#9Wc)IV(l5*)TwdArT2NECQ`L@t9n*nMMNj6At}@r+com*rC3+quO
z8sZCXyTfv>xq{6b4xK4#C!Hpk%ftIm>z040zjUdz^ugQ>F_!<@fVeBZIwD_HFYZ&m
zUu9UIfApgtc_I!0;Ct@5$F98cO4kl|J=bsM1O9X^`vZRVk$&~D))2=UDAw=_!8T{k
z9OtN9bkRlj^{;>3rcRye16EuXAGi$Czw1MTaK~2H5Fc9bs+E=>vMeYQgD<-R4sig8
zrB2eEByO5r;R+9VC^acbCu#S
zx?_e!4vUmBz8!k$CEG(n2W;fXTL3Wwz88}^alpXn;>#k`O1L+)V_P17*vePEPq;VE
zMWAI8(x-rsNEyVFmA1*dNJ11@fTf7KN~FaAri&Ql4)6WJ_c$qqs}EZZ=KI~xzhEKE
z^vx{XO=yG8{q$!n2lJ+!a6&9Na)6LF)Gq>{7TooR3okzATWNABm4Esh2vi5e;y)?{
zFo1aDFMn$Fdv_8ewbdHYQVzwGm@_Hhn8x7@;a2=9gUnaV@}T%dA;}V3&p%4aYh6qUjjWAI%gXwUY&-mC!-}sYCNg
z^GbAsc$`?0aH3S?k-YJf=|?%Ep=DRO{9a+f_C520?R()xoW^Msa6H-j
z_*`fel@X^RLCbp&qPg)UKRW##|9Knohs7iS
zRP>h2nT%&;GTZvl!xmSv%j(clCZ?ua5u28*%gE*^=Q=sNsLZH_^@DmsSN2f=1*MHd
zIZY(nSo{2QmPiIM#VDx7;&S%azijE}jdp%!m~j~*T1NZMokXEnX6pgO32<@QiU5d5
z0EmBxrKiwu%YiV{BN(y7OqOFPshitMwp+!kBv_gIXUpQcRcIeG&lzc>zw{MP&e55Q
zxtGN=SU`0vs-sHLfvnWr0QkvSuaXc+@4lo=b$ADGt(<8ytnZCcK#Zn22t!91!O6jl
zqHn?tb$0lvC#@1oRefcZHMWLr*f|$i&LvZbi+mOoCb-y|;I7V7KgekOINh1!iC=(|DV$DfF
z9ONprDrD0uw|4q_`|QW894FdLK$KGF4!Mb>G})1MWztH+!d!^-0o$T?EJ7r;DeUAZR-JV7gx8tjZXic7E3Q*gE^I8dOL_N-I
zX>3MY`VFu?IGy&m7(bToL`{+fOfp2;=`!LFJ0PBG+04I6Hus?c1$N=Lza1zq91x2*
zMVoRB2g64=)m%I(8@y}OwrV3i>jM&PM4&;nY~Er!0mOzgV>7?6l7<+{M9wuh&a!@m
ziJ%kQiB_rLI->iynnuM?WFWtE$29BT7!a!tU2$1uWu+%kd-Tyq-Kp+^3oh`u!)Kj!
z)(KI=bnXWov2s7?Hy`zP9~(d%42s}(qjUe5hL@ID=>Qeq?mz$YKfSTA)5E;wEqypmexEu^a{>fGB|$=Kvxgq
zXg7|8>o`#`bl>gMUSYViiXFM-
zq2Ce1b3cwBiZU@?l!-yyvve9~a8TdV9s;f`Y^{Lr01(e{KwJeN%@{n$&b|jg+`rIGf1qLh
zqcK?xg+?0UH&>yJ=mg|Xwt`Q=KPPT)TmsYzIK;kavO@?1P-<~7+<`f)y$a1I+Km2a
z)VdW7wu5l~T3F2DM~t$8x7-8;hcJCg?Tm(5%d>0L7_04AGb)~Z(yCXzZ3oeUrouNK
z0lg<>D)b)4n#ZT*UbToQ(n;$YG`COUR9B`b6P*BJG{g>wC$pHTt?65SE0_~3hx+Wq
z!#`EId=-E}HK-ocjy~-G?3a^G>CoG6SshVDQW<{libos6}1
z*AOqa&CfqelnG*L(_YPm!|ZG*6G_EIUiUDcX($JJLB<$;9*Xu&!|O|I&2N4~_`z1R
zTR0;PEVOel$0iRa!AL&Q6BzHlfC7fq2I?0bYCCD7Iz?BYk1JCah-pV#21GRWk!dD|!PPtb~3AzTo?2*U_xb
zR{82bdWGLBkx5uiUfZ|X`bQqM){;G>V`n_$jN9+p>n&$8R+av=1EH|o|G@j5aS0&a
z_T#{*u7$DgfY>P$aEJ-3rLb#ivDnC<3H^GZ7Q%AX)>$c;(e^J{Vv${2EeQ}bX!0aB
zb6Hluo%F|Bw^=K3i8H5OVngmHIRumm(XL`#Y)U%iq4>N4#1SYHZOAf3Ef{?j&W>FH
zanJ>{1Dz`Q=8sbr$rsTR{3iT1)O3DG^R4eC&*&JxUx6}(?Q(g>{P8fB^qtpVBLEPJ
zj@{RVniuEWy5Ilaa=Aa^tymtkhjZ__7vKnYHw)?uzjScNvy>n{>j+DyY>#!XyzGED
z3m+eC1!Gvqclx+4|Zj2Prt1x|Z!K8~8LY2*90=ed`x@vV0(9e;)9+&s$}dx7=+
z4D`J|{h$>W|I^RtyJNfae_GIoeO|0uvFBL%ia4PxC~~kn
zAMKXB7;n7sM$07Ykh~pZ3svm*e|OIa1Z9@1d79Y4t8r|qZ?f)v``Ex6Nq{l>e9w8#
zs>^M&kRvEMTj5oe?Xx}4{K+aY6Q{t(PDlHdH)M!4l8J0rWrZa&c+bA+vzBuHSPNm&
zj=0G?SiBM#{NfPTBREO{#7*zL5C5+nKz#wUiRqSpE@66-Wonmpmg`}*YT3QZDqeoo
zsuwLH?iOZx1am&&%X&_oYH2J!0>yH~(?SzMK)Ln-K|uGR$dPsufWbK~aN6O>Zes(m
z91ZCFS3P~L1aKoJy+PN1%5o=-Cvil7WN#|#tW3KI4$9F|q2)sh0(U~4;WM(hONL3P
zYMcaotw4auRP1KeUBrfEf!~V8tPOK|uDH~N#a8sCf3y^UjnouzTGRn03hfpEVihZ}
z!e#|P{4N~g?f~Lye%l5h9(6MryT(nhq(X!&ZTq1e66|QOTjapEXoYQ_4IpMgsYVE8
z4jyc0WBOCLyATdUF+g0qe1Ywm_qsK&-N3EHTTe9iy{`KdoH?{YA^MOg6TZ&UfGWFb
z@gggIX0BCi*=#LnJbR-Z?orUks<&@~MnSZI3oo)hx5LkqCK}+PPE^)EX^EMQt_7`o
z=FfKc?G<*Av6e!d*t0GnrtzgSiP|xe7`@U~(ya84hyGhb9AW@*lK?U8S(}4)mG(?S
zJ1++pr()261XJ^cL+75+LBIP?d3KOV>hreE>un#Fj|w(i5i
zLj_V{q|iQCZ`z38+yaMj8({Z;)ocUaSap*Hftf3f7^LBVzDV>OUAdK%kmfe>vg
zlXuhd6}BGbKtefL*!W#WL0>!Tx*I$+UP9jiG?L_@>Kg;ZDnm6#7bVSYGa2RBYzBaM
zp5+VG0(^3(k|5*8>jO<8n@k79UJ7SwUNSCR`$fctT~9rO1!|3TFt?fk{|ZrFNR8SBtoaHDHvyTgvu0ZZTD0uy8f(U)kv?{e^}Xz3OFw4}
z6fRPH3&?2RQeqfClI>jpaTVJA32^+Cm?M;xY3*2HxT^owe=i3h>YYdx1j3u3@f^TO
zxNiAE`mND&`t-JxZnN54RHuS?Ds&s1fY_)r#O@aant{L(86yo
zaX$+O#8+Nr88hJ!i!yP`aP``Y>kNyH2Vo!`}EN7
z)K2PnZF;mB(ZPJynW97ayxzUt%AiB-ef~v{)>D(2Z@n*?V8g!tkMtWdnTL&5{DyhfM^6T%
z%~i0Ts`f_!aqJ$BJgcu__eagRuMXDN78E#JXX8|d18f^#*CG?f-u5{F@pXiF#5Rk=
zZE%)mX4f)~6wHgG8nqe8|UI=JF0Aecli7PbS;z-IIeB)uO(F7OIAwTHqo~E
z-SVwq!c@z?`UW(7#lgbjyLH-D;3g{cCCsE5Xy3fUR)6;a2gEf1l6HW>$eV6~LkwrO
zXdw420sA2xYHPxLwYXDV3=lT}hyx9=C=&_&3SAQ+6JBRawN;QgZP&{S7zaBY5O=@y
zQtNZW)o|tj#At^d5OZHTl(xHtRJ_%%y(QFws0xii8!893ZBanHjMTBvD-!B!Si}Lug+~Fg
zt|MnCHBi7I3~n}FPI+kgT2@1UnfphpSchX9z%myebP>*_X@I#PD`KGCRyi?1t=GJ9
zK&-Hfvc6Q!deqjw^s?mv9EG5Br%tne;t(Iv5OY1w@qYpnYwNMJ)+Pdm5u
z>1D&Pj8Kr&}sW<}p7bu-Zy1ngWh
z7wj&)2~YM%fOzBgzi*K@mk@3)-s%yXl$q
zME%FyFnF+{t+Zn?i$}>3l7xq0;7)?yDoFkd0t9lLi%LrhOC{a`0t57B$djyVrGu(H?t0)t^zcI#VtsEw38NVJgR!b*G8U819>sfrBXV3}0cGJ)S460b
zoBwDJ(YNYfe$fsuTViDgN>Q{VTCV{Et^4%pmJLQwnr_ueY1u=J1ujgKB`j;2e{9Aw
zu%uSt93Ia(7vA$NWc2_5E0zi9XYR}5@&*7-8)yt3bHp0SKlITZ1;l8G0mR#8&-F}o
zEmXP|4)NIAKX18M$s7>to^%R_kB#8vN&W`cjQ#c`KRE8AXrZd_|KKYN
zJKeD=wrx+n-^~1}zxUL+2Yc_k_OqZsMm*!dEOWR}tadfcBKezgn?u`R*+-=0LG+rH
zG)TKE!P-4~W^2d!Fjy6#;IVbo-RDsYmw@^aXc+aSn}5781x&amY(bg^aKr*cKT5{o
z9VJnITn21=LO4L{WJ|C~;xWsH0Y&ew&C|vZ?!WVTmyukw=F{(IWiYuRL8U{GR|cg=
zm`-8yL#xKg!dfK|Il~H=nlCo(YAow@=2jmhRCT3%Q`CMAiyZl|!%PUkGV4z{RrXZQ
zbIkZoHtxtDKN4BOh6KUxFW?P?gUI}9yxaa8p~p5a$1{ItJ(I2;GtujehKLMvDuEet
z74XLdME=f8EM18AY+e>@mS`~}qE38r1d+IcAai{3+7D}TSU?DjLVzot6j*p+ArYdp
z8wzuULEbl8at;s2jM@^KdV)|!!>vJ$&k&GOrVz_GK_U)?6Lt-eGA&WxG3p45kw1<_
zg|79&G9~N-og6mm_ru>E0MR9E(-g{kvfu7o(An1h45vT8efiw1
zto;h}-V5YZB9}ImWoXVv;Hx3f9MJ;wqkhq3X1O-we|G$u?6BP$ZzTJ2)=PX-fMlw}
zE`rmgU|MNFQ{Xl2L3dP+s?gA$2kf>WW^*t6Mtc=nL{?Vj!Dt9vfJ6{Q1cnViu(tz4
zwIa9^A;P0V*DbBW!+t#chMR_bp3?T)W@D`?#C%+?S+99jAFQJ%v4;6r#h>1Qys>Y}
z$0KW+aGMNU(Gaf?U6m?V78^`nP8Fxu6a83Pi(Av_7ZcF2xWslYl@}MqFOln~#tK(5
z>=X}SF0dqTof6{J)
zA&=>@8=b-sL%jsgS=-EuCK^qpVjyu8jVDPSgU#Tk7&083pX3+wJVd}pq>T>&!hkgFN!lz>;5bjCTt<`TDRXWwCNWuV8?Z<VMq#;-Zqv7ZG$Fbo0
z5R#zndYc0$N=Hhy=s>=B4p+|3Td~_b^P_oVOLx~iBHx3q&050=-DaRxRkq16G3gT*sS7}@`?tW!g19Ve4$YS%UORIdAyB>Lu`RUG$~wZFsSsu<
zNr+OI=dEq-NrbAAxFIKpHN4-uwi|pvoWKE9Fw{blp2-n?@uEI*WqEt@7X}2#NlsQA
z0qqU20#-kL=8ctw_=tC$QQ1WT+7q#-$m_ae!DV4}rpfU0OLYT5ZizunruX@Z*B~*N
zKxU7Z2oG|X*SwKF2cko0(h#(OC{2vNez%KOsZPv@q82grT;<5b!f*LOla+#6QrJS5
zwr04qOxIw@M2X93+c84#se__=D=<+F0LDOeg&pkx&ttTvx!-7E>F2;Uona3`V!T~4
zB3`gz9c;7P71|bFS^Q5zB}N}(Wsg~`Y`+VXOHPH|KEHr5K7c-XvK6uWQ*4Rst_BBq
zbpBSplPvv-9d{5=-sLYOfyCt$;B`CeTMbGESbLxj)?CO%Jr54sfFLgpz0FEq|NADN
zZn>sf+8967Aj!HR0|9kQv)@9pH&4=RRI~1`MSHYKz$jobOh8Il%{4r9c|o+JruoDC
z&u?pPxaO|Tr4s}v)80U#thKiz-d1o#Xa44l4>Ldx!fgQW)u@^eO1fAxS)b~6)nzbl
z$du>4czpoXh0ap8Hpt#_4PLjTKCQ(Y+c^@k0xl0e1Tj61OA?faJ?XtTtO&rvwiUq=
zM)y{BTx1^*pXM;scSk;zUOpS_r5EsS22QMfv7)Nz`3VZYIHalqZw7Wj%4O|#!ASmR
zdY`bbBgba(XIQ9Qx-EAav%*f9F2jf7waXC~?wTToK#kHMt9Qt
zaxYywgPjELS>;z;+hj5p$#hn^7CBe+a=aLMPc0&HsrN-Q#XtExk1xTl5wn*=tTf_$9{-1)e7HdLDpRNd{gt+
zv|=-WASG;Plc9;+pG*XNGL+EPN7VYg+CDY5kSbyrDd$E^#Sv`zsH~)W32=Uq!Rpvd7=>1pXiTh%AXN3_u2e0%aHU5G8i#KMh1~Zi^u>6}x^%N#
zcVn#xba?hj0yKP~CD!uZROsZ
zsavY6mVHiZ1u#oS3;0*t;or#S<3vNniGy&Pe!Ve9(W;y=GVuRd07L;?uxGL$;Y--J
zKZHJ`a(Xi?wkn?c3ZU6)A)B|_LOf&E;bC^;
zyV$tlzd#hx(COO!ddsfwzSKA%JZ^
zU+wPPQ2Y1`l{Y+o66z!Rg(h$s8hyZf+Em$ek_pL&hUs-*3#9n4=4a^jt{0;gdp~Kc
zz5xroGz)&uUe{GKkje*o2`YphygDcH2N|8%o_zWrz@z4)MO=w-3*^~V3-xF&m$gir
zVM7aago_1iB7QS;N3D8T43=l5KLxe-9HB~NLDwH7Udw6xd>#~Ac6zGe>hoQj=Z~?1hSa&9~6Aj)E5w?i8K@-OM
zA)-#zQV9-yu`^50ORx0~qui7u5@c2Np>N;hieYRMcRU+ib&^ehs=`*T0I58fn1
zMb;Fea0YP`8vIB3^;eR)T&B=A#AkH`u@F9pMD55=^5z40b=M6WzH-8b{c+jrw*0=}
zbaY{I6}NGKOsn?V-JwQHjuycDa2e*gCrCcMTwHsWf~D)x^(-cl%~N~2>@9Lg!_aLN
z01_PiV^kgv(6P0AS&g#n4To4M9^yFxeo$_RhqrHYaFf=V
zJ;N%4T009;%|{44_W%w4tY?Z*LzLLuHLX7?r|(LfBO^-}rDAUutklN5#U!QCxB)xC
zyw}amIBA^}v&Ymc_wU7K-@
z6&N%nVc>j5Zv$CnU_;Jo$<=36>o#E>%kzT#<|K5+R-KGRe@~nAMr~OFv{qz=B;X(_
z^=+hc2V18T<3pUZL|784L`&r<0n^;$+}w$kGlfXVjv(Py$dxrG7*3Y6q;A2eK5o4=
z*^f+4;pYW%^(autNaT~j^Q2=|{PCe$_bl!&^tqmS#-q0B_h=*XqmirO4zr*>`e)-e
z%RdfdYEWPBs}S~ig1FPiLwN}0YmbBoo;Sea?L=!^L~#;*#)to;Yp|_CDdq_4DE0Ax=an90WiO~gniA#hEy2liQEslzZ-NL5$AgNKf%8}f29hkP!s
z+t*H@8;6Sksg8cfF!75f_;Nnm@*zd4;mx<8!hXuzRfDjK%W
zV+#F!6Jz7(i8V;wFSBc7Dr1$Q`Cku`o>ooc*1E2HZA@WLON?gEu)Tz2YU;K-aC*)s
z@*Y+;JoY0GTdyR)>&%zc0VL&M9YZi}58r&2Bp|==ML2(ruGGjtoRC~UP$d4s&-`w*
z^Y>tf7YW07xRi|^rB3yKETfy=!-+H10Xu3WRTW`1OonZaicx}1j2oHvl+2Vq$eQcIc1){e+OARxzgRlFaoE~>d
zGZ@2Jt9`?!-0H9C)k`gO73~WZ_O*^*(9c@~?E34Hugd7IS!<3|KHg=#8D17;S|
zsZj!2SUW3|E!*QQ?>ur$!~p0C5jm;~rp#yXi!%>;t?<$`
z^wH)qkYJaYbqCYAIk3<|@+
zoG}wof6D}wuJ#W|SCGW?VucP%oe#MDYi?Re@Vq?4L&zd}udcVTjVc8M
z#JY-aJ>R3#)Cke4c<)EC?bXjw8Cuc;sq&6x6_62FkU&qiqezLLcB$D=>)PX&-=;u<
z{sm2B&$byT7%Z7_7znJfp
a_JUiLojtzNx=I
z{b*0#r*`+MWl@F7zZOMfBHv-79QI^c{K2zmCDe8YIW^yP|YA(1&-z$cilFnx9oLj+A5Jn@nGi3#6q;H80+}zmRg_(!CC!&!7-bzx!|sF
zg?SEoZiHdp*JYnd0w?63BRB>4@`ph@^Fw=LE8v*eK(x!U>Ku+&>dJuB{xDOBwP4aKI<}6fZH7Pi8#Q?Q^cKR@SLZT;gQdmo#oA$8?*fwS?+*
zT<&>OJEkw#&&_Bo>_w%RxZ_rqnMl8EMbbCb&{R#k6bb@G5O~tZ^;s&|OL|ZK7wIEq
z$mOlj1rsi4j*MaOLM@KVzqF_sM!=wd?s`+a$Kk(`&2x}597(oH3MBdhWQ%NpcL1-h>=
zRdX!de!rQl_YN0rh{k%AcIwfrn1hPBz43M+8Fw!JO83*6JfEvF)hk5Ht!vlD5Q$ds
zE-+zija+kw|j3KrSXT3`gqC*nU1jXJT{IFC}b3f|~
zQ;TkI&r=JTzPG$x#n$AF#mfHmFDD*|bx_Lt>^}i|_{HIvzZw#=$UtZph?hTuPj1o#
zL%QmcMLtfF-fjl1jY(fS9mZEsx9fYLEH2bl)SJ<}PHw}7M0{Uuj~p15ac1MfQn1|5
zi>T0s{z>{X%dJXVXwjO7{sJ$3b1-z=OFN)Pq<&LImV;g(QUz1z1Un;{Dx<v*@70fh=a2^HjQ)9xDyZ2wAM2_6
zFF)D#>%FLC}WptC99UtuK+V<$_zTKH!YTu6AUGMJ_mlbi%
zM`N3A-K^}U?Bw3E51
zggY}kl@NIyoe2ix9kQ@$u&{R86aendht84s$)eZvn3e?7L%0xsT8&sgcY-s(F=Hj^
z{2Mh8zG1~->&(qW!<;Ce`*gSz_7qFq7;}p*d2@8RSJu&hAFcE!>>52Y-q6_}qQR@H
zi}78DcxNd?-$gN{oJ`XT1rdJgUwiv?I*k1@Lys)v#i~Q@<9;w|5Sw~y=49>Ukurq8
zmkOR4j#*&16d4|>U7Rik0kMgS!)hTtgMN0bi0x@Q`!~+
zn}>Y|mcFgRMa$bnOC5X{n=YP)RrQz%Lkxk}HTTUtZBpWN=f2{Hb5u#V%hSo;v8z=^
zr1|KGN~lKsQjEL{X^CYu6;=dFqex?fNw5!EhIG@u=8?^SN?D9~ssegb2v5gqfl=TP
zV*a)k2PU(TCHIxrz{)5Itt6#}8E$iDhZ#w}E>6XO3tRnIO=YZ)95zXb=VB(0woqiq
zG?EIknBuR=Wb)M?MjCJkIRg_s&f_DhZkLto*;(J18j0KYBJ^2M1cuF{zp}#Sk~oy0
z#~bTVH0s}o%4y+jR%jWmR3}Y&?1XqnZwt`uwS1PB8iGk5FouXT0Yap|yMdOKyK8Gr
zgV-$uxpiNFl~DD?2JtU$g~~Dj&eXex#R(S{`E5eI=hcEUV=|;6%b4)I9seo|y#AT^2EmQVF*9)ZG&!oY~Yo9iBZO48VKI>`<-2DU1>cfo$m5ntr
z)6}Oq9qI(61yzz&TQE*+K;b}OY|)!l
z21|=IT{X^{2ndYD<)s?5Vl#NSqt~5TbEfG0)%L5-NK9}bOTy`YKQu5s`wX`)07i{N=Eo9Ra|D&Ao+Hdy55<$G2Nt2r=Q!teQl
zGTw8)1IMr{AdiHFTf1*NKaYqLsK$Vr`+<{yV)hV(&Sn&E0oRR
zW|g;Bn#AfO7S~!n6USzyD=TG-Ml0NfkzcNdSU8T;6a5;rj&pjHrDPiaBb_k|9l;FG
z>|60APQ9!;@#By_{Zq;FZp-`8oSQoBq3aFo?4_nnr7!;rHw|aW5LJeqE`8W*c}-|^a-pD!dW^0P0YS@ECNAqi
zS&W+w6fTG4@6*|VNUYjw=lq9t$#geG;znMB{R~eY+CC)x2adi2sra4EEPJ(rU#-6TI
zMgo}_3$3$?Q-LeQWlWo^AM5{3Fs`Pfq!
z3W(mx_(MGCQtVP>h%Vqo!Rs+sQF9#`G{!9<=Xn`L#qdSMpel}vB-3RWU$Pg$wH{Rb
zj%j|9jm`EB6tUGc+L;)@Em#jQ5pJ6RpG-yft72R|r_5&kicmOUdDHqV+*pN>c6b5P
zE(JwjLqSQ76FZ3c#&(QWPHah+yp}EmMS2UuE5o{xIzuKdwEdIUXuY@x%GqdO<*16A
zBy5_A3cfW-&J5=i)2g94h4VceOVojEf55qs497t|i@5g-W1x9J>o74IHpW=$=fFyU
zRWn*_sp~BO`8d>@#Yv?RgtTr4zhYcgNXNO+h-9=x3dD^X1lTc-i}quafx@^%z8^j{
z8pS->If9p7g2@v`sF8-Eh^G0EV~H){sj!a)WE9*U?{_t$kUhxcH5@*#a?$+OI6)A|
zoV%3hdqwdhk1ls*pZrUH5cDR1@iXu%H19;GvpNZ+E;4E=0p{}
z5XyQEL>PvH#k&Zx)<2>p0(=z358!yjW2=5A!Uynh?zUJM*^g7G^B&`E8`xsrb$1G%
zuy-;I?hzgm3ve~#inEGu$Y)F{*Sl#;qIbg$SN|o$H}{`?q97uv7hAc*h=rB_mne!g
zU(mRMW%V!;-;EHLf}e+0)JiJaC#Aq`ME^wyc%e-UD@&`gJb^*cbI?&oJ0wE+GZnSg
z*CV_8xelHY*(^fB(nN6PXsM8eBK$!ZPpmz<47*NeW4Z`ZkwgtdzwuRVsQhn-`h(+?
zFR_<^64tr?0oJaE1s--(nx-#2Hn*P|nQlHQ&I5`BC>n;wb_5Wg_@B6vte_6TZiL-Q
z>VMHGDg@6?is%C1A4~34s9kq>wj%tz+2GRl7!cmHcw^9Ic^P?_=3~H!
zcv$0?iSRsylbYWaYNk>H)sa5Vq7N47Q29$qSYOqX?5T(GUB-;>zzM2hFd!}i6nZdC
zxzY2c2jSB;t
zdXCRr;Y5)tZawdjH3-I^qQlm}1ER#$(UrEO7}p>06akrG0RjR|!vr@n$^_oUto7T5JRqN%c5B#P50M82MpZYKLDPeYPxY9
z{MZg%Rg~k;^00{WPk_*?r7(ohA$j&3y|Xl-sz7yP!eFhUt`p7D8X8&6o}Vm1S+nGX=u#Z3e7Fum!f$L?9qxp3{6rs;
zWQ)ta#o{-vAq*j>M9&$keZH>`^cOA?O(bT!tCgIP!U=RdY7%sAl|gm1GUXe0Rnt6(
zZv)`Saz}{Tygb*@)0u-24VLK!DGZe&L_-e
zbStCh2dZ<52B_*|@DB5{70xXNUqqob{oIM|qq5G4sP?}$Dv0LoEm67_4TCD~$a(cC
zMZ-THhi!AB&psLUPZw*u(X9XKUBbquBEQTD=sUl^-op@DXbuWsa))l%g7^s+;hb_k
zsRug3R@vf@Tgbk=eVIenrlvDkFR@!0t-@}ywm*LHhQ`GH#o2cvbT8VzEOmge5X!5%
zat&VAqrIHB9P+(*tZsjqBpltA;z=W%(<<6Iuj3JatK;HI%tb~UbA3{op=!vSo5zlp
z!8~UR*8H(k24Xa@=X9ZAVloe)m6fwV&P(FmqITCx30_ts;LCA4^u1{Pp+xQ?ckt-M
zl!CrAzM~G;JmIS(Fmp%(ZKL=0J?
z;|mZt(6I{aI$UHA!1D=>-`?sq7~J-}`O*&idqsSNBL3iFHY~>Te=Js!Lil-VGmv{P
z8HeL|QFABc;+;mpsY8>)tZ0S6ksRkk9JDVaPlIe7va~7QuYQApZz3Q%rgGm-b5Fk*&VzZ;F?o-MP#E;!5AybHkp@=f1yj6qQ5}EO%&QF(%?6l4
zOKhq^-y=wQe}hs%Ray1!u&&DTPY1&ZQt!WcxR(Sf!9-J$)O=2mm4R()7}?g2h0SZ*
zGJ9IrFlgo@Cy58FM#U`;-OsqoRHrF%4z$wL$pITcj|L3T``~6wSJj|$vwu|n+oZ7-
z@_Mu^vJoj~WEDBi4P8boVts^dC5D4Eb4Z
zV+PbD>H{qnD?;5+h5@W9zkRJ0@is>mW420Xay(91U1@7ydBl%D?q}LQb)HWbqjNmA
zxbfWt--*M}_>r3uaXzP>-K{V>o4l6)cm$WNn`@Nm+n%F(<
zBuB*gJrwQs045^#+hFxe=D36Iz;%5~YF+G{}#GblDvxA@zF@tG1
zmBPp!YBBNtEcytQ2-YZyf$GiHlT;dMK5I$02Ahm9e=T|m7G4b-;M1ou2aGG&nfjsc
zHP@<__frq|sJOBhFjZ)9ne1|D)7@aG7rnJlu6*$BrUulM)@`yCy3mJgms~=zmp~)Z
zP}2-EONQ{gB^+xL7X9J*U2yPgV$d>^4?kd?=I@!2dOfDhEyJFU;j>QYPd|-ame_{o
z0%ZCoCl=+Y&F?O2Z43rdgM`cvj7@}3tt52KnKS{~!O_Nd_;=;!;q8ZT@1S+kAb!Wy
zMAFYAkupr=Fnbkp8{G(di6&2|g0-{H7^T@qZ+VkvO0_M;zJ-YQt8ft=#apn^cQ{VV*V84?F5SOfNL7*lBM
z$TD;c#~PbLlM$Wwk3p`$a;$O>86!V`ty8atJH_OB_x|s##;GZtg;jHii3riTncq|o
zL^ItzfW#GAC}3@2>`uP>2+S;4XNRpDdj6d(sU|$s4u!KrLuHia!9GNEqj?J#;>sZZC
zJ-#$1sSu>|^g_0$wWKIqRk^slzx!B2)StAhKl@c#q8=Gnq8z@hZlH#C7yDh4T+`e`
zGt4fqBq|42-R&5?hj%PaPw>e3sxtUnOGdW@=k%OpWc$^EyrQ~
z;OrcO$Quuh`GI(O>P$&8h$h@`TWzYSW;RUoYv4WH{m?;0z$?;`QKWPdr>o+NMn=bX
zndZVe^h`e3a61(jxi6DarQ=ymI<(ck=il&bTT7yj>=NeB)b`P99fRCgX#@PG&=Sw*
zO^>!Zh^B;p`gfVPC2L(e(wCduhdO_k5dVe-i~KMq{t!jtM`!4Hn7{dtw$HIj;Bzyu
z+m!bzw<=Ml*ltK@6_q}7Usz9ut)r&UH3O&+?W(sqH8rjIjCED;Z*$&;Ss9R7FXUmb
z6jcV8>(@!NGr)FNyEF>(D8g(s16>|Npq;jAJ8bpj<-BIN_ulM@w4!!EoYm)^uUuN0C~5hp7va(_E|Im5
zj1%P8g9k17@=BFgth+I1SZnn*k6?t&gI=oEp;sVSw0iod_Vc!XpYQqZ%@88|^>Tt!
z)oCyd{GQjwae+>`{IOT^H$U>D%VY~&RSqVL8M=v&zT;Of&{y>m-ko#H({!iG4f-^C
zX=r%3foBx{=pbVYPdN=j)SI>`<@s{C2qV3w_!OQWcNc)ARkPDhHqQo}F72sKgBVAB
z7Ej{=+Cng-o~C2pi`2J}pnml!7RT2=pKW81p6VFPW8+RXW$SbSx-T$%zxPyz^OjHd
zJb&wHIr@|rp36QP4*Old;!J<^wzU(4a3M9T*tgW9W6d8eoGYiCQX9OwzP=SZF8JK~
zy=sK_AbR0GR38iRGoM?JsFU7NrRGf1JLi1ams}LK&Qck6)#DA|;LqIObv}5mm4A5|
z?9c=TCZGY!T?uhMWIhs5qwFhsP1Z(ixw8UQmmP#}i96c4&X43zA4`blX|y5fl{^c4
zPZq5~s$HCUi(^=|9Y?tDTF{2-1E3$+zNgkx^ld*(N24pQ@EJ_h6mwfeCv&5<8WjN;
zQGxxXf)C^S>qJ`M%4zP#2e%H%{`HGhFx%uIy2{$(52qHdG!*m``Rbb>-Q8>F#4
z8)oMetr$P^@sx=eKGS?i&)%8-#PP{j&H@5OQhNzL+v;kX_r&I4ful?9C_>nu9
zyPU}87z6qmGu>N3Wd^mHJ$H9gyMs{-jjUnUORq!t7Vo=A{#+L=D+X>^CpSb-eBx?!
z^G%WSE%(zE%htK>@1FqkIcag4V`JhtzizN)znc6AiryQB}&$G*>-E3w9;
z1jk2*I4R#bgN)a*aLMRe22?^GYiSHkIrdHJIuDR(TSmOOgwLtHOV0|daao5&7hfrc
zwB#kq%p1Ka$%B7aMo4~V`x|~SP&0i{?L^Y^pc3uAMzBt~e$n%*
z4?a@NWR+$1%?Mu4TH5yv8es8;7%oh!!(;T{JoZKkH|}L*_XHE1SK)miJN~
zAXyX&##w2;yVzCIDrA78!`4H$EQMhoO#a{aP_jSndv_AU6231zfrHpy*%p}g-1wpJ
zeX9QdM!3Wll2sQa`oQ(w`=PI5^r8$Rj!gi!y_@%OKdyM2F1nM`;djg+{jix_i
z9U>wtQdjv%P-8S}Fe5;QzQ?Csk2;gVN}26-l;IxF)+hK_p}3~0t`xg~;Qrcuc%2AF
z4w-5J$EF&LyHurxVw2qYcuyIzrO2p2clnm_E2Tt50xo<
zYBxyhT0{{sBc=m>aBI+*L<
zD_zr{u0YG@s@iI-0a@d+=aIu=YCvDzBSFuxU0VpF2OKlmIO}jk?8G+s459Z0vudPM
zS~{1_AfRfHu!_xf^cHa9VT)2tkC}f&a3-~see-f)*XgxxDy~o;3{Bd_iIdUKqYriAR38cXxz?sV__d};!R)swvIMy%4l@X9PXo$A^G{28)slc!6A
zYtU?MOE+D;0$NYs`*+;`;~gr^vd2XPmKK`O>w4eL)Q=s}t+3mQ(^v3v58wY=2{LeW
z*XWjR@rAjUh-y>3c5hMs((7L;j-H1OrOkJ-b?=R7G;TyapHJ&U;yl`W)lL5zk0tS)
z#9rDF$+Y}GA8UFVD+Lzaib-mai%tYS9~O22HgyP;c|Oi37Z+^Mw+_JOd*dv-)`q5t
zFilo!8(rWm2}uW%iw3G#>9V*&T1&5!ORg6{cg(Hb%za{U8a=7MrX4B8cXf6SD*C^v
zc6|XEOCirE`*`?GPpxe|f0Iq;jpP;RCq?7z3*%@23c9+rmO@MEuug=xK%>JL#}N$8
z)gNI)CEMR$&tVm+Wq`y%rMyQvO*z^GdTJ#VqmE)BUT|qE68pFja=Z1Sl^X^9I^;5%
z+;bjmcxC(7&$Ft!P-sHW{@%@-uI*2TXd*!YeD8|};~D;EwsWRQmcZs*i*jIXiFTL?
zaRoNk_Q21vzslLatv
z0}%PgBSh$mj1n&L$%-~m1@EU>pFm^pX9TyO^e~QD^-7#>C
z^usY!svq6OcFg*dW#Z_T)yQ2ft1$uhM}Ogc3SY~MVjExB>%8P&fE^GHwWw$ma^?1u
zcxSb!3L_+TBoZVP{c=9PZpcTCKY+7>xNhHN_c9wMV1{?0q3@NxNP7Lp$)Xv$aV+8+El}g^C62zxZEzo1A<$&knk5@GzzI@M~j01m)>5%jtp}#hKU8{vN8Tp1`rRs{oP6)*!TT;{iJ{O
z{W0?mY#hq8snvc%ATq!J#?TDxsz7U
zaR74nVL=gzwywL;x9ERy655K^P_nLK7NrI0NZZ`K&)2|*w-(hf6G#bmXwS=D)Gu;@
z$3;~;jph+d-Bsa52cLaBZ~<2H|5nfcHp~;X5{=#ELiG|pxt(r_TE;(WrDEiJME;W$
zO@j*i;w~Vk@h?rZn`b5>uH*Nf#4CZH00YJzpE%T-!!KbbcJq3oA@@5VM~I>8L6p|w
zNIg>%TEMi0UtVT>Im7!9qN$k=g^cr#`AH4kBO|CbXfZ)t7V`?AMF%dTZ9G?+1Z
z#iM*oJVs!fiC_K=pZmn_*j8DfjPe?P%j7_g@#S)cPyee;kch|0?jFi5@-b$pO-c3D?XH%03~beM7_*
zP}pM!OtbYpHkW#jraW+%2s>jT7`+cIAU`!0)Dw{amQu9CrwX#i0j#l2&;J%WhQDj-
zmV1DTpQngH(K1D(x&@q(BFVU?gJoDXe>Hm(Zw5TKTn5?mHjmzzNf*MgXP=O=b%EJI
z2^k((3Mo_9FSfDE*E3;4OmoKs!f%&rvQD?}NJJJ%SOaA|=D-2&6<3~dguaM#r}D6^
z3w__ofzK%`F}cqI3|fX+oZrImCqMY5M0@|D^g$u1i=cSsIoKJ((dIMr>2tfUYC1
zhhXKWDSoT@Z^~vnhBTKeD>N##apJ~5a<#xK<|yv$6LjVj?d1jh^aM>q+dM_d-sD
L!dM(>{KPXPVh2@9UxLa;m32^3LmM(_?$n6I$-h86^_nImar?2l4g8DTIrq
z4LWc5A_NtaV>t)N<>OEtOap$sK!gjMsPMU1ZJ>}7C_jeGR}1%6a;*@!8I>tGs7wIq
z&YY@m9P75MyuESGT&2H;q>~0E@Eq_d6mx9}1exv|7f!T$KMoJu7V>@zyqy$D;Ptu>
zBOVdBuabO>`F}{Rx-Q7a5EWaof!@Ah&P{F8U#52k&HxW|qO0Ebs~cc^12}8n4aE!n
zeBKr$maL{~aPd}SOv(=&Cg>2`1>sEo;RCWp{q-NqAQIH!AL?h`_iG-ga(K?zD^GE^
z%=P{0+w(exNnDn&C=PH_|3b$t_W)i;dhNiZY6!{yMf99BL6W0%p|1B--T@AcQlYsQ
z$8-QeC$&t`Xm3;+>e}a+cL;CmCN#8h4Q7m-(lka!?<;S?y~F3vpjN2)%QWju^8~`@
zs%GDt`a2JS6(5`ReK*mh54JlTb2JBh6jT!B(KM|8*L~hl1Z6I^N
z@fGHikbiPY-&a#~8Vlt7Xyz6#E}Is^7PIV86R@Skb<#Hbpj!N6bVb`DM?@CVOUcKf
z;}G-wftQD8aHGS;jufm47RkyAS3DRL1lyHNi~r?-Tz1LuZ9Yv-7%H#uU(rd%elOpc
z|Jy>|Ui^L40?)q07vA?xAwJc@e7KO_)g>nyHfu_Ha?zfZ?9;XW?@n)xW-Z?KU55c+x>=ft$eoQw2FXRq|?1y|iC==Ll(shx~lu
zp#{jfzE9lmCXBs9(Ggl9f*-p`HqL!{m8#V<@q!4VxzLq2@rbBUIF5-`UAzkci4%$G
zR@9V0{q}of5Rw3wE-;W{)sARFQ{W;wzqpuYo5j{YyVKY)TiYX%ZyGS@NT$4D>B0Bd
zZ+Llp*^jem%r;liYkXYMWn6$0at9uw7COsqKDk?_^wj1^0xw1sQ<4-m60M`SHfB0c
zGtJgUEQK@LzuwAaDc~hXKcVn!I
z9=&!#w{$;=MgE3`8q3{kb~2y$6nCxzW0=2g%DE}MS(XAMt*R@;MtZm2%(|6NIHZq3
zaUArsGWKGUW6ccB25o$+^Sm}|!j3YF)k2}g`hcW{VsZ_*FO#gmH7Veoo`9h{MG{^}
zi3|5ReJvQhgH9<(cVV1Sch~JGUK3FKvoTs3!@0%93)IK6;&@l`S>l`^D{x)V4Zq?b
z%64fr`vLvI!g#ORhf@2$kBgHA@eXu@zKcBb6yh%olFUN(aMa_54}(CSQN4sgsG~_r$^wBRb
z^gIEkPC)I-+ZHyf&R%!Zpv1avSk25S@|N%EVz9e08KKIi-yj8EzgGIb*!h4lb}Q=5
za$7IE&ux@pbBW=NQ`F^rKZ1^zmkL*Egv*=%c
z&(whk$5<@m=cHz@N(-_q2?r;^o6r^PROT?u5zZjsg)fk$?SM*D{62F%RX
z7Uv{qcAlvJ8;k}=!z?Qz%dg9}Z9m~jr&Xshf;6QreSr#r3v`oJu^|y9m>+}fvP?Vr
zKDQ&S!e_IhNG;}W$wW}*in0QIbS|$J8Or@$^Dv-1`aXh+yq9cU?cc+c0>-j#RILo)
z!w@?Sy5Ezub!_I?{+u7%H>{=ie(UR7n5FiO(%6h?@EpO!ShncGx26j)k!-KG)IgZa
zw!I9iV_0Xm5T~Zut@+`Ur2oqh(R3KLp$Ph3TlXRTQQ9?I7z1JcE^x^9czis(yni+E
z`ZzXHl?v0$Z+=e|^Ht$mRfPOVy*5miFLRglqXMQlL@C$y)|*e1Nh1<2$S+qHyf7$C`gzs%X{tnaQ$w
zw^=aALnktM@?`U~!rx8HePO(IP_uc;l?-OyC<>!w9eZ8_1gj1F<}61nXLK@A-;PT6
zP~=;x5Hle_VMJkq{&FWVD>3xOidYn$efHUK!U-psqQ!AQOfH;HqU$#fE#{y
z4D3vLw%l?{^Al$ksU|~92is+#5JLy#olR6sdhj7-6Xg*{9AUoHv@e(Wfu({g!X7t+
zUMj@Rs56l7UR9g8T`Q^>8JHN+?_oT^3dsaGe~JV$ixSPs+hvzs7G6?2+P7k*Wb*3@
z8FJPrc$!A<%jZ2Q0NrV)Sm)7iFyQRD=bq;KO`BybgXT-S59^8PAbBEU4C$bT+R%?K
zeWxYw?1w-2K_(%|BqW)v#Fd$X4-UU{-92ufhem6
z1DbP{KEySeEc-j;PA-O-lv(phMIN-FIFlvP+K0D`G)8Wv3};%d&vZPS<<$~?rirxW
z0j7?%wEaEEQvO=@wO+n3fPQl8%j5!Re%smrZu??%T8@p6%U5ld4z|n=hIGg`sz$$Q
zxNM$bgB=^G*c^m{{K5;**U^Xkv4gIAT>X)UUwu*D3^)bywD#X9E3)QgI`+#3Z8~bX
zPShz`@H-9sW+R=J`7`;jX0k?PS|zZJQ^3oICFn~dah487k@Z?C%#e*T*p
z=kL=z+@lcdST^GmgDM-=&OP^B+lVs|6!Y@hftAn0Zw7N>0`;`PTQT>kg4#|w?W9d{
zqD&7=LYAaLoR&pB^+iwHxJMgdBdL5yt*x;^%IV{{dF;5SvA^p*_Wrh1h6l%U?G6B`vb-?JSiQzhAnwTmDOfmTdg}
zvL>zct8!_{bSj8V=Dl_$ZJiP^E)`-8atH+j9J^sJy67U?4U1AN|HtgQ>#nmItdos~
zOZrB^1B{H*r-0Kqje)9V_)KmRnZDFziWVnA&=Jd}!3s4VCQ1bl={)2QmuWfN
zlwmsSPk!=~wu3+Is0~2n4{*{BoZl`VDNcUhY$BDy9c=eC{Od9E=fnj6U7xD<%ipK5
zTZlQm0VRu$`|PvNuA98nAhdtyWwn#DC=bul0NrDM9hu>I;;T5YWC_yMRS~AZTCKmL3S&n-e=hHO)J-8KOr%_}4o4oO=HAym<
zU%5i;t2?Z&{^KA2FgfwQFpZ&=_Htz3`ObGTtd+=-j%2jHn(>#A%1HixFw
z?=K%N;Q}Yh*WebkN@5#jdaIWM1I~l;v%N_hH)K^ensPb^JDNF}1337wY0wNh+Rp0B
zX2%&inSyhk37r4UIi{TF%vY}n!Uvji*$~Kk@PS`E=iF6%XW=_1VX(1|G?W3IO|FF4h>EO$0Sg~(;Bp}=$e!mXALYo+$UaH}ZSWCh<1rs8Ay97}
zGbo;HXSjP_e60D<5t~>20}Ym;mp{M*hQmRIkdHZYo(M0_doj#?Zm!jZwnM$Woj}L+
zBxf7wT5GM?#wiN?fl0lj(3@}j)mL9_vdMEcf$`xO89(BwCMsKnTlu^v5Q7J2QL|Z8
zlLMm_KIEKR@3@lI?<-jWWoN(Au5P>awy>yck=pdyVVkXA6W+Mp8;qXP5kr?`#eJseR(C#wDG&LlpG98rJLbLTb$U9C{BM6g9Ac+QQC*AZf*dd|$o(wnh&yZJY-nVYGjdNL
zA8?Ur#*HF4Mdc0YXCg=$L;+?>SVA-~o0V7{rJXyf(*?}$39F+z*s4!tN;ICgb1koy
z!nDqV;l7CG@R4OAO=2=_Zp*ZrIs4kzzLrS|=)t434)7kg3T+56%Y_=f`CVxvf?1rg
zkYU9j9kJhdH^mJA06+jqL_t*Zn=&1j^xmI&%vq3~ot>E!Gjq>S2bJj|L3&5n)L?qKL^GwQ>;erJS*CY1_CJn1FEVIKGDVt_x
zlyX;hhORp1YJOToI317*6)L`pY(sm@kJI&{t`XTV~~WyK3QfiF@bt-h>^aGosZv9p4b!lqud37rIB
ze8M73Udo|;aHVBBAEjU$J#kwifOjib+OFttu{KJ{H`&B}={@gxx6c0F(&UD+@I&Qn
z+r9VR+kBa+2i9soV;uZxF9e>kYQ(v@$Q}9Nr;cSbJ}+8Syj%|qWEOWSDVD~6U_dv<
z3UE$kV6j-!-9_7sGH~aecV%Dr{1=7m1kr9qom0MR_TwL)p1nN(Wy9CR4mo7HrCW22wX#toN9!E)RkKNxHq4}e+ujx#Y%-n9VtB)UE^vUx
z>~~-_jPVP6sV6+A?cnR(YM_t8eUNj5fkFGzr@*thY73M@c~X|`EOwWL$+AS!_ZIS6
z>7gaKYO`~OeA0$!Pt&JQx3kKD$wfM^PYSD5+=pJe=Iy6e-zam?P80a-_~VZ^zA>KY
zsL_f$OEIh(jNyI945197fct@Zr-BlNLWOcb<7KlzqmVY*R_;|=BT(h@HYiX;YdTYX
zQOr7W25%jKW`imNV?I3{hX?K%FhBUg588l9Cr?Lms5V!!G{}I8jHCg0JKmAQU
zSzR)HKH8LBSy@cU07qYbc10sqGWZ~fjxowkJ@r%@0D(!Mp4=0kciwsSK@i}8w~hm|
z1M(TLTM5WE$`bO9(t~2G-QuRmdfkAN)+fE^9qAtG>@++XfT;rmDSq6zML4b~$2vvA
z6d4p$E(XPX-Baa@ddcb}h2cb-oKRk?!SIrzjzR;ix!(KU_u7X6I)$&Ss5S|r495eU
z^<}zhStw^HzbFOZ$%ShTn^hXo2fqCAkAITCNBg;1z*bC$5+x=JX*iFj9W`y(`El@%rLtRRK$7rP)2o677@;
z2yJ+uefBZD!4u_<3p|_$)Pdi`yrUjR9(iOY%VpKY!xduc!zM6UG;J~fu6&4zkM=wv
zg%`ZwC2<<~jpE0|6g(&!8Zc=>VP{f>Qp|)~s{v|{v`Jt^C|6(g`|O~DK9sE@rBYR#~m}(9=@iJ{!B6%iE_W9$;C)1!&-09MO%s!L)r^&Mbv{0YR)g0
zLt^9=eEDz?_|n(VkNrtXE^^shpw3K0Fb>fFz;F5o+JLOrHW3GoEXd|V3@y22A+EYi
z0Hf%FR`jPQoph4g#RQ`zo9yU=;1zI@17hPxg(tuozM+_w&U2@Y$GA%9+X~kA!aMxD
z8QXk
zpEf?Tzx*jfKPZr=HNRPU=U5-k$5h8^X9%+-_iinXa%5T>;Ilf63Xd`^TtA<1{HHRkkS{V9E7#yYOsRp
zSQLP*0o7ay_{aoHtm@)5ZkU3U59;p<=jy77VM(2T?2
zSsJB0mcUthX1Nt!u{_Ktk$Fyf4ZwE3FGtt0G%E$c^3m>anRwT`-qrH5FPIu$TJDGL
zEX(p67_utbJ+gue2jvsMfn{O&kDKg3dkrL(hI3QhT>uvlK19Mt2nfiL2Vm)h8p+ay
z;ri=u2#-JZc<9zgKA-`v1e?kIYQ+^-62BLP=R^aJseA0v$HLlLPKWlmnOt$j6R
zWN|2IeO^soE67^}
zU2(C&r2(9fePjgJF^)sT&BkP1>F(8;)X)xjAV?vux=h%E+#m3hmK>gt`_8p;Nu+-Q
zKIgX6Hjx+lLCUMicmzUTuU`)AF!)*A?|K`A0MLf91KB{fwGYF_GI+%~`Z^89+6KSV
zd``UKOIxQvj7x>Mo*va-C@*xz_~vPuD7;Gw6-sf@8H=farS||U5;Vy!Z}?M&eo!D!
zYdX?S9TJZp+kgM}f7@V)j~i#D?zGd6>MZKd!X-caaULmK0pwHk(;5=gn8F0bRjseR3
zT2abmsjPnJg7h6yY%bLRh$4!Tfbs~gU(=VMww6CJczTF+=2slN@hQc}Ov|BGE(!$-
zBmSp8`HSM(SYD|&H0Vtsrc@MmI&5f5eenmCyMle_0XUS&;E0be%IJ!sFG>wcJ-(@%
z$k!HSveiIdlqOe*`Hd2TB8Q?#{TW22Oqmj7*)*kU^5n_pbBQlD1GMw4kwWZp2ps4S
z+|y4xJzRJF^`glm2J^Mz8Gf8hY~VLaBDg>YaDdO`gZEQZ{)1AI@tsAX{O)(7LW~mR
zvg-9`5PU%Xt*7dP2q=2MWY9yw#m^MqVR(w1Q6KW-Ux+fyR~+#@=X_XKiWxX}(}xw@
z&k!XN9>FW}B4d2nlR&)>m4e0O0v}`)V&s5y$Q&@3IJBw|d)<%`@QRaydu$R4?$n1#
zBxO)G^}x@T2_YXG09W3j2>;iA{g+J&kQrA3s0ZofK4AW_;D@rnS-P}q0z3o{=*UGG
zOb%s9Ha}wO0xjSR3g#gP9~?HRDAN%y=%R^O_u}x%tFHuo9yeU5iP00{CFLRO2Y&EC
zeGp-y;YELSquTiuS6ms!tv1dk7t|F$Vd@A>zL==fj!f~Vu6)P_Ihiau*;_uLpZfHt
zt9=M{Kqi>Dq0pXl&N)VZWC!Jywgn#aYXp~Fr#*F+wbm43CJ&U)M1($+v-#n%2PU;l
zKKNJ*0eqPJ;zL{%ybN$h-r1WYYqsrGaDI7TMY(D4ydJ0ThW>r;3bD%yZ5i4!iH0xu
zxx+X5JSL0;=XpxE;Yrt&0+o9arwj!YP^V{0Y_cxe(m5vH
z^U3ODKBX*MI!(M@9_QhBy53wSJYPx^eBGqL7>%WjnE$a9JEIdcA?+gJ0zO>e&`$dy
zzZCGQ%LLJX;7jPuWr8xCk5XxmC_bCDd(A|pEg>8D;Mq*&>6o}d~wN#
zzv$|$ks*PM;CNOv=YrEA~%9qt&tASQG;5$CtlOEZT
zb<|ulpef^kCN$ZE@e|~y`)>Kna_(;AO4lOw{c@MUkND-6U(N3Q=l$8f@7qspcT~38
zxbfLu?|HA>Y<{10EsAMKH}A#y<~#m}Km0L!@PXNK!FWmaigZL)xWJz}(^lXaEIEdiUfnpBz(F|a+2$7!3TF8CU2qGq_^4n@EAeB$CoKIfaqJR7dT>6pe&7mGzx
zWLC;>rb&6))MvxPDgPym5>PMr*Xg0iky=Oe39M(3#|
z(YhR|aMcNE(s`t5($1j{Q2C=R3ZyjUo{pA}so+P*#u++uS$}M!4e#>l)87>AFl0%}
zWM!7`-$C;2Tff@j1CN17R?KWG`DFo{0fxbd!5Q8Yd+^_s?VT3yQ7l}6piBa>%Z}rP
zoN3A120aEH2JlaP>QlC1&eH&!iw!e$gtF3@q5|Id!82$9*URv7=sdwe7Nn{VEdwkQ
zKsIT49><9|^|SZ#i3z-KMIpAt$sd#*eB4m37*yGi2TnXs%gEm+Ae!Dnn^Yl&j?~kY
zM?T&nYrH8|q)p3lz`ZHNMw<#9kO#R@2tNMYD`ao1D8sX6b%^isV;3v(7e1%>lwNVg
zRr)Z@e%VC%9HT_xKRRgx6yl4cLR_E^z{k8o3?1?3WMd@CB0hyE_{bi0B!DyZViP3(
zu+Rm?iI36fgqAA*fzL%=VBlj9eA2@+HX|Z0q)BPl-+S;xKDofvFXss{Wspu*dGncM
zVh3LE7C&)5`oMeV4>6NaHl5RE2c7aP{bwg>^^1hE0NNLJF1A*KOvX6iK0mv0MtZG5E-Q92M7|t;x7&80WvUQ6|KKNz
z(e)ZI7)Y#+l{$O5)QixnLd>Lu-TZ7SLxEajjWx4F4*syLlJ}U>gu;a4-6kPYz6BNd7Vf8jF{)(1?`ytq6~u@
zmQ%S5RO{+_Y1>%Muu6hIaxXU!>(i-28kk71xssEHXd|o|u_=}lY~*Mq9*@bsbISMB
z?jI5!Y0gZip*$-~>$%xZJML_j{`J<~KyB+}TO}Z^@jfTcDU50wkshUa!Gbv9K$+#N
ze5|qX0p*ABiTXne58T5SHliZy$OLl9gqP>YLtRjM+5ux5mSp-j`Vfpk^dVTwp<#M4
zHqtkue9>;1grKlD3eH2`cXoE#nbw?0!i1Pjp!8uLJgxIBt(&JAjxlt|U(kqE!gK-z
zO&Jep|HyT3?Q=NNvZ&6bLR>_Z>a*BMupF(;OlBdVqeb~)kW53`QKa{I;f)Qu)^VjU
z%KP>xkf$vJJ<1}3HUlFH0)t)JsYd$8a`O54O3CddFguQ!$@gu#M=
zmkX;VyRbRQfPsnp1YiLpU%rbPQ4BbajL&*HzK)0gcD(a3a7oiwg?QU-w>3JV
zlwp0>W~wF%aaxPs?->a43NeZhN;u2U&?a9W|LxFQQHZHOhu-ty3Y1}FZ@cZb&rUhz
zyV*Mo}$TJd26rWPo1%(Gm)l#X+W940D=XRuPL(f
zL^|j*ZtOUfwX#-aJ};|i{9Li+RWUTRhaP%Z?kAs@rFAQ{tyQyaw|$+g$(Kn%c_tR&
zLx5tj#ICf7E;3h%3O0JbXknbpz)x1eu;79}Z5@T3W7y!82j~p`oYsM5nAIh&?Y7%4
z(>cIB#xL@rY(pDdn1GD|2syA}XLwgZj9g`?;=S)@ZofkpwG90qya5-p!*vt%2v-RP87w1|f%OH&m?c0IP<;IuT!Bq~mx&%_2|npiJ{Y{XIP(+*
z4kbe$MX)7X{FdE>XtiT0^i|qRw!0t(xDt+J!07x#UTw?zjSE39nl7@@Ri2p
z0^dG@!)=JW%Juq?o^*Xxh4;X()$0
zC`4EVQ9PY)0~NdM5mPoU4EWY#Nn{15Q%V3!?{`UILutd6fI83~!H)?nZI}EWpx4b>
z`N6${_Q6Fu+(f7=xRajxFuBErggzgOGIEI`hrcUIAQs{S4uHp3S7{507reU2__)(f
zyU49#b@dbLXz#%RqNyg!3v0N56X`*(Tg{V6QFj+BLkmoCe(K3*RM)3e*T=HXj!xq<
z^~9>reg@|O6JJ)dz}sohJu3jn221Bm;z^IP#FyeYdpsYQ9ARb0`b=6T->i`Nq!F0u
zML);B8jd4G5ktYHtu+ha2c1!Vk3ar+qa$SjgEQ56FRE1Q;q{5nn?W8P?^1gBJ#B)?
zxKDhvc~@5b=vVGk@wAO%PdD7-QXy_40SFI`m+M+>gqp4c#92CHX_<2rQIyjGC+#f!
zzDNLR@MY*f1@g3o7aY#daxtB(E5z`Ew6#z_fl1+z7Jl=L!4sIyO9odgQ49oFUa-nB
z&`=Ia0!k$vJMU0z$Awpp+9*T*=q$^7MUCh^apV
zFZBZtl#jD3pKdNH(~xW94|UBe#FT~KEQ%HNEGma*9(q%V@jV3&XGOE&3EGbuIZAvy
zLW;`GMtfkP46{kflwg6U2)j^-bn*Vyf7~vGcyrMr`siY%W0R*&Q?N3C6LE_?f#;kD
zixTUKIDE&73D2F6X?=h};2BC2O06ry#J~b3v~#&7J@Bv)1D~?6uHuq}QVJf;Xh~Up
zxcB*ni7xL5
zZzygqb~dG^FH$--fXkYh0m!Ko>+GE5ie?^+m&)r
z*hq95tv0re6vwY;k3IUhRtY346}K5&A)*o-VmLNRKN78!+A1*XUB=GxWtroHj^Xq>XTP
zGm|DlN<;3MlyIgv?H3C=AAjjhAqEa|gu4a)*yIB*CKyaWJQT@_zZ=eR5nX7jOn{LK
z+5rX|#weF(r&m#4f97e1dt55SO(XzeaiO9^Mron(v#d);%np5KXFh1;I}Coiz@@Q<
zq9&!5uUe%*N>lC`INd^=D#V_y2Ddgq`a6$P9>Q1Wt-mMkmN^G`z~um!3N!I
zlE6UXdD9prn7k}|;u^sB<=LdO%PzZ^Wfw~eN-#^IC>;zIelbY#3_ssIo(wY7pJj3^
zehiqTMWI6Bp-jp~adGzwzGj6iGXSDE`_NHg*2!3SoUqB~{ECOVB|
zg8YU*B&+5l!fk<+&%b4#`SfR%cNHnstIL(*D0}DipFO)ne%RlaWq57zW26+>o%QjY
zU+ODw+PIhSKGwHes}%FKBJ!{{=w2fq^lxVS?YqAw_3y}b++io3YVmq0jho4hW<#48
zJAb{sP)}rp6-y5(omm0l9Umwn53W>9AlR&nK?hpHJ7~>DVrYu|5t{MUI~|R}*kNEHX41w<2;hZ6%u0jHwx>(uLV!c~VOn>;r(MuSJkYQI
zOs-$_O&Ct_>1JcEPhvdXvWn>uTDg`Le))1sg*Z=<_;o`LR?OD?gEXAF{9e^^HKbZJqII^L9bMfVPim?c~k
zUz8CxtkAJDz_Mh8m6(CX%OOS)y;n<^SU^#pNQYIK&2r4{`IIacMg}jGRa`%~N8W(V
zV3=2kkx##{M&k;>(k==ExR8g}B7t~y9wuOC7E^chg
z)J{6HQ%?R)w$h66D|wvcz+}?-0~|i>jG_%5;D*~0$|>a&91k|%@eY@~gAYDLZE|b-
zT=V$x6YbO9+i(A7Db%}Y#poS2amFQw$ur82^BNyqFCQGz3;v>f(%;aJz+d`>uWEIO
zv5P(vzG9ul-HP|X-F^4n&Bxy9k>c#QyF$z=6Gj0h-W?qs)w+3It-_T*l*I*3@Rq)Z
zy1+~NALPT~=i?O4aJbLcpWpBn8hK!K5g&LA8_<#svGi-C8w{ZpW!TdU27F6}xCs|h
z0py
zyBRZP7(9Fe8RXbGj6%!6%3y`k!rMK88e$>7?Y7&sL1|O*O_p9M
z#qC&#kquXpY6>xs8;8N95F^9j<0qzY`UPhrW7TBk1%(%PAmpD(C4Rps1p2Ur$vjG4
zQ-xTv@3cqZ$N!bp5qO1Ct&d}910*MoEY7aF^6G5ooj9X;f+nSVN;&+wlnj)$EPFvN
z5x@TRCDlCyZWjT{iDD+)6B!z=iVqKd_NBg?-PzIbS9IhUDLFgCHlYwC+a3>@zZC!&V9^=NtL>dL1J`8JdXJ@Cu^EAXBC4tbV!0E1SqWsNK4
zmkMzkT%ePo(P9~<5#vvc;=x8F1QY=zPA?baG%gk5Hi+INX-ZS>>AX=SSzcu@qT{EN
zrUQm2X~^gG-zo2UyN8eDV?u;=&<7|6mE+~(*xA`BpTX$IiA99t#25guh@d!aEY}Ep
z@Nm80JqjtXn0PUGvh0Nti_ag*4sgkL$|^qgGJ4?poCWI}~(c-bsRgHvx|Fe${;33
zWqcL6HBHa1yY_n9@CH5MC$25}oV(@61%ZBs4_-iX{E-WO8SGJ#LOfaMoO$YlZ?
zkTovuDHpd1`Vs1ioS?))FW%EXGQnWg1b8UtSc~zU2c`#y?=cg8R>C-^nEvJhDc$fU
z?KeHGk9pn>s004!YzSnfiqkyYJ%jw7FO40K;S#5H_j`Csn??3ngQb~CXI1J)g
zU^}#Y=t>YuD3d40i{p<_hS}W0;O_VVQ^-^a!obNU31Fk(qZFqKG5M%B0}U}3ogyEQ
zVK7FSz)FRJ!Nd)#4*r8E=2(Jo)4(U0!Ir#@KEB~~Es8-FJeGz+OgW8ks1hx?p-xM~
zWdi!M(H84Jyh5?Sm4?XF+WLL6l?PB?v29rz)S
z1L-mW4Vld8v*BiNfQ~48oCtw6(^oL4H)&lKES6l%&?-o)3NeZ$yg@OfeX#6*?6Jqm
zlKX@vG52bN*fFZ#%DPsv`_2wdJ&|DP!h-zZgR^Y^0Qr~%?Y;MVZBom`7Rxhj3mMR-
ztox?sUiysmmf3-ato6+$DFO5838P8;tJ
zpbhsZs_a?VOzoa=3)d6eC>XbxDC6$H1R8kY#O6hg>jP(}v*Ye^i|mmXp5gzC%LDcF
z_vA}2p3@e%?vaI_J`m#ou1K7h?ELk5I2@0?{NWONz0(+eKtIMbjse6~1$RA+K)Ai6
z?P4&{snTRC9Jw2wg;HWZoJJadYxwBl!8J&$fcH^<~ISk^o6ZiL?-`{z9v$N9%
zITT+8TsFyY+5~cXysX#mUyNlNmk-B*G99khvA3A?;4qL1F&4ahxlViH{5wOs;16_N
zS_(0nzgQ|qQG~}VQL|LdBsvX_yFa5o&>w{W*A?7od}4({*os1o@=cj2s$2u*G6Akm
zZ(=5X$P-tQLhR{1kJpvo>E+MUn0CU1fVRZy1@++wLC%Y2WzJzkH*b&J1DCv5czq%P
zejKOf>C&>fXX1wffmMHFt<+$pegFFpkaG8c+QT(w6<%ePv6?t;E{pHk*~?N;2{aE*
zig^6-IoZX(x>)W=J4*RoSqkcF4fpG=yWU`;5JMmOBHT0JZyMk=R%Mhy+B8Zz?egxs
z*@TJWh$5=;blIsCDwq0GAGZ)gA6JO;7Gkfr(~Ou&IsJ~iQlWq|A-`S*9{K@f4xF*p
z(vJcIyrGv$ucB}CgAhDb%tc6_^V`ejIhJvU$Heb%vS{P#K^^c1=L~l&&K?|Y8vDDU
z7^n60d#9)WM#g!D0fj!Bwt??3rz-Iq`gxwgLL(%j)oU=|Tq?vctkS4ki4izv#wark
zLd>-3)L1gY>VVKX92ZW0mto0M0D57(DTzbl8p$G0)t>i!#pX1o#hw7mC&K8gSWk;j0_a2n!!pEo2%P9#Xiy-IIs1
z`=SstnegRb@MNi(C1(_34_-cHSRI9@Kl9kr=3{8T#1&%UML8%O^a-vIW5wefY^-p|
zj|b|I2J&*Dpke*T;t0RFnkmGx309zw7m45{3y@la|J8iR7YB9>~!Z;
z6w;C26+Wzk$g!vM`gk6P;k;@TlMYKT@&Ih=gZwhsv+ChW73n;98Jw8F`M}`j`0-Uo
zXaGK>OD}Lh#`tu#%in8X`#SmJ-jtnv)=%YA{2#KIt}T9kRFg=ZIbYEUX(HUud+{Z6
zYuH2n#hf;=*=Adq;{21JoMnE_OgQNWXm9C}d5$;F@P~%KSV?hRVhq9Z41APg%0g67
zz&&7rrQcu!mG?JT2$|@n_4Izg^HEoD#T&PQOW
z)()!L_IS^Poy#oXqP6pb#FSa3c}2#_gW|^WzE67Cz=yRQ9#W3uo|ls<0z>YmXMg6j
zb6P-0Cf2kwR{B`^#G;SEgFc)ImebzpHW23g`c-Yfl@8ROr!kG1
zb6oMCVmCjtH2lff0LAQ$_oR0L9Sn>f4mdz_I$K-I_#ENzG#Lb%|KEVfR7Tu
zPJ5JXlxW~LQ;1U;MN!Af!%f;b8-PNU7_g>pCTIa48ARKg}Bmxbar-{8w@;xSJa8kT5SHxTfe}KI#EY1
z20k`6abf|yffigWhhy1y3n}^1fDGfO>=t5_BrX(U>fT%EO(BNc=?0`h1g}=aq$>jfC+CZ{qz6s6R+TxE;V~D&WxV>-1Azt{+v#s;0U;>*;l`EtTvgQ
zXrIDH8OA4<`at7+z}0|uNS}Z;nK1;pf8c=!>yn}v^VK>6IOCRpH5Ek~oRN{dLQJ}%
zz{Ct%qC`Pkjy%Kn9G4XOFRbLqE9Vh|v&&^3p3@Komd$*8`HsE}8AlF0J+Y_tXR3v{
zS>RVq`=Ab-r~@4OU(Z9Fzl!QKG@kXWtJR%;p+X1ah3@GG_*e=ne#ki!R9rZncAlOX
zS}*J1ShNx^Yg{S6RER|c7b0)GY3%RPnD-1e9UUDuK;Y0$C&S?2N7;}j?HmRJvxhnk
z@CXGHD-#1LgA6gJH@J_i^UjrH_((o@MLt{`u(n{WGpkgE*QD{hDoz-^_-BeA2{%=m5cnO?~6jrAdNDI-z@ZFGb95vKF|!x&L7H%
zp%^EBn~%xAv=m}wjN|OwcN?VxYaA01Tp<|DJfHxB8*;~{Fcdl_O`IO!)=_xw7Gfq2
z@Pc5m-Nz4W_=h=MMvxN}Vr0Pcc)9r)8aJ~LyM+ok;ENR#KWSu`3l|aGLQp(CkhZTE
z6G3_gsT$fD;fiXDfc7q{MC=ojg?>A&F}$}#;sGM=Ydk=!k9+O?txdzz(<
zTTywXLM*DdAf=7h@BLjqhM06P2q?z`(V?*PhSiwP4gqDb^Nt|RKNtkHNEnvSXZ4*4
zG-nX<^P)Kogn@@8CH%p~Y~y#zAMR0p8B{q^k1xg1VPidI_RS!I6^>ouT)@Y2%jOyU
z@EBMafLZEhLkiZ8yhRYj6S$t1%{Xj?Kz(0wyf@
z5rP-WAPN_*23Vb-Jrj=(DFg0$ke2QD!1a5Nc?NI$qYy(AWap{|=MZ~Y!~`Z%(3K5C
z3|iEQ7&jGoN`1hGO)(rj1+SU-u&IfqW0V^vJczm*;-s1=ex+#pI2)?e9HrJ~l!Q
z$v^dD81;s3X+KO`hDIDCii;-w0&)wzi{uL!^vlaSI2NtM%Nke8Ux7br7{fX^2|P}T
zp+PDAS-s~u>81DtEtv-`%Lge{L4!rmGDeUh5Hz@3nrf!xrV-pENqO4>1$yvIJel3m
z5j22?v(G*|NXZQP07lReLqW^WL6*`0?T!A3zV0<}2Myps3U1JZCa5zB8tm;-#}njQ
zV7$~oYwy%C1-T;xS^R=JF5@x0)_@kIm;@=+K}wL7;rMA_46>*M4MstOlEKkn60|WQ
zXfO{N;4Hl+SwVw-(BL1WFa;ff6g1eFY{?R4ILRM5Xb=e+#G1+%WzU>BGw6&|qlK*J
zR<0DTAWNjtBrm6qZ@cmd9iTOJ)Ytp0T>t~x!3$_l$it<+>eR!JfAphp)zw!ADR@E3
zR*+RY$Q{Y*&TkF+K^FF)K|4r!=ph*@O0=kdOj+J+eyt){ABH^fPKr*@4)&mBbo))+OfD27_viicmq9-ALCR#cjcAY#vW8oEau+bZ
z)9$43G?Y=tCynV(k#lW0Gg?b22vVGkZnPC>g!~d{Q}9KTkRavI+7Rs-F6UChf)vxB$x4uQHms!l3l=Q2at{392gCG34-J#VgB3>f90wM6FAn$Jf4{Y(
zbIv(ippmyOt1q%E*M=a)Ge8e7&&$^d4&edGhBjvhS=dcRp#S8_Q>;IruJkF=Ya~^vvGHZBHzW;|#zUhTi2n^vuiuh5&m
zE)6aNQnKu^zPxAcfxeJ;q=)}HEh0$CH(ro1UvJtI@{PP|vvbfS(8f!-99p~fa-c;%
zcpdW3m;c|iulichZz2200QE+daYNW<)l7%K?Y5v+eKOSAOLlDRLB=HWH_T~t>2te66g=tye(
zxYJMV;vdJdE>c${w4hC~G>bJ5i=OB0Erv#cXn1Nk|#7`l)j+F)&FCB*6BG$KZx
zkaH>Mw%Xz4!7K2_a>WKMPJC#$4+K6(eX$(RssTK5na6qyeCS47p-t0PD32or*(@d{
z&)g)SGxebT(6*sNS_kfV#zp=4;vlClj2IEm`i2%e?XOxf&(
zvPx&qz`Wrmcf|33^arkKkuw4kAZ@7k~waPO_;I**+7S~gtE%Oh6068
z9!uy9I&_5W`sVys1}+8>{QOYn(sJ_mKCm!|p-AG|fowA9QZHcpz?IM2?r$#(nzL))
z6=KR_&}5n0X-TBnA*8v*P205-#7FDZ5K41EqO}n^S
zksrPxCrpNX!d0bVPDbDlr>r1H^iRkFAE`jLILeKfF@*^R?g+FGe5~1@z_Fif+M_(`
ziz14GT~wCS9h{M8CJ9U)pdtC;Jv@hg(8}c_tt0n52WR4$+OW%6>-1MlSaAWvg@RAn
zBU6-_&(Cl0ho_WD8)qWiseS{z()5mV8e8Rt;U6XuOhR!hL-vtt`UKo=oL4EG{9Y}0
z7*eZ$RW4m7)FZSKMCPW+Smx897Sy@fa*+o1pk2?ll&8kuG_SwZK<&3>+=K!Rc_ALD
z3$P_7w7q3q)m_&$s&u!Mq<|oeq;yCqE!}L8lH3x~-KiqoAfR-&#D>jQ8tD`^DP7X&
zySSd~_CCM&oR8=EBwzfmy=u-e$DC^pd^edar4e&GWmQhT>QGMf@-2eApyB75m=<0P
zf3(yk9F?m$G5gg=lUb~GYu7mXCIV?*@-?t+mps(#kg0J(3hY%Jinoun
zil*gn9x5jXM#aRCsU{LHeHEqjXL+)y%ZL^Y(#T;3zyt{if=#l2>%7;c#LR&gxF?iUappGSx%?lQ=Ix{jb(ogvbOAlJB^IS
z_M0{?NwTIcX9p2vfL`^OE1#p-4T)se*F6^wUs0ze^{fUeaytvT@Fg^TNiY3US>&GUbiI6$$BOM2*NS3=CD?sn`vQaf?zcaeWUQ&V?=Ar6IdRxa!)$
zO-5F69hd_<^;vp7jBafH`mPiKn#@|l<7o`Nroa$F0=$RW*+kjr7)bT?O@0Lvb{2CInpPkV
zQrqa1_Ftp!elh*n^+$)?>e!AIKbjr~?Ric=ic6b#acw_o6AJwrH49TY;*ZU~_!8IW
zZyofr55Bw!G9h})&cIHK_WLCNyN^zKq(C7SkE%E3&lgXVs~lv{QM1v&Y$0
ziVq2Vk2zlF%iMHHt$}Vc!)q0^7X9y7)MxZ3ZqY1lnG
zM=XDR$MoeIoWi^SamcVyuMN#mz5j=d>+LpbLivmCV!MIvIjh;!!OQcAkhHrZ
zP9vPpOJ5846p6?UHX4xY?eNA|E1+KaOQxzC?d+QF>l#bJI!oq^&paw^zVRq9VE4eA
zPO!LMxjcO#l9js4y==C~NiBVzTOiXPILW*pZMv6V<=f)+qmza+G=Ppm)DDA9z$Rtd
zf=N<$pkg>ohWrb*{l&*AcNHxNwRE!{E7``gbP*F3^~0yQivkCa84}}peQha5Dey0P
z5K%?2HMy9(bc4LOP9rXloAS|-2+aFuS+C`NJ45=OO12CmCM1U4xx|ThiAb<0bdhPi
z-@n4A#K&BHY228JTq`$>DV}UZV4Bn+MUeN*F4*beq<#{W?@A5}MLr~YUXRdaNR;B@
zpRf$vNi|U8C8e5Ti^=}p$13h|A}@0ALM$pLhJH3}ma%Ec^P#tQQ5_Bi{nF=C99&Y>
zaU$O&MJ{~GsOQZ&!>vQ4jth@Re25V-$II#TRz*7^5-FAQ6YW?V5*jmDdd=VHIlYR^
zz>J}Wn={(=DHJXBS4h}#?BjRYzTa@$u~(=dBJjhEO?v1m(mo6>>7`MT;^2X_H9GHg
zK;b91r83~`vv5Jv8jcAim-1jQpeWm>@`AYzm`RvsPFIXhCp_N0`POiUcJOfw{^0n4
zjr93JAVvkJU#U&Dr^fH?-%jJX1Jb!+Hg`GsLt$mVP5UueB&)zWP^n5PXo9~F_J~_zI%C+0V04uHU;YvCI{_G`jxLr_v
z_>0FwxU{+OxC>iQqNj7z3d#-|vb)I3&&|I&gxOn7ng|cP+|>+u`#s58e_3WAA|GKD
zef$-1lOg8#pI!iiKN9JDl~5B%4mwNNoHBDNqEZq#WE6)jvOjR2dQ~(*MW&#JCJ3lb
z$3@dT;!r83fl7-jfeWv;&b!y-ovcSY$zfA
zo_(G8N3|Rm8o$0&KAv+-idh8}fmB9FudNw>iarcY+xqdbuc#nTvDw7&GJyk9NZRy(
zZfxm^;Y$_!>A0wNEJm6{S&u%=Y{A9;EAhi1sSlZ3m{Prjaia9_9c_zk315$Xhe|(1
z0u|Lxx&d1rkzfl#@ki>?O)n2DZ<(K8@@Hjg{5T0Cvm;2dSt}_t7vqMkN2Jbl$4~S
zeQc%c$stuV$L@43KEy+?(Xx{kN_q5g0bbN6x=RZ&pDgQuE0e3^R=a@Uy`!~
zVSigzk#U&f;XJ3)Z-d`-zoTJKjjls-;N#_2wxx*p8_sE%^VDNg(EY33ov!bG16`fO
zY{;%TsYA+J?-p?rx>Y*_6uE6U-y4ClOF8FcgtqR{m)e*c*C3y}SWzfnX|uSRj}`K8
z6cf&bs3={4s#0A*g1@z3)@@G5jM)^}T7HSXL_r?@UO94?)^8ueQm%M{@{GYLUVV8i
zzgIEU-`0D&;DbDML-~9AHQrDg8MN8lsNGUEEpI4>++kQk|J2Xzd~Xdp?^8HMj#0$*
zt18Fo`OL7-Vn+45J|ZvZ<*iZuGzpQ4*WY;hIS3NQdZ$LDMe?Wi0
zjeABBe6z;nPpT=WJa7&~nYeMY&fi*Blm4_+)gUJ1OR$=f7a<}a8*?|9e~j06M5DcI
z68uajJBF9UU&oFN&XI3Kru%^cvPGJ!dIcj$GQgB)6jz5mCjDky?Z
z{dQ#anDMS!s#%S&2>;*-IyB&gZiR1F5?py1AML&Ld}scVPCKfGEKHEW;@Hw=>}rbd
ze)br4nMKBSDW83ymf>~YB@AJ;v+8aj;YsKA*f{miv#H>Csp)820TwJ67Tk^7mh-5B
zXDcsus-_KjAmZq2!jYXcED&o;rtj7je6NUQl&Cf`>>OAXjsAwuTeG`)#k!0`JPC@&
zS3x{P-2u*hDF|v&c}OU~G^1~>mt1$u0?!naLad9=vrtP(l@mtL@2&RPPJU+uZbX&&
zSk!_rj28tJS2}IDL?1`JPf059MYo#6NgC5C<{b6t
z8%M}8bG+wsE#2(@YlUmWl~_CPgiFIb6s9Zlmq(wQI@~3OorF=?h-#aiH^pYPIq4Fv
zl1gn*-z8>5%R?*2LJdLtkXqUPDIzt6-3u<>W4B^InrG~w3jb!0=j(tU&KqtWw17Qr
z9hdaYVW!~G^UY8AuW2_}TPCi%7>Tr!J^J-S-8Cuey57IZA>_7>bTBjcLs^tn?Vi4S
zZ~Ipsp~Wn%)##y=)YDv0IrOyqd3sGq4jWd+SE
z6v-ER>D%q~39Dx|c<6NaG|QT(#x`f?T(;Gs5ry2LPsqf5Yxk}yR5iUs&(XB$h3|u&
zsrk~~5o^A*PC7c7%m($}C(0*s@_sx&`!hF_CFrM@Um3(D;2m;YA6$HD_>!(#;Qx7$
za)C0Okbdu>{|RfX-s|TDR}ZAjY~-OY^xxc`RN92+Zw9Fg-mpzpRWrWy#!)4vW;$Jc
z8OG*eq@qWhfMM@rGQRK|Jxo3{Ox8O)
z2p>r+mJ=7~R%sra93d-^H_w$Lk{kQl8G&!8dIuwh`XL`3yN~m=xcct*$bQ4890V~d
z4H<-obI<5E?r-RjRh;&m2%zvOj@A6&O&3KYwo9nzM?E3JAtGRAsM;40%bmW9&rOMF
z2p$Q1GhvV&aqTxySrOA`in~42-nSxKPHa{e5p9O9m{gBd;PE|1ZIS1H48WnSW$cq3
z!2wZ}J-$SX^&lwLv4jf6xpZ=Y-?FWlmD|0>b>UfQO<&~rWyb6xVx-tCpMDaNg@&v-
zSvam0c(W?yUL5ok+mrJNuVx)(#1@KGB#ar`dvOsp^S)Z#bo=)=J~V*I>%n>RdLUPD;J0Tnf~sNd&{!~
zNe|kw5~aJY23q6I2P`Oy$_$LJO6-E^g;jZ{#?kl1PtZ&^;r7CnU8Eh1tM~%hbDuG18E~k?1izn|DjxJWM5F4RFTpBI*2OM6
zw;a7tu}kQ4pVn4zW59O}2(|I9`HFq1IS5kG>X-}gxFYzqrZaOn67QTNEt?Z+Qa
zF`f{A<)R}eduhL>xvp2Bo9w+5!5Y*Q;y%7xDBNNjHhmg1ktg7yds(Z5(aPnQRSKOF
ziy=7ThrFk53NaM>r8!PFu6yJr$&Wu$YaP;eml@9mOFuIi-VoqmAL=4FZERqGsHc%{
zYEY~lZMUE!mR)UHU)Tsqm5)nR$lZm=uuhE=qX?kV6_KSr=Usx(X}U!wY=RnE9sO2+
zVgh-$7-W6MlzFsSXqWU-N0xUko^4o~w_+zuhtCqQwzCLpzon*{w8dnzYoVL}9e#Eu(EUFlE
ztKs
z`0R4~C0HRr8hwl7sI_FAFISji2zjjOTmVC>Yeiq_iH{ycDUI9LHH%6v=bFwQLo{=5
zlae&vAW)=yf}YyAs)$zG5x3rr+P!84Eo0Ym
ztPsPr{#^p52c{P}evlO}#m7$)WcZR>%!g8cGMUWmQM2pbp3B!^hziMD?V=5@#LGjk
z*pb3HdcU)edVV4NG-+T)&H2|Eg^&7*BNa5;tlcoLY9HWX$fnJH#;kuN*&^T?L=?M{
zEh%%hV%TsPtrx^#&>JAgSHid-``-TOV2{kb#6zJ8jR5au%pFIaUEfL4pnHVT&d3>z1IsKaN9t?&-PCfFKH6yk_
z;c8pZsZlee#hbF{xt`($<$NPQ4TlfJ1n;o_Xg`hVn~f3=d$w
<6VB8$_nSo*CbOvjL5$|RctoSTR}AkD+|S{
z@EbWX$5Mj}1c&LVnzs9drEZ}_%=1l`ur-6E2&IH~QLZ>nD~
z6-`7JP#aIYRiZ{xrvs!mQ6hSfsW4Dt7Q0s2vc>May2It!c^C71{l-vwEJLjlb%%vS
z?#|s=N~u|m-|1B~4LanKXbeB69%x|heWGYJAM>N-D-%U}`IZYDc?nHRzHA%#X(q)e
ztz3#N{Yvh{Z=1&f>Mfy2>*-9t_11!QXBDmOhaaCKgX2
z<*cnY>>XoQv>hrvAC9zVByB9UhIk8&Tz4_o-CHKiEE@X1^iG;|$s7W5+|$AVuc
zl|_S!5@w#QMlhgU3<(ERK41;fS33Dp34Y4PCmBBAr0z*nV)s5{i|13GS|E;`)9@|V
zhwr{RsQdiSPpS0oM6_q@KIThmI{B{LecPX%cUb%wXipv
zp+Jj?9c2?z0zpQ&Ad_@w8XNq@n>!`sp!&X85j#j0?I_Fnw`tUSX-?+LMLpWD39g(Z
zDo9WH;Y4W~rqqfUqJM^Og730p_rQu1{fU2%DDsQHn?WyNTbcH-j(Sp*Mk{^Wk=@Ki
z3U>McQEjQAnRU@k@JAU1ia)|k^ri`t^lk-RhT(T-1ES?J-TqpDdM8?V+8ni!0x3{^
zcp#Qqi5|~(*Bv2qYM-X4)1Ij$*>7jjPuYrM(mhEUzEO#1=|n6)U!8rLTZZZ+
zUu65%A?cxnbDXsEc0ugxlH$iNUwFn!i|sn``oGj6p1*uEUIw*&?JUeHlPXQ13ZW(D
zhdb2v(v42z*VdvTnvN@`{1=qm7EVllzUHK`+JpEZWbBexc4bH+5%
z3o59>m%AgT&K|18b&zB}dhzeqnb9t3gY?hu@k1$VdpJK@?sS013)i_75~tJMHc?jm
zWl*#B%_WL3`0&`TCdRjDNN9JZ-e<2z`jE>WQuWY+cu{uogHF`Da+jdlFl$+LFSY-o
zIFIJ5>o38=EYGo+(MV9RgF-t!6&c9=lbT_?NuD>qrWUk=kFiDw{w!fiVf_H@)?g&c
zoTHX)Jk)<;U?0?v5VS$eLuJk`3#6!8^-7Ou17vx#H_aw{rh~GY
zF*&IHdz9J{>FtdEXLl$mv24pyhEoRx6>VxwH$Nt-;oRzy__0RaN)I?x!^!;(x#sPC
z6UNq+3q>vt+2{PZCP8{6_5&PE;m
zBUX2`mMj^Zf&VPyxojZSl7eX&m4$;%Mm_(qIDZ>ZCV{La=@HmQbQ~pBo)3{wZ`}X<
zO7FsDHPE_7TGFq@nGmdIV}zbj^-3>|86qy-rLKo&JSf@o=o>3xhC@x%9O>}me$IB)
zjPJ=`u&kCH`7$1`{?E4EPI5#OO<&*-Lh3hPX29=@WuVz`80KahUQIt)@gh~(HZy^L
zI09ZHN5f{%YXp-Xo`R@vGHDbyz`yv
z1=<6knF?;Jw`P!8>YuZIJ5N;9y8{o*{4dsA;%IxrJkA3=c&9w(95*_E?#e*gQ_6MU
z;I_=pZeM-=C+6lKJY8Jhp&=#9qy()mUc!qe(^VPg?>B|r%$+`b$&m~?>4>*o?X?Ca
zZcn>g{Jz+DGiRY5BLfWrR_ZR>BeuVT-h|$P@!Al~gZ83MX>LGAIhdP$Ym1WGGM=+N`*CL&4us$w83a6!fbl!EC
z7X0SMs?%Bfh~)-hK4_mQ#wh8{>i=_LDX`ociMgo*s4CMg{C4Z7VBc7Cb}*qt38*4M
zi=Hc0UmwJrr&d5s#8k$c97i_1cKTihim0{hNdQh|Pr`#stAwv#59N!rH`PH0Z}%0U
zL(l>b=!@(EPD6`J8|ZzHA+&1>BwOYkf>RXij_cfVuJZz=&(x~CqM~i^(~Hwaa&+Os
z5V5?*58A&&rRjod4#ndmYPRG4{1%R_bDR{(zW~1o4+vbo6ggiC=?3k5X^Vi>YH56eXz{y#;0NAypFJRmoznf20u=ay!=YIC`)O*zx=Z}N74a&83G#PXR^wC*R)%G9gpH@OoooH24+9dGAF
z%N)O$%I;n9^c~b9)3y!0P!;|8QK<%UlFGMCejlO!WR1*Bsd3WK{vtgWNMlSl8uV`%
zFl%od9||~P_4MSt-R4YyCIPFhCu2v0Boo>~@%Cnn96ss$HDyN6-F5&wNVAI*o_6VW
z+02UwPqR+{76w6rlXs_wk@N!^vc04a+-z1nf{DBJSqUh!7BI-Bg+^gz6yoqay{=k%
zV0u7h9~|NBxlfD!SG$lyIK^3agNO^R7B+GttM`wHcus;8xCwZgh{{Cid8kq=DW}8u
zLc#d{$&0Ffw7E)J0CkqTFzNAdxtnsGzcuu+mo{mrh{MZS)hOh!z->R%0T)38yQl8f
z-7Z#nxKNhRqw8Fzd(tFSJ`<~sL%`nIfTS(~cukwNPyNfRmTCQ|Xeb12<*~f(sAu*t
z;z9)lnzXg$o(aB1-SP?>_r81LM{hpQcOsucw08b6_m^9x5kP-|gR^Bb|Ci%*`rBs-
z7=pJ~pmYoTb|2W1#=T(XPHjgU?1+zyx<-%gk5RSq*|+^H%79e{+-&o{8fTLVU3n`<
zfW2K-t41m0kg9ZYAh?Gh#5o4|;P2dh)ZbF%PA;+@IZkJLBBNY-scghWor2`TJ-nCfOpcyJ$hol*4$zuKUTc}-!jHg{UiQX;~GwpMnBR;?m#mM
z+KOH?l>u2f$klEmVJVPNfYdxR%ed+G>Z^CXO<=g{dlZB5PeZ%%*wI+J@=s0cLb^2^
zaTk0d*WZMplwVS_kq1nFfT_ZzhEOW5}7N@
zs}lvP7=AJf#;${FDM_tN6O`6@pYn9>zN_FA^N
ze^{Yd-T*lPAqTLYkVI7>?8Mngd(z`=lIVWZ$r2tTmfja14+DYaxx!gxCSnarZI~EB
zFdimKi@WjV`j@uk^Ccf9alLSEzgTw}*Hmn7W-=}{Hii6S=TLE^-Of9
zsvCw%C{CoW-3ZiZFd85kmhn%FDXq0!0`9W6>pxT4OWfLF7%ed|^I0&xSF)?QWBv|-
z`#C+nNk^9?!U%qUVA!ZWEN_9J#E)FFgH)72?#uPWkL3Y^A637*(aarldb7JNcZdi)
zlFZ8q#blu^ocv9=oK?~irf1?u&Za(C8(MFQOMDdf4ZUTXWOgT7F5=zWlc@(&ce#T2|<
zj2fho+pOOWE;NBq-GojMd>>p@v+hV@rt9lK=Q-FLsd}g2Zd(@$U|epD1FTT0VZ_Fo
zm+`b$2LB+XDAw#vEq<(T4*RfoL&xd8=dNQ!{mD(w-+>E-UP#9J*RcztQKt9_O=7GK
zI}R^5F8a?6V^ThO{W2Bkip;B^TtNuNo;w}f;#&U-e(ZKHAu{fu^W));13!Wb5-S9@
zN6z`)n~wV)Ra!2S`j+^@t2que-&$rkqO9K?7?Bm7e^dVtHj|dkWkuO}GT^WS0#~|Q
zeMht5keXM`Yst8`_>NN2*K<#bh5IvA|Yb7@4Em3N4*0$ue)=K;E}
zc+~6f8N=0p1<->@DiGCD-bsqqs{&Rw!L#MRgSnznMo9fWUpZI`Aq;1V7kMBKRImJl
zcP1NHwuBl|2}l*zC1QpzQG!iN8*215Icw(CARchAJI)b2xJ${Q@yu7cgKtEQF?%`
zTzV?s-1ugQ2-|fN(U5nwZK{dpfX}7^?*xVNd19QR>ZAHBLrYV{#~e}-lr`xtpNb*Ng^>d9Lcad$w!CikfvxZRYHEPgp1)8FMUxrF6+o^R;y{zbcY|^Zf15t2XamdI0tglED
z+xN*Q;2hC?OP_aDbWYuDLmOdvet5u)cN!_ANe^TwyDqWZEbRMl2=$DqOMSV2x?hc;
zYoB$Wu7dowNdC^o=F`r^7WqE-zlOn<*jDi2D;j3HsT|*!rb1%F7+)7iC2%$Rl-<@Q~QnDRPL7a~4^l*F4#Lv??=lvDOY>czmVaZdZ`#2+>E-{v1d;dNg>5YmC
zXeHSj-^bm-Y04yy-2+PDHg(dZ#Wi=W1S@8sC}UB#g7J+IBhVSS8}M<|;Oa>Rc=en9
zez4rg<`9UIIQ=(jmY%~Ri;IF%t}vWUqXt;u{&Z?ORQO?yKL_d6YcQAta(P?U#8AUj
z0AuEKzAK<$!;bpjKPO5yBd;U|^a%zz>Pd+{L%0EUCFND^P5*7fz1xQLmqHG}uGr{<
z9uv0)_j!Ne2{bgn>fEbE?LWq>(_Ddpr}IT}KCg$XH;5--VBfaIL?Pjx2VIyE0G
z0-OJfPb5bO!0H)MW~_dme&yh*>l)9v17;%OD#~0vI7)T9`3l8hFfRAOuKBcI@F47L
z&bgy%_EqUc^Ok(D(?r!>92Eh}}}nwzgtBHT{(`ZKkR37)Z_W
zy0CLz-6T*8vJZ%EmpQR_U1oxdw1ChEwf=t4-)g8aeBj%5y0^@^-p*Nnlw?Nk%o|>M
zebnEV3tG6wOkt^`Kv834d1X2*&a+A%qrmXC?Q899B10)6SD?5Wt0l4VUc+74+!tII@byT$+Olw
zD%5HPW2X**g?vfS+Wp?4Tcqb1>?tUw_w`n4YgxGCLbVA9c%tIoT?cqKXK&dm`&G$j
zV=bDFI&ZJF?q|LWPliYe|E?<@4H}V?Nv9wr6}k^TV0M0-^M{7cbLsAn?`~oDbX|fx
zK`?%bzLjn#?^zL-Sj5#ZWAIdG@5*Bb1S`Nl47Kv-J{fhx*OIt(4X|PV(^}xTg+oCb
zjY-12r7&w}3mTr_U8^E-$Ms8Y-ph64VZ54fh&>W;G;qI2Bq
z0Baqfdw`Y=jVOwumCftvzg(wSq99`nq_lk*WP|Gmy4jGdH}2_dP^Tpla{S4M3L
z=#{F0$NizV(82dtsTqEvx};YlZ8|eq0x9a3=f?63W!z||(P94T+UTgM4ulZ^vG~9}
z;_vzu%D&s)$O%|PxA4d^XIub%BPkoEUn>VR7cx##aNCjfy1)LfHI2pUv4rsdjzT0<
z?*nN~!UXXnB@y8BOrk=gmbqJZNQ9=%LwLtj_?vYp#VngWceM3E(J6o|bo0Na;;x!V
zm(s)T0z0KA0;G2r=%OnZ${S|c9U5k=A)tp>h5D8B$3N{Jt@jug{$i*Sv0j+iHQx~;h7yhT1XSK{kgnO49tJx_u
zMr`fYx1hxZ1YQw9h-b7Ta0+PQ{1bfxt#*Ve>&a_iX^8sBQvY?CA$UO^XcowtJ?qu4
z@0L?KuC1DYC-1h1;UaISo6!czBbo^jY`nu?3?VGlb11h=+#Op6siBUOwolW9_65*A
zuhEMmiKDMfH}V^GS+s+0NU3|2
z#^$3w4nM{P0F}rAVPt6*8ZSMN+Be;|O#2Pr1ca92SlbOdR;AJV|!4{
zPVIx45d$G^=W_xwWu7l}9oKC;7nMsgSjrYp{#wNFJC+c2hL0!9p6kQA5pVm62ldR{
zb(&ze!Ml#0$wZ^U3UB!th7Pav2%xrP*#wElCq(56@7PZy@{Y-XTfOcvVh9}@I
z2msCPlnOLId`42F7gl6&C`mvB?DmB{g~WFmE?r*xcKPL7u#mzV6wH
z(#EuYSYd!=Tjce;LHi
z+^5ng)uFQp`T+5H&y~1kWDJi7X|$^Fg21h|Ui-8!09oK3eW(|AQUUgI{$M+095_p1
zOIfHsUZ>z()dC1i+ovAHU;}KocF;}#o0k(XPLPt%MXwatCGJ;Zk(FWnd>7zTd~l*9
zxrAC`F3lMJm;f7Eb#nF8aJ3Y%qA7yL2|fmE
zoj&Z45-yI4#`dNPL(5f@FOwxN%GIiQ`Xu)RsQxey)ZF_C3>?+alMR|F0#~I8Q0__6
zezmY4-n^d4uky;M^pTU~Mh)=h?JbptW~)-XTV>8770>HU0GOTE<7!O!*^A;NX7G++
z?lTA<_>Do<=@;pa|EpHDgQVExraome7Bw;7!X`eHwmltFuP=K?medlJr5f5LugLDT
z@?4itz7?L=U1_4ldrH+2klB=E)*JQ@MC59_S1;l&7!8e9GmA007~Jf36pSy`h;c1Z
z5L6reW)J1)pxWJ{lrF@PUz_ZpjEq^lpyr`!r2NC1*aQF#45R=^b@d@(Rp8o8pP!ZU
zI!v!RNy>1`TN-QX?~81ilz43Q_m8wXh=PVKea;FE-mT@bTtlC;JTgFjty#vcoT5#b
z^Ehl^YxWkN7<A9HJaTv#2xS}y+t|6HmWtL1iScso43
zQz_Iq%rH|+umsH5^mfL!dWbvhI&AEXzv0rxCqp)Es}X4ovIn<-bKA}u+=Wgdd(Mv;
z_7%;Up0(BW9f&U;TQRT`=d393pSLRhoewS8C>kc=$cl_Fb>-1AhVdTlT^^ZDoB1&?
zIYLRw%2&G%6+Zl3KZSTkD=}=*wxtddzZg_D3Cm~G{{MYGQ>ka*
zW`<`twLHoMW^DNu+S->@hvy(g&*ojH)bqxsbp?924ECES&$M^PDVl%%&&>MFzAWhG
zk#CF>V1Rm$clV!8$@AFjoIdN9jIHeW?fs9iG+<_F7C|ev+p8P~{+%M+UW)9q<_V~^
z(Ya7M>?2xAsyv$A)=4o_s3bT2UzwiGfSj24>s2NC{p?0Ar4*310SS1q^Gm9oNN9QQ
z#BaK@+0Q(EV;$}foz}WF(@GbeZV$H|W(YG8;wygF_BAfuj{+8dkTvn8S7?A3nFpbx
z_>dlVC#NPgTq6a7KXr&<9P$bH{oSU~PqLb1C7Rkh?FXe6(u*!eaVs9YL{`_op-5eS
zDhl>i5Q5Yn=#C@DC)j!)iTZIltqB(pHcp6C+#Y-C2@!eLN_hFTbzQ0Dog{X$B%?nT
z4BRDGu|~57!P+3qC}W$2kjd_J{VAZoVH*GmZZ4arN%jE=K45Re&;HpP+3K&A|1%HU
zzw>D0z5nC*bpcB|2${P9n%$e?EVB$+kj3R9JAcK!eWwo=!4P_*!Tfg~2Ic=N^T7IY
zO<6h}^5+&BlK!k>yv_dr^4ERRpxC8jxyJa?XWqWJolWk~WEwC+;UyyFy^i-@LDeQc
zO}=0b5>ar%GDV>9!dD~-`gcV7ryPQ4=Y~MJ18oJBwd)a}8+h^PCFjKwpQ$K2P%Mo6
z1h?ouzuaE9UVEQ?rRcjKG?DCN@_E$q@IBlPc8pbgu6r8&4bL+SsFAqELrBWX~$wt{*3#l>C2e2bCX`9dH-_mt(Rzfq(vg->j5T
zisGYwh$H}Co6Xcm2>!q_*dZVj>
zKDyZRQ_RUob5Aux6$R?N0agxt+7lY2xG$p^Yo+&%3k6h8>en&-Efb{iXnnfmOm#q8$7g&cauk{#q|+O^yM
z#oU{$Xnnnv>^oI->wO%RCzk0{`_q;=qy~V7zT^cArWiJw#Ur1R5fx~-(CsL*zvc!{
zg}Gn7lO8w*ZVb@~St(85wQE1Eue{((xkbXM94sj{3p*{Ow2|axpHu=
z-&@P0V&|G&9@PwLm;7ifrYteW7GYpVQ_ZeshLGZc)`tI{J5mF!myF{VVo@k18WM=9T2dn-`SPs@i!j#Wrgw2
zXfvX@>SF?E3^=2^GM;~K&Is)*zj!RT<+J&zNd29Zthq4}8+B`L3gMJz=o9*Fvk^Qq
zzh4u}0Li+S^Ujq)NjPAYp^!of}6Sf>dPxm)#n{&O&3IR1RrIp{y
z)g<65f5+M<0;d97k-=K#HZG+e5?P5oxIP~Kr!eHUXy&%&0;fA1pMxxXnHjt1OKC!0
zDyTz~tJXyns!TTfPS%%G(+=W#jIRY@(orhJQQx}-idAdLMwh1Xx1`f-2h`X_&FG{BD
z?a^~Q3|V-flO-vQpBErb!vO=ya=q&u0FET6G%!Bz6>cZCPK98wsu{bp%V))B*AGA2
z(CWFyXKoiY`+gM0>i2HS{Ns$US2n*^cQ+&&}Tf*Ons^
ze`;ET`t+zebYNdpPG28-e>SmcSPXOL8F0#Wo-4b#tm%i1{kgU|kEdm?2hWkh@9FAy
zHR{XRK8*Vgzqt2LZB}RqIA*MwEfv}?L}_m}*@)u#vP6D%qd
zyitD8{^|HIEv4_>a4kGCX8V}7O(EEU%%wX3p@J}ASDi{jAe?B
zbNQyTMW1egF%{Bykf*8w-gc_dV4FUu>0w*9CBL57RlPy%iG%NLvf?o8dC2e;f`A92fUOaf=U?~4Q>OIL1I)0ZF~Zbj$sgy8~Sc&wq1^~xzAV@4_;
z+BrKGzjNgabE9~%UVJ@HM&t^6t=X*}v$gE2O3J&<;+OW?4-;;C9RGZJEnevtW#F@0
zOB+PVT!IV#@Q&VUBf|O|&|)|##;>0>fz0!D(|VGg=?ofjW#{7r&spG;gtQG)4&#KT
z6_OF6Fe8X2hYv|K0)2O=5ZL*RDw^>R$RUCDA`Psze;7f)kF3pAK@_UN1qIGxnvt`4
z^*zYA2!zoRJjD^s%5QqQ`+-!Q?~BMlYd%Ul@*MR>Gy!7VexCjsFYKs6iyrncA;h+4
zIl9#5Tpn_GEb;}mQsr?_A=o{;#Ac{-BQkuRep22y!k*xJndoxIsN9M75fnsQI
zptxiHYPYvsBSWc^%!I8FSluoyVT^(d@k&0P!}|BDD;#anKTNMa5V3V|V%EO_K^pa3
z=_8D_0&(XrzjT)(tp#8^yj|Z){>c#d)la|#Ojt|V@%@Q0Oh*X?~V@^O`t9%pUv-shj?Ri7>2$IwP_
zIMEccar)C0>v_^l5-jdw)AWH3wO%CoSGw14ieLDq6f@33C82%3zS-a|*hN>Y_@0Q<
zPu_3I*8y(=($J8PuU{>1d99|vlW%8jN}+RES3&=)=htnJ>jF5ca8NJ|LoldZ5QuIv
z8Qshgkb6)ful
zxwlmcJD@jE1xt3rw!L^xgTeCU?F>1PEClustB5KqFJioQcim0jmZT&EF)7v=c)4nd
zd5Cd~#48)(cM{&FZ!w&24Ok+T-4J*YfT0UfljYikW)8
zT!ych4*3gpXofM1UZ-w9sn^+<;{L=pN+cE6w5ErYv5WeAvZHoq;n~Aw%Z?ZfibC-T
zq_nad_GrCtcBx-5y4BiD&&c2?x!LnMc$g24R_1wHh5hQQYXRgFLzy+EimiHLMY31d
zVgaMA3!bx0FHGa!TI;z>XUNysFoY$Vwc7v6IpVdv02%wsSe7DRu<|K6N@pNFDm(xh
z&M)-wcxNkD5P0f_#(Y1S1i2&UciTVQK=$738dHC7RGJK`5b;^Y=RL}VF&8@?VNnp`^?Dih87=oDY3Ywjgly{@wLPABnfOHY`{CFJ
z=BbY;fyUg84i+bEp?(@`20
zqjzp)gWX`zZH$Cdn4OUR^an)qxks*f3Zj5&t%)ujZoiRMFCDX3a-IKGQCkr2!-EUI
zTd#bDF(sp%H1u$P99q&1>hK!>Nyk^TU%vWLoNC8@>i1Gcu6-p!*C)$P@@!~+qrcF{
z*Pr^p-Aurf4ElawMLwnJkRL|1v^mbA-wU;zg^I%9q*EU^n$K6LTdq4z1&#%jitmz(
ziYEkwHlq@@ezMcMpH+9nLg3aJljGS<5iZUusphpw1wmGy&i^?c{<%K(NWy>dUBVGu
zaRkMP24&$XDOCb<%zHxt*M&I|yCgyZ?e_czl~=~b7#*02O1XjITVF}t3K@;##Q~B`
z33J&b)z#kf_U3MJ(G*V#Q}m+a$~F3y6yD_h(Ek%=#meQ9slZAdRA18gXP6bu)N%R2
z@R-{nfuDc=*yH9xRHnixzA%ilgQ5*S6W9?qy@GGw*M!S;3WVmDUPw!_I$h6L!hwQV
zMg5_#(F1%hVcU`4_pcD!H}?X1j_I+XCRSQrzcPJ_@5AkkPkTaaB(fHHE+j0+WuL11
z8?+gU>^}tg%P_Z{xM2v*@c_TN2&jzd206k(-j!H>h1Buy^_M?7t8@mohV7jVOOIl*
zCsgO3JrcQC`KRjq%~wp1@GXX8V{g`(iO;Y7z;;~;Ih=#{tOq8n`XjvkoVDkBO0QDs;X0J})FHwCoiLpBC$K-eBSzkPoXDmMEZu0h=2A|>LeMe$^XxC9t-=R=?&)ZyP
z(*wAe|Nmj?ETf`&!!1rpNXuV3MF)d!$w5kG2t|=@h8byT7`ht-W$1JOX&8o(?id;c
z2BeXe?z+c&zua}c!dmAnUfy%wy?=W@SnZq4x_#%rPD_b4ndI_&U0s232L~j4H(yqN
zMytGGZtt{+Nmj{lH2D>4Dxj%pCtT)zpPS>u;`=M8)mU|%`m+)yyM4Nz_qyq2k0~HD
zzaCo~{?a$ZImf(!7>Gu6Xo`{+{4O$bq>kN}HT$#_c1o?waoVLg3O
zEg8LKF6a5y+pqrP-y`2Xfhaz&Ge84&*Ca794QSf?=SG$_9=u+2&2atY!KLB)v`dfg1_D~(}^9Mfst^Ofn?eDbJf7-?8Yjmd?vGv#|W}=ZF
zDwNq{2RE5`_w?{yd3i9D3$b^uu}jPPjsO`9bivxocf{FkIW;DL>ead@6)1VnrlOU%vYT+dC|&q&)%)qCo3zm!IM&tF
z-?2|_s=kHMBjRIyy!r~lsrx(PtdkUW*><(D)yhJXKCI!M8@_!1t-AZ+>TE`;w|_ie
zoaGy_p94;Cdw@aP)sxY~?#+wXGMK-MeC_yv&4*=G$MXO_@OR+gX_Uz$fZ2Jk#q8k(
z*r$7&`6kaJrQ49Slw&UJF0Gx*kJkXhWjxM}UC2B*i=`!RM_s0glGtaouk#A+ZS;nPedAhQ#AzZ!k{uGEKulnbT-s9ol*^E>`E1E-
z4e%0K9I9Sr$e_iLx5wpvuC{;*17C~!ExW#bK6Tdrp?T?tH#kVpV?i}TkW>D0ySkZ!
z$NN((lL+V^$;wZ}Th;r3|E0xYOw%c#9sYdR>JO4>0=Q}43p(x3h{uBDt$4v&JTk3u
zga(pzR)ABTIUMJE#4TSJ;+7L&;PD3bEyN)>88|ris5=6ucXfI8bQxXFAiRFlI8!`!
z00Ivq_e?qj{uzY1YPv}X&nH`&qp8>bL894>llMsnZG4xHT0(mi<-BgUcWfil)m{YRlxTk-wr*hVwPryAse6RVH9s%
zQbT->7VLKdnD`%#egIzIz;r)wz$}dI4~NL>g2sNJ6lGyl2
zNyiR5fVeXo;Hy2l$X91~>ZF~^)Byw|$6l_mv;7k%FU^T#>SkJ<6f2Pr=`&q3
z_EmOQ-D5dX;6nv_=SL*-q-k_lMSn@qkZt?`3>F%0Y5IOK{%&AGAMVo7vv?i
znR3w#fXr3@;z`wQk3`l~``rP3R^PxtD$O~zzJ!+?I^b(l51{kEdI58`%Qm8`(p!!cM1B=tXBN;$(%Zt+9}i!LP<%@SYC2GT|{Cx@^ttg({Te;WWL0ZNhYt
z!^zN$gY|CHr9G769s4|bWKIJna1roCKC>;6Y-O$tW^*yU4S~LJAm;d3jVi_38Yp#G
z1s6z|$w+S&<_XhXW%%`jS+cJSWj+$3LJq4Eli}Lcx0fxq1GWQQSUKZO#!a>l%zxDv
zPQ*3XaG9$qWF6DMVffFE>TW>4l?Z!^kEut-q5Xf?9wdMsn}sEEaZp>~>TyMArZof1
zmIz&T^`o!4?dLqyo1eWNV&y(I+H1({ciJAUkEZyvS{9dM^x2&Evrj1zZN@T(!10Io
z=>EURpzvjU-@2mhBw@MDW}lo?<6wL7vPGjW?QMzBJq@;$w{2VZ(*Xoy&&x;)6ZK}`sU^?tYy!ozDU)&CFk
zLpowZ#l8t1W>Y$lVH!NB!3KgHQn83QNy@9W7D^0$^~2*`y{RNW3$r<$ZO1=YN?)JO
zr9;m;V|Bc^vnD~L(F#g2b(j;OG#>eigc*dEfO++qh<>4#vm)^pEp7p@4WG$-=ptDA
z2>;*OdEa9+tj_+&F~;#9HhSB5GhdOKp;QwCS5CQmi{10=5FLPdjfMw3vj2Af!(H!d
zSh;DSR&oTX6?rW8zHZLYFLk6@tB6M>m}Hz3y|agJ3_{m|;-t(X-D1Rkk%CsdnCTuj
z-pEyMY?P`8^*0wHG1%Cg_FLxTYB{Ymj0;nPM
z+j+y*0V5CZb!$@T&x%wBGTmoPcWfv7XB}c1=Uoq+>u4jO`sbLH_bfqp_hPkv%+-F`77zsl&`bvYj-k#d^n8W~^jYrg-bN
zzmMRhG^InQ$l@5#8-$}gzD&%z>a>3KxCfBS&Fg-~QimGPDUeVK?QjeV@5G;OBQ0W`
zF7lrPJ4K*RtCRy;8tTzITI*4)130r@*2`_uPl&6(KK9g7
zq_tIX#Th%L5VQPNxREqW+pBEQaVPXk6UwI;&PSTKj3bJTz8Ynm5pA&X7YA|>SR$p#
zi9J?p!a$qEkp`To8;I}GRjYI=7rG4;4h0w-XE)$W6bU+2)Kp84Q+E#U?nP-Cv1l}P
zT8)bNZeuYLKUO}g8FDM0kMw8%{K75A{Ddyh@Gt^8h$T!Z1y;~=
z9G#GCAZw2t6ugF@DzoIIk0-{}f1KH#Z15yW49Kxurr5kxUw7Pj=$V@!!6h#eFj4b+
zEH#(%j!mYJw|^)*pES-^^k^yWlUDaXiN2_3d3vs}j4QtpM(hNegP6Ke^i5(}gy}e&
z_}eVzv^_Tw>=#dmkS(p>b)UM!vLYS*Q*
zUK{zg9Rr)g>B6^*cZPpcoWP0{L!AY(+9aQxJY5Dw=3a?*!X_3orn8VdB9Fe?xbIku
zSSJ)(z&eMvgg(&YSoFQ-p5VUuqo
z-hNWf$jm&h&0+{o(GfE+--UJ6dhj-=f}`)4kN-Cr!u73#gqoP&cR|HEcH|>-Z*<#`
zsGhx>8MC|Qurr5$URzvS7JkB><{%H1HU_nGfJWL2E_7(iWFzT+F5lD0OyYKX`a!NS
z5*)2H@J;~5OtFp1`81Etp9WehHaOHjlJD`UK8K`jZ9oXuH)slJV`(U8P)V_EYylo+
z_08$(!uysWrQ2R>7PvWSH$SW2O$ZriH-*MAf(&GX%obC|04$9ax9XgY3va_U#2|&s
z68UTNjze|RF|{O4(6i|3Z13*e3S~EG7cxuGO3i1wB=G*XP;RRPur2Nx1A?jZJ;}%m
zn99o~!q0KUa)N>)Z7xC9pNtud8j&%@@;$46Ve}_mLyI*b(A@YS$y3dR<;N%F=d^EEaTLLA2db+m~EFU3Du{)
zKQ0ZhLWI{G+(b9t`i5am{q`zM{)($wPwe(($4dBVf>iFUHcnE#z*GGQMDdSo%Ef*XfW>%=c?7-Xe)(gFqhH>6XCtU
zFMPpH3N&VsM-EQ{_&VO0r(?R04?%r{KZ9{~#a1H9&QyO`}@?hCAjUhjZJIQ|^{v+~0!w
zIhLrpDMlsc!&N1UOT{1>b=E8&+YbPmakf*IiPkpdHTG_a)AzV30Ky0$Vw*B@b3#5C
z5J3sI{5IQTh-Q%{f*`;Cz>yI3r_5j?1LzCKz4|^-TAiR0+XKj}><^w#M2`Da@d!Ze
z^2`EqrZk^c-!aU_F^Qn~WoAavWxtd6%Dj@OsrUM?ffvlC2s>#jOzjDe2nm*R>OlpT
z{!=nX6;GMCdhqwy!csxtO>Pt(Icc!St)h1?-{$kEM^Dl5R4^gQ?zStn^i
z%UPE|Itte3F4J4QRe<;+!Ql!0xFA9?@$6V>CV|`dP18LPb7olA_z#tt&Tf_fMzjA6
z%m(ZB?BB$RHPpB>OMBUtz&Vma;uM38M)?jF%fEvu)aQf*^R6U4zWH_0cFW2iEXfJb
z9Gc}Hcs{sP)pN{$bHQlhH>G+TOm^NS-@Zz^=99C1h_fYe8$-CHL_|%7T`26AxB!X0
zqklyOr^Gc$C>y~-S3{S6DEXT97Vn(7(*%&l$xN}!Chyt|{t545n*;k-jS~owQ$C{L
z%7%^PlsNSai%sPKuD9ia)yIou(97PH&dO?q*gB!u+2w2>K(4to=Z8@09(BLqYL5`$
z!R|+8(w3Q|6UY4N!c>GkaU^0xeQQ&T6{To|mexovgy
zZ!a}vg$83iNdmcWZ;AYfZ3OXbJV^3rG2t;AZlY^Xi~I4#L=8y4!NzIB?bf3C+Zu|g
z8uqyUB84mrNx|At;ONl06fi`Nbdod~a++pWyy(_kOGf{Y>so>?i{M42-6Z1neboYAZhQUPGL97MZSXnyFG
z$qAtejvJ@l|JtCPHPow5dNjO)Oq*?kIZG-R3p+S}4CYkX>u%%N729{rU(4Ga_7kVv
ze_H(R7fm92TT@zJFq!ul^f28$Pzn#ovYa*tUL^@MuBTqCs7kdT5(t6lf}9E^0njoVskYT&$&Ia$PFp%Uxcq-Vuo?6O3GVn%qxE(AM<#CK8K
zRq7o1o#?3tDT>g=)b-JZ4vLG%l71vrAHxdy_narj;*Zn&|EvkpsI~#q`XE?u20+`!
ztYn>-M@i%_*mJfx^!Xv|jCGY<)?UuQ*;+z+si^u}@>HS>=rkq!
z1UYPE5JISAkviGBNW9BE^2ijBbKT
zzN7=MZ<%a|Wl}u<)`T$j)mbmNSE=_KBv}v2D2uBI*O&f#Mg{ijpL)l3L_8=g{-+^4E8oNWBQks#d$3=oCD#vTJxHb$+V~ek>4`!dM>#Dr7g$#c7|OgLx$W{?
zXP$$9NDA@&msvQ%V7I#gT5|0eue>w49L;9QmynA0kCh?P-SBy1DfJNj5UDZs-DWD4oR$%=Xi#Ic;T8n}VMCb#&$@$bh#uQ2jXHASaaEB1K*pB6BIHA0X3X2j
z+C_1mz$hDh%hAt7e5(a6_o()AmI>7+Iq7;zAJF98vD9b7rvTa~w?vb!c9Y3=+dJ*Z#Df)&zvx`88;|UtS-D!cs2pgUq0A+M0wnd(EMpn|Q
z1i!x@E=zYAh8JE>^n#0n8JSt3OH;~?7W|o=Ii(U)O8m$$kw*jZQZZVvuE{PZOkFr?
z!ZypmuU1GxVSNHZ3NLzgpvbAzy1dL~tgFKM{9vmTOcA$m7d4`wwQ96zLFs!gn9uKP
z1${8}8#mO0L$7I{w)?>=%y7rUIIpt(JnX=hmeA)c
zn!-rH@GE}sWvNEVe+a3-piUGdracu?UtjA+DubZL>
z>9t42!{IXqf!-$oawgw^phYC5EG1nsWGC%G)6Ho6fCn<0u@der@8dlsf6rZx!Ahxh;4gS<-jEi
zs@S+N66!}rpoPYSn1)?V3|+TGH5`=*GI02P4AJ%OT2IT?f5RE-7tD?>Cq+y}-E0EG
z{8(wxf{(y-VU$AEM5I9z&m|8m)&gfBy2{xqGa=$^d{2*ioEN#XD!vm`9)JxZH`?xs
zcR^Spci^-mZOklwaypgIP#N^kMcWakIrSkX+hdD~J|Cy;0^Pb*$^SfGiODO$-2Y16
ziG)ni>oJM1E5{1QMu8z-2YGz^d901@NO4Y?(c5gcH8#_PP2lLZTunjRv-APk7w1Is
zY_p;_RChIEBuA!}}i{&+S(6jZ{|L
z-*YXClMrfYIY+H~Q<&J}IMt`D3hiSl(?2D)pm
z8l_ADP29YU!o6$Sje+Q&Sa&^XqU>$H{SN2#xz!t=J-;bB9Fi{I?fIx(=bQR<`iqqM
zS-iHMOPnU7RgK+v`>vhehZEHrCjW{i;HEZ$S?QvxGx*!bF}L5zsxsxh`-~lL?kvt@
zCb#O>s;t-5eT4z(fo=VAB^5Jx`W{1Qh?qC0Tk)aRIcc=w(4kvE2*6I%YVc<@*Oo0M
z$KB42F_^T7#RHuwi&NQcmvZe4k`wb9h0(ZmpP`dPu{6aQ!V{f>+TplUvaQmVObfg5
z^2Nfu*dw|Xpc&%6LmrCHl^GS_+%he{XIgGrO?#SnTxfF=E>>E|5n~gWx65RUvzQNJ
z!cNCc22;*I!v*usyHBD^jr~yXsWDxdS=lJr;^nKNAR)}K1W!$h=Lnc_*Jm-8PcZEIw25iEGmq#>Pgx2q4u
z)B0-@Z|M)l=gaDr?#_2GZEr76o*H7}7_EEI$Y$zFvd$qAE78Rkmg3nF`zMJ$TET#K
z*rjQeXQUvod(c>9_m*QM=kM9*pPisCO<@tUnNt_kAdc%vEYofr{Ll3SxFUzIo674d
zn>uzo&K7#NSyjlJ-uWK);d+vHMvslsa2`Bfwf)Di75Tw6M`^M=|LBEom7qd0
z9?qCuW>g7T7-NkQizcY^%VayFli=yM^X9l2pXx`+=<)48S5@%hNnwMj%jkLP=zSB
zVFKz2PJV%iF5GNZG}-om*$d1Km7$C~(##(>jjy_HE<>N~L^cZbWH-N}=3~XZ!O>UK
z!2VR4gtG72mf#12F5hdbUBhY4+__
zwML*`4ppghD`xZ2lknd+Kl=~ckwO62e}PA68@{NB(-ggeg?XxQwC1Yd*yL>+U1Q?T
zDN`Ni>|iTmoeR;wOs;7+;E4@AMB$h_s3im6S-FP$7OW20yQ|-@C(G<~(h%*5+5o~`>pdEeYk8PRS5|u%ua?D_JR;CpuNg7T)NLQpc(UV}7184%xIF6!|
zRH!S+B!)UuXm#-2BLX&peYct2_$F%tAtR(7v!z4hxtrUTU9ELgYIc2VAh{LE)k?v1
z+KIwZ{g>s)XXQg*Ykq^ELLy;`zHYFS-g%C}o6|PcX>I7+%8;F^iiHmh{ccqu@L}1o
zkx;&)#Lz)s@!ztwWSlH%M*F+bs;Ii@%*{szF0PqmUd~f;ogKDjGn3eoC6eh(?`^C0
z+p=jXn{u1>;l}A`5iD|0=#mu_?b|~w8mcm*@Iru@0%(_Mq`#QAK(}
zRe9FeHHPM;_Z@OyQiBDOueJ)IdU#aK!YSYpaQq7zZgv6^yAJe!$9BUIZ{4h$_cuP_59k@DxA)~OsKq(o$!DRED+qKxt3VcDG|R67wE7_%~i{VSdV#QAzI
z>t4(b=nthSemQ9mFM;xU2r&mK`oo?ACn_DSO|Njzc!ef2tBP7gZqGyWrS^MH`nZD-
z{N~LlBYnZ2?U`B4B!^_dDmbA(O15latuKFfZ@9*g5uYp~A)GYahKI)V&&T39!fHy)
z+gXtNLXngL!wc2Dv{cl*AS`+3M~6yq^b=ZnB1@04xGU1-<@}eND7J(2n;;I|V%bln
z-rF5;0n^8}tCPX0xo@Kl7|*nHaQEfT|7Eqylyb`ch>kz_@9B|ZRSLc4;MJz#bl58v
zzn>c@q!e6%#eWl
zg6z)>+dDCExD-7OfZhubQ4ra-0TGRBO4!w%#^tp?N;batx9&Q&Vzc%GB@n%SFF5mS
zZ={1d1nA@)I`bCUuDGT$dqz$YwU+5KgrzOpw@7cntV{yn9sTTdD(A1_}?%$rK#g6~LJyt(d_{6rZm31M#Su(j#<=R%Gju*Ss{MUy>{Team-_H_{f
z5xAvhXeMjR=UZ&fxtZ-R`=~FFqH^3yB<-h(SmKtMR&Qe1WgF~;%~GKv=aSz?ECXd!
z(&~GG2W1w7`#V4$LC6i|F^pp?gKxS(y55;cgqAf(X>#6Z$xJw4I?~7V{LMD1k5b%V
zu@Og-o#s0gd25R4^36w+@!8W`oebC$m=Wk!*v+M%K1d`xTg~XOTmo7{KP8gUg_NUHRvViE;Sl^?K_8)gFa}qfY$y!ekUd{YI}d4LZuVMxBq`
zt7eSYsZNChA2efa;Y~kjif8k!Bj=^evVK|4Lqsh+Wy0f5lsAqV-@geT&TQQ7_b0o9
zd#E!i??ApfqTl8E!fH0JBa=?A=+7ud?#NC4|m7T
ziBSqAsqd#Y-ONi=r`g}wVS3HgEY)yj_j*{}5hp`GP;F>yO__5Sx9xo%%R{X60|U47
z`&G_EvhvC8NoI4#%n?83N1dKVp)@zGt&4F?fG|*PZAe
zm{Y;9Pl%(%9%$}f-L7>cl#+4|n0ocw_QlQ@;U0OxMJ9RHQyA;$MDDpVw>4(OwPZxf
zpmx(P1(gc)^}kkcjp+m
zo+}F-C}$)b&feniG;MHR2#_ze;nSmFTrRgU8^y-Ki&^)+Hxv6#`*aW)NGK4{(a+>e
zzfVbuMJ%Q@#ENw`swz`8kKn3pNKle!0rXL0^+##t4N`8ZKUOfsBI`M)F<8PgX7lx&
zMXQ+_YrA6UW3F~Z$u7@5iX9PG|Drp`y}43*G@zBmD?P&{MOD#5U-bcowUHE?gM>Uo
z+tZ$0TS(M;!ARyfCT;)gni%Q{&dOI^+IAJgUV2>KX2aCpidjYzgutS%?i
z>+K~?lrm*qr>LG|4kljDGuz-W
zdM)B2EYfX*Ud=%IknhJ{VALRmnK4~B&!F#~&y4D66E#A*<~Ai}j|3XIzZk}9^IP(7
zY8B#yDM*F`UIVuy0uw37jUdN*(7{#REmG`nBy|M^o$KyME1AkiT|a~JQLIcn8{Z^l
zpZacI5XttPRn(JX$~e}DnWnIaaQwwDcj}@w8z)zz_nh7TEd`QG_Bl}1(slh!kK=$y
z&}<6knBH0viD5}}Yle@`9Ys9B>+KW71&Bj}{c$4@-JBaG`BHUS_+V(=-V5XO?NBge
zM(HI+8FtggMPZ(WuoTXLU(Ma^q-+qIZEO=IXo5@#a4fIj(WeCOXLo=&3gtr>MQu%?1!=(x?&i`*Y`#O{lp`?DS_njQz8$Q
z@gvS>G5<7T>Drf!pr(rl--76;7T5edAzx71a>qfh*e(;a<bD1q+^_J}A>><|8V{tpJ`<9F+118?Z
zp=&HAW9+f`Z9AV%vl1hm#iwM@p&@0##qOyGw&M4<7*62j
z$tHhbDPX>|kQXv;E^a$e315qkk=)hg6hEY9@LkM8gpdx+XG
z=tW1EGL6TSSE_+->h5;7gULr*AG!5w>zku-Q%i4?Ve3x0Tv?|Q7_L8xPXQA_)sVyx
z5DX{obC4pgCT#00>>Etd&LbUcROdZ+VAAmpl8YE>~!B}j9o&5bRG@oIhEG4jLD^7NLddZ6<&
z@`Lw2EbGdH!{GX(UHx63H>H~&a*8B@#`}AH4&(vsY}%6xkUC;=(L$HHf4%qa7clWr
zEu&BSU1gQ|gaTvs=&qL}4|)iMf|!`af=TM@O6~$_iZKzSP(>aWw1HLO^Ffz}3+b|c
z5QPUkzCC$?i#11)9p=&k)!w17-wue%4idaCJ^EH3<`e^B;)-FTMpn(w(d%%t;{*{7Eol>WTUBJ{IOrax5Dy*7d7=8XB1
zQKLQ`AR{i;dQ=1uo!{Z%0>X&3$^%U(Ik}%DA}G(brknJIkjs?z)P7X(-SA@D?J9px
zZ1zAH_4rTTd)$;7XB(+5NRw%6;fpibXy>$!?33aE}`h*bwBg$$Y=(s4Uo4N8V
z)i9C$h9;eMyDcb%b!ji1!^(n|xt%f9mPlyy4ePq|8M(eQdMSw{k+MdJ{*24<`;}+b
z2~S&kh$}Crt2X{}UYdhzyk_wMO>75HF7G*4*{jY&c@TS;Go%XA*!ZGZ!u7{Tab(qq
zj@aquHQ_Mgzda#;6nk~PACl=6YjR_qYPK?|Ql5r%XJ_ykqP39kUb1qUsp2*8H+Sk~
zD7eZY_q&_d*n(cJ7E0liy-e!4=G%9rjzMaUCOOng{?@n!cxz|+;Q+RNx=kp+)(s_k
zT;6VHkRgqfzw|^ghLHA#wO2d_;oniP{IAm}{6SPWY25-zr_wv(N4bTC{t$nqq%I?R
zE=FO_2c-8Ho!au>8`9iYAkqsJ#kXSWG83{TD>}a&+B$5wIPuy2J$Y?>DpIt$d(yN!
z*HEC5@!jCKT)RNyxxo9O_vh~h$4rPj->?2Omf56GeI|%K+&msA(vhw0a3=2DdHJlT
zR4w~;-U=lXn_McDKO-ha6f1dC@TS0GPo+@<5iRf*Oo5jj)XqK@wD!}lz?#_wk1mY?
z@2rno+9T&VM7s2dZQXNiPz*0*!w`=EFKNE_4sK-ORGq*M5|QWmB2Cn2V-zmpO1VeC
zdwP1BrgA5~+nd!e@0EBcTi0QdMNxqH0XS7p}xkl}90&SSg3MZ!^q(+n1hG7jwi9wP9COnUjF
zwvNtaJeprj(q`)uRM&rUA99+=PzZjDA%6;ac{YeyreKceIp^Ud#G~W9*aGXW^WwQ=2>HJlN-lllYjOiPe#@@!g*vsqwO%J!E&KkYf-q
zwzZ*VOg9@Ja_^32ZuQDGPl3e85t>{6agiBZN^y@!BrpfdvJ^SapPzcns>MB!_1zkH
z;MGIeC_9ZsYGr6kS(&5lRb%1!p2HPQr2B@}R0Nf`G@?BBiPG{0Ja>aQ9bX1P{_bi-*pAB4
z|JH03rnPRxr7kXCNlO<}m
zFE)82{x?VYQ(|Vl2BKR(ap_`snsbOw>#Sgfn2o^yj6cPMSJyFf+qgDT;QBNfj=ObU
zdL!O>cZw#t-YjTGSjqyt+Ar!|U{?MVIhu5!4ZIro2c7bo!(OHmm6E
zCxn(!F+4$}#1H(<4P)Qj^bQeLeFASYo3~OrjRi>sZHc$u!(jd2^s{KCbsyT`RSIn9
zUM*&PGH7mu)mLg7#}+t3e?hm_k+0UwgaH(-dXCuI2E)}2eB=0M8*#)m+Vm6?x+TPMN!;lA
zlPi?1YlA?3p2k^i5U7Wt-C%D@e&|AZkp8
z-3j$HHo|DsY);n~eFBzcWYVW}vwM%l!KJ==a0}+-pU1Gz>yPoQHl8}bM9I5EQ@iZe
z^k`|u6U=a2weN}jb&2lKEVa5Z2omBcM=4}0y2*F?v+AVo@>1X3kS;k0quO=G`;Iq&
z$0cg(qT^48e&{cNs(!_hRn$un-(}if<9SAlvQWI_|6oY`5oFVla60O1_6%aUZ8iGI
ztop9$i_7+R;uueOk8Tnl+rx|z8ZhgxaFIFhJ(|P_`FSq`8Q&p81JT-3xy#fZGCU#X
zrJgKZ_GH-;kE{6>d78NE;pHVA0|&ZE<5NAS;o9x{49CYQ^-B60r}L*0@KyfAP$z>K
z!{uscP0{laow;v=5<@bFyl~jY>|}hX$5*M>=(^2*V9~9RmvS<{Lx^%e6L-LS`SuU;
zk>HLd(_#dk9S=ETBtGxlqMywX`H>Tj#Yg?M3amO%c2%x_pp7SyYKFCWnb;N&Cng6I
zP4nti<(F}Fhn{_Cxmcyyqj)wv;R_wKv33v4w&wL$@|x@|H-Fdjh(IBC
zQ+MM}{2RI?dL=035nJd-{?3y+9n|w6*E=a%#1xEzDTUv;LM1ktKy-NKD`^DgXTd<>
zZU5gILfyy%$i}zfI+TwY=kTejoY1fy8uq4%{h(}spuPZ|YQ!)OKawU~Qu(~m>4RgY
z!gDCj`^EqM)lc9x`ypq;Ntn~^)rzyhJ=ibC`&kM|m6%xap6e3CnyC=A{sU&~xqaet
zT5c;B7GT}^($eIq?+3*Oho*{hH&*eKbA
z@R;}>{BXdp(svb3Ql_PGc$gTb>3i`Q?p7nHdTz|+{hP(1;khpmMp#x!llc&}b`mGw
z@LD^=OT(h;kmp<1>Zvk=iTT_kRFfIQ&Rh4$M)ldqbzazj*_Z3raHCsx0h6F_(d$$P&WB)t1JxO!P=`epz{1hRd
zAJ?4~KykkGqXQe>Mrjp|;TR{wzPn-x)L?!&t_~6`UHpNvO<-a}h-7+nbKXvldA%(c
ztXa4WBEb<2QA9t-o8~>R#8XUpYfJ>=v^i6(-kJaO!ynl|$O#pMWOS=A;qu2z?2}gG
z5OELxgWrc|zr!OEam;QWr4nWgke~a8_)x+)0b|$@y8trf`wm|UuHTQ|i-Qoyj2r*V
z;uMJ0F-5NZwAy-CoH>*5X%4AK`Y0^n75IMXK@>rN0aGI2j^TQyUtR9H6E
z1Zy|B=r6V!>U-tiv>_S~)n052e)b5eC3+epMLqKnter-2FNVZ}E5D_lew~t_Q~}&2
zUaO@FXAwJs6Osq`4uom*%x@;`WHP%;JIBS~Pw0iJi%;vaD3;v++q9PHI6f#rl422j
zS;G`+>u#q_0iO*-9orF-;iI#ajXK0hMvgpmAMl*0eG%XNEUr&m74_9TY5#s(z1yvQ5lm>aG0$W=K?JeMU7rhmbx*st*(()
zm~9#>Bt^JO{KK9|+JlL1wIFoDeHXDQ!RK08QxNb1&Qd(7#gwJ&WfUV3HV}1Wr%1jT
zL@dx%h<{G5OAMze-6moW1iLg*?Ww~je`I$Bf~>_!62!;E!}q-m9&VnBJ+2t!KBHeW
zVRoFsD&icM)xgp(S=fmL?G9-Jo)!;i3~%fiEDUb)3hM%!P(0|D_|l>guo2Ctd@WpO;oNJbRL1@
zT*~1rbw|qk$x-_ItdX#Km^S^57vGP=~SFPy_Me4ZjbtcuV3iCjAgKhD@veEAM#GNr}Jn|bAM6llcS9kSCtbV{fxqHiu
z#};&Zl+w}rrDJE`Y*D+Y(=?+*Vzzh)2LWEu`|Qd)D+ICmA!35~b$Fzns=p$McgJ3h
zGAYKL;@$U$Qu&V8AIwsZO&on{ve*+vlk)I>K-6d4J-`XB_`tWKKfw0ntfdr_ZMZ%6
zXQ@Vm#4{Ln+ayS2o<*J++T+DFcFg3z8b-S`DprLKto)euFW<)JV{gnSq>_3CCxZ}=
zO|k3%Lld-x^$qra3F>J9joWL&104_heE60-z6n-UC(Bl;&ZRd|EYhAkaY_tjmRC&_
z%J<@@Qb>)-&@U%4Y*N7Ag!K-OE445#kTp;=EZ{d7hjy;kPs;kLRofl7PJb$ATo@+w
zXEv@=^+}?yHs*Lja<0M;VQT?LZ?FxA
ze|u2!qR1IBaX)S5^ZtVsS9~U#$J}S!zSU9-L64G2j{90{hK%E;DnI3V>`Uq74>%C4
zYB25dTea4b#OMT^_7U!CgZ8%VG*Z77B#zl+wut^2*%H==M~fQ4J1I+SP!C~k<&-$9
z_IDiEZ@W&iZ!;rZm~YvyK>f>T^3wjIl1z7lKKi1gP=pAlv8>HH@=t2$2({D`jFPfV
z8>SQ{O$Fr3IBTtNZtmR6&+foWnWw9wU0U{e)m(ozSbr+e)-e-Jwti*7U=zclxj8t?
ztms>+-~KT^O~thqlDX4q7jHN`$3I|@Leb4lxcBQ>ql@q@|DlfOp$8mSI`?WBHED&8
z9F8D-*`h6?_WI{Tdpx{{pI<2{yu*SGf$0I_x}GyLbM%(?pw*!i_xfQmN##IHJLAy^
zgn)@gB2mNl7cCiHAbeq@)6o|^Zb1%=LhJSApDl+E`dCT{I{(3PO6#eWb8-Iqq4~
z^UCyl99*W|wJJi!d#;glm<|e1vjPg_A8cQHEGeOgNYK%Q;khN1HH?q4B_+~9OK)zS
zQ>;B>^^;P-Ut6CF;5!J6MPJAcu_AqeSwdn8(yXb2vLeAaMo=$d=ycP#>d0JD&2y{M
zG4z4!*H+l0c>I0XBjkKJZ$N6y`dyptibr4P2OZPtf5K~8_}-3xw>6l^yWew6Jjyaw
zr6kPBpZK~t`B6M@37*_@+}mmuv-?r6!qnbC>p4`><-*GfO(>jQxKsa4)O+(mj3|SK
zL{oBkHIdYl0E%$wCxejU2%?YUJ))7Kwy?W@TW;mVqOGT1yVL(#XabkD1sc*(;&;Y`
zL&38zh0lGzf`O~`?6p5;Zg2$=z-_FI9@QKne(^`|W!VDuM})YV5LASdeO}n$xAw5V
zhif^$MZBNG%2<9~&n6r-jJ7JCPFno@vRRz)FJ@(`1u80Jdhd-2H{sH|+;b^4PT&q(Qp7>mV(ubc2K<-6`GO-HmieN!-Qz
zANRxkatGhe80@ppUTd#4*L>!Dev4kWt2|9cO9&gk;d#9|&4$>ngGOrVE=(8JD!m`|
zh0Rf1#K0K2i+xFvQb+Ni(u@p33I
zy8n0k5PKPD?E)-&%f#955=D!l)+(NLW<#oF(
zha)3ubN1ps){4~|*u9d}(yJFF&p?`#QsBL_oHm8*bu*+8yI8_~MsWJT-ySJSc3T@0
z2KiX^lZ_G}9Qt(g7`10{*v(X{7uxc_zbsn%+1dxKcOP)q*nSJYp;2SvO=l2A{H`Xx
z_A5e@qmd4e`N(S>m$L%i-}L2Lp|wV&m1EzN^U=a0aEMM;1MPbF=RNcP{)ltwRoAx6
zTr<|_*Q_)B<1~2wr#4SoI?JiUF1hVEK7xQ1gErmabAv8Cn*VuRR<+*UDW9MqS}oOn
zmF`X<*SRb2+gMmf-n>*xj5w&f$v!-9V0Mo2!P0Y6Jy*9!iU;r;u(F$*lbUhA{~W^m
zW#3gU&N@cDIm_Q&6Rw-%Sb-1i@;
zB`cq!1JUi>D1yqg}L
z$@Kb5VSIw3S6QT#7i(17gq@2>6z9sUrSOFHt~JvITcV}s;{sn&{|}Ecu+d*H$ny3c
zMIx{zeXO-fN$IHI$tx>kEk{8@-JkpFGLa{1OFKnI5#pn$x#T8x8$A61Ow+PjNs$&J
zBrIo-p8*>Q&*&FU+m4Q4)XoqRJ3`^JaOI$7_toXA`m%+2ji_DAUFUx|bf0nQ;+GlK
zSQyhT^@*Y`^@(}&m-qaL&6~?6eez~UW8cZ!R%ix%)gQBhJB
zzRjCQ-PG8S7PdV
z!YdV2)(^z7=RIeDg@wF&zr#DsduCg=jDIx_7fHlv9-`;ITvJMY6c`
zrT6}YkB}D%UONij;Bm>=_f*qCvKpuV49bAjfQG!TD=dlAkl7dw^X?dTY3fHCPR9)i
z0f)t|by9OyZ+uGf!}>5r(SjgHR&K|Q$+t=E0nov|(W&XnMveZ{--2(wy(iZ7Ce}zq
z^@rgEpJ~xF1~4eA-xg1Jz3rPb8x&+#O)rDaPwNqf?hD9NmFurmnqJ=@U0*af@U4;JABilB^O6pFUoPX1J})!@!({AM`pjHmEZV6#e!EV5uAQpl4RGhxNMF2iy8*pJ`I}CG5xZBw!@D42&(b
zJOI?nzBHwF)z4e!<2(~)o+cW2SseNQrU|aoZzGA^1RS;01MicMzcctVN;^
zQ4H@h;qHmnvu@|vR{JP#aHj?uxBQH_*l0gdr9B%)>Yu{WRHu`fxBT$D*hy(VJ41&U
z@yd`}v<3FEDmPTQ%f^h+DV`fq%QY~t1k&O!K0aQz*179H{Lu^rs}nKXm7q&vr@}Dx
zn(21ygD#VRdzBk7ut0RnHCE+H-MDVv6{`J6eB_}0VZUb5#tme{Qe4iflw`p4QIcVw
zw4e*9X1AT*pJ?;)dEKxXg03mVReeL#lj(83)eoyk6>!rnHGiTLbPp~1IdJWw`0hLfaNyKmK{0|3t`{Z|F9A@
z(5$*-ha4=Z2jFAtz+Dy%7)IF-$q!&lzc%_iBk=fMSl5}H%(G6F>`QZ{+EaEQ2FKWN
z)1pmPl;sLcSUuyGP5{p+OneK?(=)%LTU`ErJjRb}D4qx>B3*5zM@|29@76AlzIu16
z5SCIU>nAH3|EXFz@JLKa*Nc|a+Fs503S+uW`MZ|Cz$+0Eu|0kq_|=%Nc19T7Z=3=b
zi#9=dHfyzF^2v}Yt*6!1#G{Y7-iHfFSjv9`4;F`^cBbm(+@
z08E-^h>6Yk7$F%bW;HUm4Ce)wZj_dI{_**$k#YX+;&3nRlG
z0mo`Vq1N*EGspzYwIc`Mk&@OEqlAl2t9}cm+9=mT#dv^imnQQx@#tpMH=2!VQ`bsK
zT0W2}&Dn<%p85mA^I}JiR+U*w;+!W92G2RL!}+;w4?f1cnRhe%7;IpIf^|Qc^=Pt+
zLWBEkr|hvSuxd%{(L(+dl1_G6F$eT57QoSpG*=zyPI_J9K*Q%83Bwm
z8yajDk_}@9rxHXG4+f7$v)6NL&p0M4SHTFu#SZv&xbLd7c7jIoN>e~0bW!eLAF)4u_qMc
z9I%0!VQFD-(p>LD(;H8KyZubXtR=xW+aF((Cm}_4F_O8
znqu$C>z{usAD1H0Qak`L5sWb4kV;cUf{0}gu$+j3
zSF8U1BwUctOWhCbrD*0^LZeX5YhmC?8G8Nu#CP)-<&~hS=DW2dK}R-2m_xN4m`|Cv
zL~+E3TCZ7s_vLM4?>`eXXSYbQIXdqZBmDWR_SZ^9Q_v+O`W@QGQ@ZvcvI9u+a(nYG
zXd3kW4XP=ve>8&tS&sGTxcYgOtCryWO$pN01*YhL97(eBwSwZ{?!dmho9G!yWFvP2
zTnX6!^_ppKRC0x|CHTAO!u@r^H-#D2;7GXHxxZZpKE!ASHys3MQPu8A9Ym7RyRQWwBPFysd|*0}Pjx=OC$9+=vP)
z+Wl-I_R4U7?RCys{QToFkyaU2?;Lwc&1rC%79=7
zISCn7Mq8^8v}GU(LZM6nrSg!Bs#ArdpQ(grFWA2GUjP`CfRyW{Qsg&ZKByS&;@L+gQnbFUM6eZZ@B-k83`b>gxm2jWwP}1YGZx
z?p3xbYIm`n$AHq{;ONQ4VwNL5q%zRjUur4gE@K8gGe5w*S^o6e;|HO~&dE2aX&B$=
zOT7tkjMU>8I3HCA1)2Z-+22bc%)Iu$YbWg|h+f1hU4RGA@^VhfQf8C>M>H%@Dd1G{>vMdDR7X?_p3sjx=juZ0|#
zl__0`@2@VyHy!!JBg`MsFP0wxSu;X=k08H2I+Z?*BPvW8z3YN2HV2V}M%ptoe4(48
zWs~$I3{bMhUmN
zJ-%ODph`0~M?sUJunyBfBRt9^U@<6Lg_J&k%1SqN7{WOz+R_|t|23a@?St9%*FUJ!51{khO{o9}K8js2Ds
zH|cyqRHG@iy0N#K>m(3DgsxBEK;IL<$T1ZqZjV&s>G@
z7(}u-l*6$c=@qstNQmHQ&IOLlfuS6!=f#m~*{-$J9`IYQbee{An~5ZsP~5mDw4{Nv
zvX|m>IzT(z#4kh^ig*p6_Z5h>25zZkp2OB10EuWd*>zxLrE~}5-7BzSgy2Hu9&f6)
zza-R#2dj)7{|ZW29$vx#Gjfkvlzxm&*Tr%V9PGJNx<9eOa5%y$L+QkbC_a=~sn4D8gh+N-5A4OGYEh~KS5r)5G7Feh|0QVP?v9v|m~2vf6n$Cn-+S
zHnhPH^BO7J{$iLHGxec7u-UoH#xN;Wp}Z|Vqb-)V8Se5r;TGlgQE8}$rXC2w{0b!9VAgM*gYsn)
zT%g-L!1lxotWsODK`F@sbu5Eyk>gQM6mO`3P|*4l3b
ztxiVQD6X^=RV`4&MwJM&t%>$Xs$v%pWT2#M!NT6DGH`0B6{a|^mn42Z)U(Qholu`4
zYDm5if$IegRt48HXJO{_JEd6BPx?>rA}-lnUFnt{gT$+q-udC%X}RBE+$y1*P}-}K
z`Wv`({<$thJo0=PuIh9TOjtblV+Tq^=!^86-872RP18T59NWzjR|TsN$L_;5xQ^pp
z-zB@m0|FWLvPHW?uupgPFUW|sp?IZhWBOI~Q7*`Nov`y!Snzb?SOl=_Fr;i=z~eON*}6W!X$f%L
z6eblH1e*YSfY|{0i3=J}1kH4($32e6qZB!X+LYt=kdoT%JEZZL4&X7848(DW
zlHE8;>7czU7=eU3i93(LBs+!R!xC{Acddm~8d1Qs^0`REv0TUVyT+a83f>lcR0%CJ
z;!*SZx40_2_h6ho^d20QM(LM9Hjhmorw{7U{5EUSmLAqVh%dJy7x#W?SJ*s*CF3n|
zeTLgYKfhksID`N;h<0MHMPzh$L@-D
zCB%vfA>g&KK#2fy50oa^*2ve3R7F-7N(BA->X?ZOo@vtxO&I1&bHtM|ehvF_bU#e#
zJxmXjRfD`61#!jXz@`lci&kga0f3_B->|l&&JKR>8Y_Sk)RI6}fyskIBWkO-MJCp*
zZsm*5bo!#BrGn1UgQ+UiXaA}(fs@ebu;OXHbf)*N*gi6)(cZEM!+{T
z3A0uHIpiI83X~THeH*Sd{>458fkpOhuM0{_u4KV$XH(L
zB5JCJa9MOc!mz&7UHtxfLmg@2I={W9TLaGg@4t8k@x8z4yx~W)*-7{+yIk
zC=hSZ@xHIkj@?cDRJ)tkf58>AMD@;BL>`{(#fN}?Rp`5c>UR9hm+w=T5S(%ge&yb~
zO9%Aab#MnrZ_2}Pjm&)K_n;I?>c<4=2fA7JGf7r2)%Y2~tG|Een^?S4n6*6n1|yi)
zaIvBpu#Bi4c
zdir;p*<4+Q8G?SC(E2IcKbW(o(%0{X~s0IUe`de#h1Icw~zzSvqEjyT66noZ)BhPtY+NAPB0GxrAX9>pr@~PT)zW
zXiB7L%>8j;o~z_|p#VFgBz(Jd0}N=|1sU1)+Hnz1)N9A`gb96NY4%`?^YXtyJLlni
zCuAfo`EqUEGm|-b8l);*D8V2jH9sAii*S04QOit{C?{MaS|*glC8fQ~9c+riu-H6;
z?7U1Y2
zmx!kqix2~Cvu~-xgh4%=ZrDfA02+S2mex&z=p&13L(!0U{Ug%02ioG7uCp%xk8oz|=gE6wWcbE*hN^Hkyi&=#-LG^w~1|zn@eukM7w&bco
zk%{LMy9a3z8{$tXZzP~Z+FFww7^m6vzVHVY1V0qh@J+1@N7r9Hjy1x?uZvEeB??1z
zxW_!M?=%E?;k(B4-$2m%lwsLDWlT3JEnVCoXbxSzq@Iq
z=ihxq2q9(kfy7-_Q0=5npPX*E4KXDLD(iX|;_{?P+eB4#2P2ZPeZ&jXV_d;0hwljt
zXvG}nQt7ORC!bR`o<${}n>=SZs|bD-R{p}oBc$ypm8+|kE#6$RA@6e1`nuoOB7&K8R0J13w_Kb}6a1$n`PYIxt0Ld?QuybvF`SWP6~lC?zrV+nM(#C3>#<`>L?vg`z`b_d?a{0N!52<_2@bhn^z9ckN`@k|Z0BZnFo6GTg4X`v#dAQB$&uf8=EhhX?*&0T)lj7$k>E9=K?
zVY3%=d$e^T3lB;5f?1sl?<7bQ+ZyvlQE?lRFwBiEsb8X&La!dG4zIjaxffn|IC44X
zlQ(3dj^*ysBX`m$$voF9d{t4Nugj_E
zb2k~4*&0&|t2o)JPnR@kC>&zlij)=gkPxeM^IH&Y&782#u=u{WJINY;nm$!(!e1b?
z`8posm3ne{Pta))SC5Bjw#``|MXZ_jC$3Q&xByITL7Z$!GjD@{wMKhgK_2ATV8(4%
zqgt-cylx)gr-M@ZyHSUD@IsR0&gOeSj8V0&h5ng+1S9=Y$X6P>o{6=;zdXvmh9vuR
zO8XOVcX@m|ZQG%>@Zme%fYRu~<2kE`y1z^b{5YRYsh>lXv`I}~y)e|WmXz}ERDR9(
zJi?7|p3=ZCj<&k5s}~;O8U;>rM-q;ew343No?=Y$K%Qs~BYId)H)PBOojuiA_X_)3
z%reX%(;}>Je}5LjkGiF?nHQ&An*v|GQVm<=CPO_&_k+qBw^=Y-E``GORh3dICE?fv
zZs`1L!PK?P(N>Y>sQO;46=lma@3%QUoiZy!Cy}~v%S8rMyOxow@3)6Rd;_v)1+r~!
zac!KK79HgRQ!XWzpet|Sq-Z|wdm#mjxrkb$Qm*^xR@I+zeU?V?ngSw;p1G`nu6C|4
zI7scr(xLm`$X$!8%y_A<)|eIqd>%X7LA9@#@rZR(5R!RR+UQ@pNZDQ)rP5a?t;Uk(
zvNltZ4(O0bCi@nqsx6ih@-LN5&T=zuotXqk5uwxZbT+#O*u;(#8Yjv5ip32yA*{;H
zc`A%{(OZRS^+~0^9!Q>6M8{Wd`Pu4
z)4B<&B|E{eP_Lkr8Vnu!N(2^9@
zNAVCTa_BG(ZoM6#PMSBSl0HoR-8_b6TsQnl0bfjw%;sOjQeWI|MAho%zh0i#I%bDi
z+g7ZvjPeicd{Gl{>;=>`?2uZEq-609-p|`_4SiUe!p8LRpF7xW2=P~#SRD`pq`yl81F~RC?#6zDmb?|?qG4n17_7lG}{@gfy<;PHZuX&tVg4?_d
z+S%9iN16Q&^i*6_(DDzVyuA4mA@p?4sDE0)!ycjbS7djwdX908dv3UoY9Bh`i
zz7NTA-&;CMhV-@oE0MH@P_8J)rlZ=beLwt*eCVj~q0&jmc~>kHZPyKGd`$>`-~1{H|m6`IJh6)%m^g6{A%q|EW|3fb1=-
ziB>U*3re@OUToe{ke2cZ-q_<0t$(quTXy5580rwl*Hj}1HEhIHc&wZ&o$p`NS;Ks?
z%s@{Ef_i((akwh9tr$jStnnch~T`fh=4`iGk%vhEsy`-HL~v
zIYdzZ+vt9xT=oj2NcHc5RFq&8&q6y@jNrrv{;FTg%jKTZ$LQRX6a`7I*fpkv(z?IhdsW%V)(>27Ux${ShA!DQzA^Ggh
zd<=PO7&NBo4!d%PSTuFBtj{fANfIP
zG;bS=J~B)hhX}j7VtMd_2*JqP^o8)x5qloq
z^iML^o2+(ulY2kh7EaK4rhlj&$mCpuIfVO}{5i?Dkl7FZ6l>4W69da6l`KiGk~`|U
z|9wEPQ!*2b%SRYQ!X9#V)J|bmbXLPSODC?5o63aYU$-Lp#p7~tJ<05bjrv#RJ27<%
z;)j0$fWmJ}wL`c1D+V!Z8(a1fkiXefkXM^G4Rch5HaxMhsF3_I`JoEO?87lMmqL?2
zdWB(q@Kf7G)&f-&Iz4xmkg+a?F18?X^%mjmT81#NYo^!>HkKdQU%+m`@WXOfrtuh5
zo=P>Wt3|Y<6;Kc2#c*t;iIL2K&I2<%-3#IU^Yq{^$(b-}Un#lh?FSO=r+6J;PQPoJ
zKqS^k%mOhzx7Zp~@aso9B?38ud9ov2`e<9vsE2nLEw0xS+7U;8A(riGjB4xyvf}?n
z<%JUinZB}K&trPyW&OYdKKi@Uf051O7=yJdi2U)vzd2QS9{rp#&L>yCLCg;{Q+a>r
zZl|~K>d!u5!oWN|rSj2X{9jVZVFnTuPjWJ3@z5TF?hP{17d}Qrv}Cqjw4a6uLwwnE
zJLwNYa13VM>5@ZVu;I;Mao>o(kQ5DgJShCVkd~IVoVIP(u-rtJd@!GaF>QaX(5kMk
zCls1A9L!9i@&@^>YcJmpKlj}X_eTGxhgp!vayteJfP0Bfof}BS
zWfi1Q#mRoUn-J({PT8sDQeYY~h~whZ#@KhNo=b_X{dX}cvW!ITv!=wijmHbjlN;eN
z-nAXIK0Vrj;tE%A$+~}Aamq_X=IQH?cL%IOb#tF08uAmh2NctIh80sdBsUe3+1ej&
zHe(jtzaZDY9_~Fl(E4*C!{Xjei(;fdnCRJf0g$HVQC~3%siyo9OP~_cQ=I
z^fBg&E}T-mCbv?c&e;JIZ3i8jir|B>oIonO=GTn=_cv#D;7c3(-IU0zW2H6uL)kr7I>rrn
zBv*R_s>17=NtWR>UU$Z_=1Lv26jMBJ6X21V#YJAu53oGT=YyaukFf?vHSD_sSwB)ikK_G2*6j>}E%?uJzhRz-zFeO}-});AqD%3l}&LnGY?
zd}iIE4<&eUz`JyTnXz>j&t{Jn{Mhm)u%|2mDB+1+^O;m#J0eN_GmK&qTm7DSOP``i
ztASiC>?_9?S!<&f6PZ*4?F0F7-S4|Q=~WDvcRl{+3cj9uD!whkPxlvItZoN0iYJ3F
z2z1#N4f;FJbDp~YIaD`0=*l5~Y^`L=veEFRGGJ;-q>+wDYn|0D-UxA)L1K~E*^t9^
zvOj;GwF_j$aWsl*-(9y8G#i06x(?DEP<=*hTOY3M_VbfIC|D2XRzr6a6`XYzsJc4t
zYh>bbw_{m)89rO?10!}3YDFNk)NV?e0ywD#$G{-UEJYN6n#TPDk8Sy+^{EsgwKian
z{YI<N(?8Iacv-ObCU*gnqZs{AsT&77ll#gyEWmh
zi#6ssFve0w7JQ3^gGwKSd<@Doj;kk?)W1JN$`9J2Bf&H?;BfK<5^j-#rh#wGB0vf(
zN6LMZ;~#*g3j@s3m-emxxP%+=Kc0?rK)J3$pwf;`5CRn%zWv!*Wk8~0kq=`GZ^Hf*
zcb(<`==fap(gX-L%T=SoMXdB|j(~+x5BQxd@>k)!Wzw%4cj7Ku(I?G
z%G0t^&}O)NvtDiajWY#mC^QY;Q>?|#0|>%Q37}$VeUn?fsD%5Pf4qg7Q|ldH>j9o~
zwNFQdaWB8gXS|cjL6*|cSaW@{Hdr(Z)(z1a&|>OT_ZiFnT&C%j6Kkyb!aqve+u&|a
zOXi^@V%ZCMYhU_Q`ODY7y?1204Vus5vHNJY=rM1Dxo67vGAI8^EuTBGvnVtjvT>&l
zNBTF04+9-O95XAe-wP+VEY2>jwIei^*swM>Hb|VZ(2-9m9)TyyWsZ;x*@8tBzw4ho
z31laeJTsm!HD$?DLfH$t3hA)m+X&_VjXGL`305SAU+fSPnFj=g{s_)e2gvHnZz7n!
zn|!$v?L-N<2dLF0!tu+;w*th5GGr1_ZaS{h8hXy2IVtkUDVB=k&6QEa+ym$&JVU;K
zyx=wD%9Wp|hAWyYx*nb29Q`aCq@T>Pxw=L
z0A=dGvX;96Uxs>L#w~mf32)KQq4`~^lKvbwJX?!SRT}a`G0&GEQ?Mjg+R8ds{YE1l
z$D#vfy{X+g70=-nAzP%A-?wfi90*ClWY0I
zX2P>UxC)0iLYfF4vzU(H(}?HBm|c3VAlsJd7yj>j1;5!G*Sq(@?y0FrJsY0pR%F%f
zLO-#Jxqr^cl=!?VPsya}FIf0T@5n8VA2%!L0R!s0N*RH_$IChfpBNYzzK?VER#)U1
zQ~CPH^Ap72`tc&b&6F_>(ZU~TSJ^t}gC#UyF{>#5=M#7l?|Qkm-jQIB!D^Cq6;Mmb
zcmH^g3TWtyv2NZgJ0*kQP^z*h)@^Q7T}r5
zwfoU|msDiq6LJa}7e_|eEyR3mPOD)T7g8<`S5W(L6w9!8_FM&|FwRr0S;A~Jq7M0I
z0pkgE8k!^8t)D!4lgykP9@1}0X&J}UN3s=L6d$1*bT+)T+r0g%%vw;fWi_RmdlAZ&
z$m*o>k1wyKR%`xhabv;rpY3dJPIt~om-vBj?`vl(-}Wh<4bhPHAde8Fu7uS*^G#k>
znlraLr^vnYjn1SOTw8O=7nR;~MxpdZA=$feTBu*{W$n6Ug651gPQvw)nMD+}Q7>No
zV$NU{tFaDoynMTBfjab+O|cQw@?FYfT-&d<_)aT?cvG(?PT|Y$o^NB94znN>8)zk$
zEy4ZMY$^UUOMFE(h>VNuSghJHdM*w{dKbvNK#e?-`<+rMFvu)+bQNi!tF-o$|3_g=
zlmF&5*%0FB}VcCVIi3dm@2KcK|+`AR6
zUw3onp_=jw*~wK+;kAh&l4fT(4~2oBb5tw`Uy>}Rcr<5F%EjC}PE{Ol3k3xa$9bQN
zVa5yQ6-X4*{t42n-nJ%BP?e8VJ2@
zPp{VCGTM4qXh5A2@fIZ%Jp@|wJ@^)ZzTAI%kio6Q=%gZ&EdZ;RnEIZH6~V)!>Z06K
zB^b}xz;lFecQ3CLoHu1?1D*@oxcgN1XSjv~`}35a2!ZMCNhRmoS?yU&&w%w*b9(XGQv-o2l10-y*vCsP^u$T66r(fIM0+pdeGlT9+7mw
zznkm$M)s9IRh>eCaYUlIUkcLGfMV!n?`jLfD5NrZ=UObFs``dDXMPC%qBylM$mu|Mk-9A&2Dnpow8I5d<~0Jro8
zLD;YjX4(bP;gH+?!&`xtFn<1}XY%OdLV+hFVZit;5osTGDvgaMkpv~{oYzdPlKJT=8qd(L+HP5>SfDnar*ZE1%S^9o~5qNg9vWhEE}S~+c8PY;ac=F6j9Bda&E?be}dZDE75YL1KDxY
zDx&9O+TDr4c8D59*Y?aO(G_iM!!?rv!AJdZhV{n%X9f(gV9OsFs#Esmf$8E@AWq(N
z>^M1>fLZMxO6@i0Ua%IVUOVsrbTao>uU_4~3P>dqm0u*7=wVcz`aBhd8xYx#f#AX7
zY1Dlm#tQF&FPZ}VLD(F<*71$i<|eO}fUmQ&ulk{uZ3#0(0(lT601`G>So68K5NnNc
zc-IRbuB{uFcoTrPI!IloROO&HpGh&V^N`#p8s5JMm7$J-$y(gUjr~M}Xf!*NC$IZO
zQkJc^`JF71tj3QqbG3H7Hwjp9myT{!U3*BXG!Fjdo0VACUZ5zkr4hc1Or+(juqEoX
zI1a`oPfL^9EY&z*4-h|%iHvOLh3F#P
zo5>xtOD3$(g$PA8Mm3FwBToeRDF5uONAqdZJyy2;>0c;{y8@wcB{`+-2zLwdocX%N>aUW5
zoYAQem3nt?$nxyBJQi|2*`>k4XQo1bkALSRRcPs=5
zaFi@bi7%Z#h*Qi4&XJv4e4*r->#TUsLWbZ#5L6rZs*9mZKR(n=O?cf%AN`NiU-*eZ
zDH0v>imTGQ5_X(_Av8)i#-49=U;coDqYj4(G43}d%ay-=XOc`^t3`bd%3}GB>AC(NpDNsH%UQUKV+8-G`N@!A(Y+2B%HzLd`2vqW!3PTK
zrb&i!DyMEinQcx14$thHh2A5w0Sz-QyV7^-K9KAwEbzTk+Hd>R8R5o59ZNU&%um2}
zp|4p+!etRlBI4J4FjtXV>NfpLqo`Ojz#?beh)go~?DeGP_lID&+ErKEi^c+bLAub?
zcoMkgw-{uCABE)C%+Q}kJhqK;h=)eX%XrlkmJc)gHAfvpw!~?588x1t@N^=I)3yY~
z9VD7e8g~vp1RTtl0wexd+*yV(ILCtqxPY|r$ik)RmHRCWCy>?UiKq5@1hN->#2cGPNK5y
zS;yZA$+o*7*}juItJ%AOUX$m+VnOcu=T-X1rx^djyd&yS|;jR>qL-ORXi{j%ha`%|-{m57;tSj@q1cE-jyB2~JqYd7=!8w3LoH$9Sj`5e?;jh?$35=ovx@%Chp*CPs{hu(7TW|;J|7-z
zK+IC=6;+)m%#1bh@OxChx=k*FP|JwRk)%$~$wk!QNvP4$sxN%-N
ztNCkZ^cS$gp%ny=d$}<#Z=51`tjG};Is=k@K?dE~$`mKgFD}6sQ
zm^~&{2sslJu?I#Ol!fOq-^?pXN7GYo75WgGVniP2{_amoYclCr<|pXJkO?gTy6q7F
z1hO;p__s_`4{jMe=-z0!BXmI3+|iu3V?%y@T7pmR0IXS&0?OX`AV_Jb
zUwR%+%xF-$IXS>_V<5U?yx!|kPF_p?7>e}8?P$T2_S;(x%1lHp|i*M%cr
z|D3`<0)^fD?JSwXnl0(0uVyEL9A?1E<1ynPANLEZ6a=}%67p0^|J?(Brure1<d!)i3wl6|5zcszM5GTgWmT`je~jwOID_qpqRaA57NrLzs2+iYI_&)uayIEYr9A>Z
z2|w3ckdkUO{=7_VU7S-i?|QtXg%myn^I6DIstU(dfjnUZFsV^{U8O0oHX4nS8ABmq
z&XnqpyUy5J-bxRTi}uH`T3_wjps;`ZJwWQvZ8yWaR7Wq$5T4SGZcDtO>J=>FOA;m3ToQ;!ng#M`W@|Ri*?Wh
z%cj-iXFpr4#px@&z{#3gySAB4i9x*aSwPY9Em*#}7AR#@O%T2zqTD-t;%H}31ew<8
zMZ-XJ-6R%0m(QdNIEhTA7vJ^pr=7kB1z^#3sO`pq*+bNkPJ|$qj+-jwNV%`o>pUQM
zs0$bz$6z*(P4BTZpNjnziA>|3IHP8soh_eQLlAq7?D%IyO&c4$q9s?z6L=^Ad7^N`
zCl+VjDD*uKSb<$i0!LfmB>$tf>)8<>4U4mD=iO!r*)vZEt06G+yq$(06R5nwK=
z_3`a%h3c~YzWLsy)+`6=G?D(8l~~V~-kpy|v#z&9{)sjc-vZ+;o=rB8
zeuVrM9Vfl>J=|pYbKl={?gbQyIvs~mMUMr19u4CR<{FLn*h%AL@u28(l=!pjeg{jP
z+kj~oF|kR8?C4cIz;1T0)%*5SVv+w^0Me8jA)L=Mn%4JvS@WUn0xbe(gI{Fwb4b0K
zxWb97bKTjc+#{S;^g~&?DVX-@I;?&AFmT-D3LVa_-qy996Q}Q
zP-yognt}0h{95c3QXA?$-r}v*Zx(AP#X5JF&@Q@X}|e=fbpPBY+N?)
z9oB}IU3{z_go1)?5Sb8#ri+Zwp8t8y>Lg70CU8@_PP;5kw?Z=BgWe0rCzgm+xUE4flTt4IBU`oKoefY3MOO|c
zmlncUwh1p0q~-QXhdbj2&|!ZJraUKym&EdRI$YK#SB5mh|MxAn$b^(T4P6qA&sxKC
zc3v*_dcm4i?|TDKD(*fT=;*I|L9z=e!9-QJK2up`f{Qgm#Nz2=v72jodi1WTF~$<@
ztepO!vp-Q_yI4Dn@dk}&++`lEQxrTYEG!EMI2N3}HV)q*(Dx9feYt7u3lK!kNTe>Y
zerLZlV{p(v&Z@XTvRj^`#1?Gy+XQsD0!2~7>B|8_4h{T+o4bQD(k!B9C87>s85=W&
zyc+?QW0Ko`MNo&ArYIIM^vVbo836$fF8?!(KD7fipT!tO1}-eD@NxZSJX)RgtWtNi
zdDhoWwXZ^b*jN@a;6d5RT#C=5e}P(h7NJn)-PEo6yFaTABp_q=tlGS9n)sniKAR(s
z)cevcPrM0@5(8e2`?4bjjD9vOHbmgQNwD=a(HTIf|JxvKEBk4z7%G6+Vop0TU#0vC
z7M;$Xj-NtB4n#+~awXU%DJ95r*;uUcqfy2^k*bSLpekBgL^RXqyx;EmNOiPWH@jy<
z5uS_hhXj5IdN4G_A816~Ko8Q44sQqf&0mdL;sTLrH6Kc}3q1s{J1&ZHv>D=c2A;oQ
zpaj>1kpWINXb$mZ>3T?s|I_0!z=%4N*pvqxfUOpT36-Tjd*Bsf;&&e9K0z=jG6B$}
zG7Zi-NrA}Gb%3~kubKB84==h*DlR8z>aQ<*>1oBNok?%^CYEaMu5x-RkGxc@Xqpy)WfQ6m@jsc!_vd6iXbTx(ZruAW%BVY9A9_ek4kB3I79MnNxhM!nPB5J@$xs)cnS}vJ
zN+187HPC#slrK-<+Fg6I5wTlCj(@Q+_hD1w(CgA1ZZKNE)J<2WMdfCpuEVKVs1+;M
z4tZ+EEa$fw`s#v1jV@{@uWjj;{>Kp-Wv(qP(^9GwnQMUi-qU0rYH4&k`V$Rk>vcmM
zgL@ld<1Xv(zCao!6FEyXu6ZI7m++#ko2cYa#vx&8Vlim03Q;idXuy^O^tni1gIUrD
z_zxPiMQozm;DS@s8SEM59yPCGdGu+r7RV^iCMJZ`UiNeAMLY6!oZLxK*ro+vF`(U6
z*K3#VpE2u?&_o1Z6@SLMcyR!lGvD)C1KrF4#QPO~!yVTS6H?l>9hvg7dm=P1Vx-nDTCyFSg%Z~bhwZhQ{=AtgL~?0X356a%x=gL0T9X~$=jUai8`^f
za_U{K1|4gyWPP`Y{)=#QvB;u6uv^an;YiPl%n`Ie{`ul!5qk7uHB(e7gqgf!h@eC(
zi8@u2kJNn6A@xcv9;`y;j+1ZFMC;myBCv$8Hr_yqE1CQe2)PI?2wfiUFO-pp$k+^_
zsVZ#k7|hR$=CT+n^ZVRNo>K|dw;2)oWq!KpqBTooO4IC?Uac=JS;s8BT+C+vNt~54
zkNi%1ug;mUb{jPMyq{2aSm}bi@8xaW!8>g!bw04u*E8$&`F?mgS_TP=SR@xaHVuKI^NfoIGC24h&Q%=W
z?q<20XL=SWm3MA-fu^lD!orI`;qN_CwaUEycN@d}eo<7WV9G?v8$sv^wjx4pzaH!P
z@@0v)Y7eJ}&&={AT99#=gdHr_l>rUtWNAjn{>bZcZyjhLhxqy)Mr7Jr)@I&3S{6rm
zPqw>ha)cm&(rJwSSB#fw00O8wk)WkPJXoq88sP~%|ITq{Q7#l*pL)yer!7eg;-kt2}XBkt;}_4td7E44;G`5?nj^*|Je|I
z);lwwbs*OcRx{i=v?}b?Oj&#>RXKiw-z#%5Anvn6C2-10=(u16vD{T?tar+rScxzq
z6B>o&wM@?)BE1>#Z2a9w`CS~$Gh7SmjdUbw=h)k(d}HY+vb7;P@g1FoFpeaqQ(}m?
zFvzxvEhKoDiyKQ#Q$x*ikdSeVRS=0a`h%_^J22rid94Kw%L9e|H%7~JNAq-dC#ken
z*q?9W->d)UCWxqFxqfEn6Y<)m$F5Z^0akZD<4jJ%X`Yi2{f}Y>)}Xc2%n1K0{TEjuT%J5T?<`M3I*uzgDDjaU&&tvH
zc-0VYTy6(hTk8R9M^BNKFbIQh3rlap6Szr?i$;v5x-JeJsjAg2giOH({2#vFIx5OH
zdiR!)kQzW48io{!p+V`PTT$t5qy&_bkRGJFq!DQZhAx4jOG>&sW$5NSe1Gd*>s{xp
zbN<%Fz|1rEz4x`R>$AH8B)u0KIY{{5F1KxRACo@}Dc#E;CH9x=ARiE0U>6+LV9iBB7Nr+9=v|67=^c3d=^|0U&bpH<2In+*8l
zF)>FOeutd`hQWzkB=E76LjPKa0E;$Whq#hEQ`bDyO$QI9iW|N(p(;6=K79n8#KOZ&
z?!lztFoUo;07iL0_Ot%y%rm}ZlWTC#N74hP>>V^ebP(KEv3-*}?4v$V4SmR|erUU0
zhQ+kJiE6D!7}BbK;0>p8Ff9Xb6$tp$z?fQaYEVJwBc=<$Wb!cpi@+J$a*?C=1#rEf
zSidiQ>;N!T$0B?8cBTe{@`Ni{lhOaHQ||h=@*nE}b4arIKf6p%VF!POSw>Bi12h_{Io-3_&#^
z&cK73H%#dOc`r#X;xxoEQlWtDFqPqbrgKU(15`oXFI=rdJO1Y_&%t3LHXW*v{xCwg
z>Owwv2=t39WZK4P0-die^Wx@sO<%ORu(Cx-!gHU8tbUdB1RfBzsP}LRP(kn`3^HA6
z6$bLa2dB}gV))oiC@Jf!@9TV|)O4K}I1!G5hn>U2Gye)gR-KdW4IPe#bc^{j-hH+&
zZ^##7>b26mcJuBvt{mr7VW<*S=iO|!4q>hTndzfzREe_ez-$0~LJdFWNIRL3$h%tqRO}&(SLy}IQ=5==U
zi!-txR;}dmI=o-6ukvqp7=LOW>MS+k?%A-J=8R~neD-#(O{vL~!H&@htz>l;mfcE{
z`QLsR^FW)oooL{yBamQR$rbkTuw=Q~m@wrR)#8(KtrJ;DM%r!0L=s5(p_}t&h|V9@
zFf_Rp1g5-pxzSp2FnSxwG+v8u|9Pu`FZ=p}=PqY0AY1I90HVw$nU1*$q$mZABNw+F
zLsm6O(FPllceGoKHrf|m(`4G0su>J|N}!_zp@_j9KJRP`y}_Lq0qcAs?Z{WAT#yF=
z=l-+Mf_v_e@&#~qzGojeI;65k#Q50zb071jpTKCk>D>(0eu$oTe$e7Ye#`20xG|DIUjcwi_L3
z+yY$m0>@+E?=m1;(4ITppPjUau#kG$Fr@!bZHH{@SBA^M$3XZxK~bp#lmDJ;1Q_NtR84
zN4b3F>yJz^7yLf5?jzMFrFM9^PNM+RGKy|ez+1GnAbiAZWx`DdRoU_H6Ap5=ZKk)~
znhRB@AC?)GA4bdC8Ic**z3F+Q-_+zzJHn4bC_23q5~*cManHU3Zm0RLXc*(=FU8@I
z_6OHgaX~?kT3+sf;&zM#Zql0PW7zj_SrL*`I
zaKb(#TYgUenj0M@6}pK3q4nk{3?OK9&jFQrQSmg*r$15$fMVzZl+`s{%^x0jj?G^3
z2c-U}{xeFFuSf?RjAgc0?mllQa=Vem|0-83Hm_9cophW#?VoI}?i){OlXuep@1IUo
zW>^wr}H%
z)_xfr5#*Y|O)Ipm&u?%d%;s>TFDgE{x|zfKkyFb^O^FH`wP=U(T5090*x7V!5?{Ll
zTulu?U7^4_3OF8bGtFQJiYt~8t3X?>j<<2yo><)SMxWnwNCHqM1M@=-3L?NLG>%|(}@D>o`ijT3VKfNM;VZcKfsra##MqNWT*1$KlL&Ym()Ba
z@^pSgo^C(cIH|v|1vlFA^;la&tT&HBrCFScZe!O=AFb&Z-3ZHH0`(5-I`HZ4?=G?G
z%!&mZ*q3(nHO?o%`x~$KUNc|tO?XasN->3Vr$^kxO|hdnDlr}aOaYh#`5)O90$)=tTvQi0;chz_vn(I^verDXPcYqr-
z_i~D^Bgl47bF#>b_;nv@X}M^+kTla?EoI1Dqh)F;o7~Tgv}wH#lY8F{y1ld0!@8G+P$eoIzmNEJa<_}t-?RDNG>~aub{{SM
z?5uLpt?Ijy9h>4oah9dCGv)33UhfMrcQncH#Y84>T~-1%&m9
zC=9Z`No&TymhOA*jYYH}bSn%_9i
zI60=pQV?j?l;%H0Z!0Hk4k-UhWUxe50*J(?IDxMiCF`VQs?Y0w_$!-HCL!lF1sWz`
zE0R;~xQ4QYfYO=;6DNCl&&#)GfTwTg#h0s|0&4Tnfawt8w^+uJX+n+%iQ1;P>Fa7f
z6cl`zX=Xi71f!zwCGKy=D)IzUOTT@4lEAE$-V?^F(BG&3V7~@~B|vvg&pkT`@T79i>uV4RcBGoIgD)>Wd>v?d?&Jee
z#LfugsD$UI;9_aGt$gkLR7m9=T9cKrhL?fd4Eh#C`Mdk$58Ck&oYQcMltsWZ>bfL*
zd9Rc|>93c>Ej|JE4(@f-BVT5J1A0~?Wx@*^%gS0;lf<@&bD1V&FYmWXJ
zOL{KU2no57WYK435JJr&Y;uz|1cj5E@^Zyl8foNxNv)*X+<5Bg>RAi*yclVy_HTjH
zRwU8d2av1v`x80mfr4!dn8$#{@*S7G{cmD;*r5HhM~KCG=`R%DmZJHb>5(t9Z7{*3
zCy$CPCul6KEZwX}b(4#|;>O$cQAI=8F#RA|;U_px!yjS1^BR+SqvrhBRQS`@Yqv)H
zPmVoGuAt>Hb%}X<2&n~qshy%n9^E)^fH1r6@-+HN)wE?=VOlp26DiG-P&=&=b+
zg9#b{77DGI%6UO`%4Zkdc^F{6`YkE}AM)9@q#}40uo<0(p~=MZH)SoQW8zyY3$DPr
zemm5!C%OP?quXvtRixhgzM#1Z9U8VUFZz-D8@~6Ws;+dsRu{yK;%;U>6s!3-`JffR
zF{F&LnXM_^=tQa;3O>gW?ZNQx;}I+!7CjDEJA)DS!3+%z>BkVtva&%B0wT?&UkAeG
zz5$SX+a9JEw}4yo8=p)%qDP^Tg6r?U=W$0D&8RLaTc0{k#QuKm;@_YbTdY%CRbD)2
z)ht4&9=-;@<%fAUrPdXRk=289Qkdmbc8&6Ri!X|C=+Vt-loUL6?FeHKkUfPV4$DMjx#tQ^-MzLJa}+vpo(0`7#SqGLahmI-krI{ITq
z6ESSQ8VCbZ@4vI)b3$M#U3e06j&%c!aM;mV4pfdh}<5!
z{23Y;oI)k;XocACET%2fFF9quqyXE7UOb>Vh7soxhG-bNq-P=tL9vX6sieN^j-7!H5{zBilfChe9IW)hh>O4~p$yZCJXjWqLHxp=O9nz!6Zt5!5ew)5-;*
zR8}GU)6gQaXW-Vy_OpR5aB1kNbA8uNapP`Tvs`s3%A%n#b6ve9dj7!=x{F``Z>Bm7
z)L2>x<%*W?3l`38wjg2Ih8SAgKqe5_n67{Y`134U
zlmlDPvQ>?=Q`S(el+TI-NiG`tc1*EK?;Ln$o
zB*AM2Q+s7E!M>sD^+ruGReIzE%DSQTLvG?5bLaCW>k?DiG~kJP(f@xwQ5X+TRQQDy
zCb=ZU>!DkHaJSpeH&pLJC_5eI8w$z#R{FM*X|l$MK2T`jqKN?m(07f!R(}BkVm~J*
zB^OPg#i0z#QTRrf9WdccdXW66l{*+nnMf+7MHyv!hEV|Gro}Hl@zDE
z=}4*c-f<-=#rC1=Ct-%GBfO5jQb&;Uz}CNF!Z;*L9*N4Pd2s_>c3k9n}H-d~@Ja
zXww!$?69bkxsms&fLqh|Opck!)}TP>tSN;XFnVu@2sD>k>1B@;!X)H%1Li5ac%yYr
ztNOs=pK-5XFgYU3E?VBu&d>`b+etOdG>$e+uO{)t#OLitSQw7Zg9Uva3wE#{C%S%w
zj&GXp%jhz!L0
zPq`d3q1VqU7l6?cXVhKD_G1g}mmseLx*jp)Gg53AW5=4R@2byFi6TYSJkheaZZ}h?
zs6vl;U}nVKZ!M<2TJaC(3>MuMk$uBX_LIdc|J`qYN>
zPg##geOvp3PB6fL4ts|*&D!9??3m?}`5kq6X$934gbIclVtKU!`l>s`&=6slYPhPF
znK4-W+DS%wPc~pT=+J%SgXaj7CnU{~cVGi5STubTLs1X>V<&z)Ud%CUs+r?OY=k2(
zuuB+!;m%00!?8kQ$U(!O*7tBZA3ry`
z2dqh+9`z_Zu3uS39_#OKroFE(-4;Bw`Y!c$#0<>8v(+gXu&5lG{>{4mk(1LN)?6lW
zxfa)KyK&aKCiORoQ&QrJ#mfxnc7SrES@A
z(AxEa{MlKqTvQ*jeDCcE`z)(!##)rvnKqPCH$k|@W`2+YqYb~BXQ9U|f!>3@8HF?T
z+Z+-=j!`;g>N%pucKMVbwRNwuKYoj6Nmh||`^h~0L(DB{V^ESS6^TC*-PEIwJv#MO
zrQVb)+x#hmH;{yTVe)2$eU15rd=1x{Yz70p2+}MSxekcs66@#FZgh+J_Cc*XJH#vVFG
zB!~|Oiz(hKC(Xpw<6Uv-+>9YxgcjHndCi!ji-5`}Imy?-YDpT00^|UTn+PY{}h$3@fP4a_Y~IdKbcW#fW%FRkOfgJ;MP)eq1LH
z3J_-rI3gzriZcyPEBM~}O|;qb>+7Z5+aqMmJ6BAeQbs*%<=p%2ah+|D%?qmhDy(6kGIR4&vcoQ
zEJWTom$J$`vTsZCD03u$c8NJ8-oy!4wtv6V92xe~AFPT1t5(zyPhQAN3ZKByfHxjcI-suiR`Hn9w}OzD}!iR{F%b+RRW`Hm>+GRJHbgB@BAA_%`3#
zyIPzyvAwx
zg1=@QVLbzY-qYmu;(W!UEv(*;ge;6S!S4k06wVPpO#2d)*!uHs^(RhD-PzS{e3qmJ
zmc&`XKj_S6sYsaMyB*IqS@2bP>#bZB)9t6eB+>4>SAXfaFe@UghaeSn-X}4!{G8<^
zq`+bc^RQr7PEH6*>3Zg%-nWZ?5<6SBARN@0$VF!YC=<#Xsl|&Ap_M=h`3`%ZUvF?G
zo?g4{ZxFpa`PjN`nRfk`L1M;rX7ngetWCQ~$sNVN(#fS+9cNA7iKXouriBK{Y*n1K
zLj1L+7&&<0U>m9sH6_!S&yMVbCIT+>@~8X%ieNc27pxiXed-w}N%!_EbUEJMBaW=*
zKF=T>VxH71A-*RS_q)Tbx8d6$Zr8%xy}+I>EewUCDcoYwm3hhjBt>%_0%)EA%ZH+1
z^6A1TVuMi^6<^Zh#}jsAk*434?}-UsOmc7~2M|HAO$oD%Fp*6xj3MvJihOk>NF&aD
z@2}o0MxDvixFC%5dJZE+{;e5#?7#PQZFRZP-7P7F8o4ca*WRNxGxOBn+XP2Em4-(V
z6I7`D9s`Gq9MnnoKTES|J3RVup5cD_y43MINbd{f9obRk=Pn8>b6lR!k)$iux;sQ0
zd8-RD((0{C7NC7@O#QvGs&ft-`&wRUa^Na_N(A`Mfq7+5eJF!*fHpto6D$}a(YgdF
zr-9x6;JOMUuuRP2u?8Lzdre#(N>iLy7`&9G`~h-gwt*l;V*G8pkg1$>s@sn9yQ$Tv
z<7fLbSKeo{ldWQVG!iEhS~oHBbnAKu{l9e1Q`vW&5b1ZT*r7GvP0{`>R_CY1uHXu#sG
zjCd>vS1Gs{$0_*fTiV7`Aw*hFS6DAl4X$JNgpshI>HD6H$R}`^@%o*S!@^5yvSst{
z-^lYX&CB8`ORy4dvtgIK3%-3&
zF#4-ES4;TYaXpIZVY2Yv#U5_m&nbC7^WP>HWpRSPm_uDrIwW?taolzf-YL|Bo#=u*
zgd~+5eZ+4dGQ#~(QImzu!>Krr>FE~@JDibGojDzfN4bH?>IXIg$l5Riz8T(>rnU0M
zgICb1jZ;1purd4eSS<5U9#A+k5ALt@#Icq2y3Qrm`B2f>(zj)e|5zv+Yg#g==6#Om
zYa5JQ=Br!QolCvCRfSNsbFRgiSO54YuA~g`gH=lR%Eg{FoKq(9@c
zq-p6%?B0a$X+wK5Vf@HM!LaIgFQ5=I-tcLp0wjI%{+}E(QY;9EsA<>1cmMO`br4ub
zrn=R78sfjEoOb`pwFErrYN-FiX5OLsR8xTBw>j3VeM(89fI2;adoCL?SX-0rt-s8C
zFW%rGFm+&DJLVg4rQOo2)*qtd&|QMI-stwssf_gbY^#f+%q!OIS&isiH3m_6ioQDn
zWy)s_7W_zx*bnB8PO%4v}$jvJ^p5&l?
zc4FHB7Bs~ydACUm^7ucBnebkcvBtI+w-NDLV{O(e7ckpCU4J*o4B)$Yja
z33W1t>yxVCg1_$BvSer7=^vZ!UHXjf=u-GQe}2S4wUR_;avO%4utG$W9gL0G4Ie#a
zMD=B_q2-{*`~rtP?+TvSqemKfAD6b?^c9N=BAY$w)-yfMJnr{ghL!aMwd$`=ceNs#
zjwuY9d<$?fDV0#P*-*)7sk7rw%cu3F;vjAn7H$J$jroE%x#Rh%N$7^DJ{Nb`zCd97
zIzn)-U}hO`8|e(Z=z6{lPzcnSRfS?KC@PZX7hBH{uuW^Y--rH^+`qrp(k+jDs%I2v
zKDOBvK~;sc+kV+A&E>x
z=jc_X!1i!21&kws{}{I#Lgs?UQk>3cWcHhw^9H~rZ+7Yh)!>otSz~;ZBttAUWtmus
zYV`P&0oQ8=B9QT&7kEN%?0CQ0DtPL@UuGx{sVkn5)DN>TAM2-dTytYg
zcTf75V>8ytGPLhj)^O1-He*DOP@Im
z9U8DR$ryw{_>PtslY*WP(4*^F%q%(Q7&~zP887UY=S>Mk|AD>5x-w>59zvNp7V{
zw)-2gozP%{FWsS9DbmMg(Gh9c=<<4vh?_rvXSV3d7`R7I!N)^^TZ4~(E2m4g$
zh7nmGIZN5t-SC6+aR*ic^#8jTsKcmvS+LRCg4e35fl8pD&16|=Lm`IMKE^ljZxeMTV2G`P7YzM%>_w5wP2#V6jx$M#@Rpq^Bwl`2JulVq>8jb2{9OK
zyB2~c4JqFd1kBT(N?)j#X3GC$sAX^W5}i9+rF$ecsC1NSil5FhyU*?#fCezaJNQ`E=I5xP1@r?kH{_Ol;~cVoInb>V5R=DMBkT^yZS
zN3lPKViN}IAe!=AMs}Bl0b^x>2r#~%r0Iy3mZTRz2bsbPtn8zR9#1^U2R+5%@v+mv0>f0iN9~m0n?(%Bf34>&HHzg6
z&AfryYqy8FM4z1^8V{QKKmQw<-)|glSpmMzRKmttq*QjNFO@|cxQZWFGRy%sjN-7$
zLzths2~KXZtgsVJe*fF5D?0Irh&3rVBnQN+K!%t42Mdq|J&Q`jyNd~+xO$G&2`yOz
ztWYp7#UCj+pbx>A%T~7ALY28E)qeG9`PwRy?Qp|5QmqXVK)yY1U;|3_9O8aP2EVW!
zHOB)=TxfmA068lrZ!osU;5!It-RFCg;2aP^kHct@v!n_o&*9c3FMHpSU+iod@;6dr
zRtxt_-Y5*O+LD7aI4PA$^WXa8n!XdrxSeS%qxXs(>hwCjOaq%`&S+@>ovo?lkMCA(
z^e00VcPS(h|7n&4$`lCE0j1379bm8>b(R>(w9!+jwJxfb=mDb{^bV1IuDG+?#=-L-
zlNk#FY!;GPk1*F*{%dZz(?B4G>`e8`xo^!}e8;mrGA!cnS6ff5E~)J;(SqPl1yX+R
z>*`XOvP|HPlx$eE_pOsw;$P`pE49>^@wRPR3%Et^E=EwY304ag_)bN<>lBXUwz!zr%A@>%I>wvWUzopUTq%zCXXRFr=?kvSKT
z63Z6<%m82D4{q9guDl+x|TKd8g=i>5*nu_GAsIy+08Lw34?=G@Nv&bOsLa}0yRfS`-Qa>=W&E(Ao
zp=Y;0j|i|w-CesSAUM4zxv=5v2%;aNJShd?aRkg|pE^E>u#l>Yog&Vp=VDD*NCi?r
z?S)(ufxm6jxlbj}>@lq%epi=t$5bq16|%Fk>hJE_TDdab$J)VjQFn2!o#`{ZKQnR;
zCS1XEv&kzr&*SiYDLcgFnpM9qY~rIXM%o?eGc>lW>`vYkW*oGtUrDp#nN~s9G*wxC
zr}p`>`;_wFwa-)B2K5G*S!kqrjr>_uY2l+XJ(#^vTWsH_+z-6O+h8p^`N2Fi4zUnnm`-E@;XTx)GbZfu=k>uns$(P9EEA-4^>0Vcw?IE1mUKwQ@
zn*ycUZ(#a8d9UCYFi{{d|j
z!J65t0A#-;QA+gqYIMMa(Oxi><6082km(e0Is4~8?l>}y!Pimy*1;|B5|DTpw3LU|
zUkTU)v93);q1?-aN7SqaD#@>uaGZiJAeNO3YvEp_4%NiK6WM&Uv)f`-&gfnBBQ=a*
zS5_mbyp!nIm-o`X(Fc$dqi!IF`Pq+6ZpIL%Ktc1ib)K
z2=puy6cEeoXQJq8(gztVD3wJ&&AqpI6Gf?TqFqd|t>W(P`20
zGuju|UHL%4!pKl_cd|CHP%?6sFb_tOr_5NKcqzjHwl7+#Q3m%`P5<6ul4|
zlRRe_PuXp|`&0^U^^JNw=9-3LE7Se6U-&Aig~
zS(ANK`3TL_pU7eAP^^C`Vq*$xzlowpmWtmh0hH_XY*vXT%jp`KW$&RoeG^GSwgsjX
zW$6|}jmJIAttum}>lYsK10}E=b>IR2t*tk)PYz2T_Z&7z%3JLHG*G
z`n*X0x->!T}{nQX-MfH-z(!QJ=KQJP2GkSi7}GwC58YYj~q64R8FkyW^G!X1*bY
zwycr(Xr;hk-o&YYTG?pTV96t=n>KCFv8V4(*;OX1{Pm_4h}Q1pFnMJ!cgA~Wvf%Z7
zMN9RVVVPkifWk(9j)0`$9>m5lX6Q@n5Xe%r(?RV88D~f2Dv*bNINk3aI?FpAf|ppB
z8j#<{A!JWs6##CkFp=!|F@H6Ow{2d)09?BP+RnH
z3FFR3XMJy|@!;fVU+fSSE}JEr)eWI9OJj=%S;LF
zR}PxMhJ`0#!1)}i=`G&|fqu-ZjJDr3lhY{5I+-*{>XJ>csr%v@2DT^vlZ%^Y4#$n}SyLY*J^nfPd&htBV
z%S@8^SaVne;7?U;;P!N36?PI(+do!h
z=JJOBm}m?O76zbGs7g;z&S{XSnQ6NiQkm_%s*@+Y0Gw)R=;~pUMYr09t||gBEx5W9
z#VL0@%GRet$1ZBUaAeA#1(WDJ+p^4(IqL$C&_YbA%k0Op#c<0nM37Z4uI>m*nPnrkxSJTNOG99cDeyzGf68Na
z=!5(RrboQiXGLrF+jWH578U4lY*(aLpInDR2D0j+2Mdze`{7EFvb73i`b+jNKh>Sb
zba0>2XTanYkZP^}+>)5of(I9oIF=VKPv_hIuX6U_gS6M!VC|JrSL7IfJS1)ivCl0L
zgZu3RNyT=4TG3x(0*F%qX+CK*rvhZ-Me^4r!th;2Su@<10s5v6XpsD}#6(Y+|E0YM
zdh|budzA!mHr+c$-8UneN7kGygy4%Paq5GgH}6kPB|VR_>6ZHJxBg`BSQ5p-)l4b<
zpcaVKHKH!-wU@00$y_~wd=npHGa^9Wd778mv7wJ1z;`6l=B8GRP{At5Mkhh7Z9Zh<
zl}z%P|GUxq?cvf{#NULCmb(qx!GIftV`x1=ceD#x{Pd@)!4p|beMn|c&|Z8ZttPv&RRVD5g7E=oh|F%l50ehyOfk*9|IzN@kHl}In_tM0HvXH7vCR=zl77p
zA&2hN^_j*98r-9d;pAeksU{c?cWQ{+bt@C?zxOJmWKCB$n#~)pANny|tyxmJ-hOPHg{33a6;)5Tg?t8ovNd54PFbBxTY
zyy~Mr+Gc5Nd|L?@Z@FarUco*BVxz)${Lr2rEJglVO$AKdw*$)0<@*5$xwBNH=h
rOgP^IwYqzi=Y>0;oHVB<@bCKET<~
zRM|-@wLS2Ua4y@*G)2EYFJyK!_xoyM=-14Jnb{zXJ}sx%n7tfDvhuvJ_Dtc4B9TY1
zoryzRzkIP~Kkk9mlWiZZ#E)cY#yk~YK~=x8k<|OoDwM}y-$Okh_q`c$CThJFA$(9
zeQVnr9kwI{%=kNqos~VVP+dF4=HFTsf^?<8p)2rtp^+}cKNZ_zRZE-y6XA5=(;`O`
z{iJ1eG9e4Qwe;yG?mcR;plAP$|4UkW}Xng0K94b1&!wn%o
zsyq~!%{#unudb^iJ^Ja;|8YKuiVqUMQw!j6Hki%d&kyL(I@ux#85pB$}GadfirT_=<@hY|O9QlvON3
zKoMa!9n+U5jO%6CbQRgsxcgan*1tu7YUU9R99#svC?f4-q!u
zs~@f1br1Wh1Hl<+fMr!?%S;pH8PSw6HgU0{CbDmb|!c+IZAv4uGm!_
zMlPy1$s-KHSFgIW$TbpeGk_3_ZU5u?eta|qHW}e6zT_&N=hBo@vQ$N3yzmH%#4LDe
zAz@|obY6rPJqw82X*NI5+ysRJhV6|UCfO=06p-NO+*4s#YG8w}!YkKc222lA#ukDh
zIch<&%(^3;>0VY-=67I&Pcc_F%<}-?GAl1gik5`=+1SaN*(s@N%GHM-K1ZR`y;e4-
zUsS{|sDt^XpXh{RRJQpOaojy3Cb7>UZ8T1xqSz#9dftHpt|X!3z5E8!HE#gy_LeE2
zI5LR}(0M>0f^*)>#=aFh=+pejJt4&2Y_78sN6rfMr7;@BQTnroF>VtPxuQD|%Fbo5
z(A@WkGtq01##t(Ge
z;;jDu-Mex6KjWP^71rGozC2LD3y%EK-l&?T$Io&&ELnFZ$uq|;t`p0NzRBwoHg2wL
zZtvREp74xqXum-1Wa4AN^k3NPQ95J7^eOj2dDd$Y|4YWl6)OAeI9)?P;p
z1XP%*pPs=$f1+c_R;p`2Q8cnuI5v>71X;?sC^P=W8cG_AQ14P{M%tl5!
z)cnbI)|Km3^?gs;V)38J@7PTdM=j?0#b=?IxbQe7=ji=4u~#-`3WP3yG0Z;FQNZ*c
z@@LcQ-EoQ5kQxy?I%GWH8M%-uLUKq|M}~dtO21ieB|W!Qy7-MX-4+hU`9gt4q(Hew
z(B6ml$RaBxgh>j$5JNaR@!9yFt+B+K^&;gHQ5oXF{Y==Nc#N~Qdr(s+wG=9-pb|$m
zP0;?Sp1EwIJME2S%#$@{bsUZ`$EmQmUQEA0;VNCoeq|6xydMjlDsQqsr$;DmSgeoc
zht*C=mS;tY6+(3x3r6uedlo7O1CNVrV>7!=QsQF)
z?ZZH@umU^O*4nBqSyr+@{_O%J+6k2!LhA)L)Y4ve>11m!lRrn8k1Kwz=N&jx&
z3!=ofaSmfC66?0!Go_xC!0L>y)IY`#tkc)y>M;<+;r=si3?{NSHvhU#ndxvT6V8Ug
zgaJcZS-{aIIa}Umxa2+iqBL>Aqo7CeeG{#W$lE;H%x9P#Ly!qi1KTfHfs%sBNO_pY
zokOop{
z!yC65Y*RI(A9jp`$SQFdRW#9L8@9*gAT4JSf0NxEqsM6N6kFUK93LrrtUTXFO5kxK
z`|YIW4YqkM?b{#FoP?040dGd-7EIMkZxg??BmN;D^Pxsc@~M+yQbqOU9=#PwxI3|~
z?16PZh6U`me~^^l^%_I!{9zqtdiUhaaG#m68(U}1c(Z~^jAg;8L3E8ywMc=5qHhRbz2jSOINj3?aLJW
z6`jBRjtMX2Z!Ld(ZMszS#yrvK737InwgwZ3T&pTj<1kI;Oy+izNigcpuZ8uS^J-I&
zu_QQ7TC$Z`*&X*r*G3#Ob1YHXv&1pJ7YVPSXyQ(j5{Y1$R*?|SBiC-Y~Yuy?oHr3;u|2xrzerbjZ*2}>cm{Js(s;FW5k+M;*&td%;?i)T7=6wOS@
zGVd=j?eyN6S#RQ0Swtt@L?)Ryz08czOHrdcqp-9X;ScYs=2yIw8`f$1K#_1kWFGl9
zyREa-PI^s&Q7cvWa_3#7ePX#dffE7mfLPcimf-D_rWqN-UBrX~EvJC+FfK(#oCp_9
z=L_Jy?yrFSDYQ*FRmZ|>d$vtQI}6;CWu>FZqu8*yWL>`TA56sDIVRcS?~Xz0Snn+x
zav_!*qM3yi^X4$Z%taUPqaR0_!PLMp8rz)xDEos=2mi}wu-GbZR@E+u8UuQ=pJZ@~
zLdZ0!VCNK}S(qIQH9`@x50eT4)dsWLhyEGw=)GbM2wGBlO!?nS(^BS-m=ohT<=XVU
zj?s|)4G#{g$LiSf*dtGg@CB^6btAd*#rxSM^!W>9^gZt
zfpeOFVIdkjPp9Q64vIq>OoD|8V3U-DkBEVWN5#jqeF#7}7ncnRhY0zbA!Xmo&enVg
zfltfu57+VQhb58TtEO7hDo*BJl933dmc>Wqetu!`vR|rZ=1TqLc$<0nIo@^YQ^unp
zR+nT5ZRHmHfvVv-S5Q#!vGO_GQ=?58H;%=gu^d*RBppO4bgLNf6{1g0V&lxkAs?4Z
zZbE6pR{M#G3+qW|4h^GA7>m5&9YJYD+-^!|LT9rv>p8YMiO@o!%Vn(!;@G8>kIspfzHV=3ta@Pbu4%~%VEjS%A_
z?@6%R(ZokVPV|ThU)gK9o8-mu6dIu~Q@2$;_+bG{lPR4Bhu-0{E!MgnRXi&epC6cN
z)DMagwH{~BTmiAMDPaJ!YrA#WAOTg`lx~e(;XxYVt1bG|7+oBY$s;v6_Rtch?(bq&
zHb4C>ioSmZCw+9Sx!mJmHyk#-jjWMAnd-|Os#7v&ZUX2ps;bPto>?k7vb4>ROe#(>
zrB`|V=W`kG0ivE6x5*(S80asFjsFB;@&OmirI^E<@HvpP-6g5v*!pe!1we6ZX>GB(uWe!V3e!i)YG{CC=n%+z6mMhpZ{>V`FvZRRnZc4wGy7>h
z6%O(&7kiUOWs%{;)Ohu&fiX29(Uh|#-YYV!sZpJ!oCEP%vIC`FN8ggDhS_O_e8d(V
zm6e6romtoIJy;CbCtcpy<#cP(85-)u5XQ00l>il!aLa-u9QD$UMfLyk%XtvPiJES@
z2xb95=iZR$vC28H6<|ju{lQpW+In}@fZ)X7%O{Io)z7OdB>e3pn!B_s&||f($jCj-
zA7dL#H#y}}-x9WwxjS_fwPDkpmn}9uiuloMw(Y^QlALaPQ!}^%(p_Ky;70tumvJs(
zT~TtCK%k4V!%4&YWp^ZNvQz+8Jz#C>h@jx>I^7zPW*y@}CF~l1FV5uGY@(D-3wZ@(
zhXGhk>OSoUgLZ%q^*eeVP#OmfTm}U`{DfmaNep<{ML*xiUYaL!0ay^QAVUIwHeMOE
zza9^>R&g|>%m?9a8kZ@U+xNOD+i&BQRk%yo*zJK3=5V3wRLk6Vz$djsOAO`y_Qj%-
z$u4$if`j=xE)W2>1V1E~x$>l6qWQ(+$Y76Jld$}20(Ku905MlLz;pgBRqeaa)wV-%
zX^k_dE~1CUB=I<`+A~oLa-l;x6O_KVmtSAnSNttn
zcI+b!OxdeH_l4>Pd^eHBGlG9l(2q~+$~tu>vNzYs;r)f)Z5_B`vpWv?Kzr&h1$?0k
zz%E<+iT9mzY_;35>m%-{O3GlsEok^)05RNumS>L+B&f+tYodSjt^`L+?|J3i0@=n-
z&NO#wBCdN|$@3X}rRIO$VK3P4A17(
z3IyATI2@A{yPc}^r(*R(eo~D7V|oMZFm^?k5|1rzf}~LXQ&>M`v*toKz>*eTHGEhX
z@)7XTCp9!Ns^b|YA3r
z0qlTlKSz~{U_`I=Y~qPKGn*daqO!X4nDb!ZEZ?(m>oEz$jc5
z*0^jAy&~5Nqq~g(c51Qc_VtY1C|?NUj%~eESjkh2`y?wl@CI1aNIF57iz^o=0xW`M
z&IW1qtO0a|pOjY*t1%veUPYWWJGlZ~P)-?A)fc+bf^Z&@OZ&Rz;D#0YnXP`VMipFP
z^9vwQ_DPwu`kiJYc|we6G;!$~01;Z()UkMGfRppSSX1eD@~2)_uO3bdL;`cm>UJ*%
ztQH_tHb@hRy<0a!B>~UQ0)T+9(RW?z4kHVUps`cg#h;!9g6Y+*35*c6c4_wXO(L7U
z$01-!{uAk7e5WKs&%y_`Qwx&XV=d-kkI1+yBVpZyrlt*O1#@-lyEgv~A0z^p2wSK<
zQoe#Y{Zfr9ZW}%11Ot2_S%5FZ>@V5k7jKK7XI=1zqf&(oz_rS}UJ4)@$2S2`gPIzl6d1^75r+V0YwaPM
z?*<^{3PRhqMsgGAQ&w)X^z!!I@26!+Bfa(5SgutcriVhorh>LNP(%y?
z9*RJ1kW?CxmTr)e
zR=T@cG=g-9bOCrC)kxOo9
z?zfZN!ISj2?Mc8GV!|4s}F%Bz13i{jT@a*4hfP&B4lQ;7S
zHqn~u$G9bHah$LACfEIJO=KkEZ^^Png6c`?9y3ODM2O+Jhgfd4trgQ9%hL+#mn=W6
z`xe55>H|n`^Fe>Z4~Waoj_HdXfQ+UFu5Sn%me3`O`pMHj6_shN>O-g^fY|sw1vhN;aJ8rH!c8Za0h|2-tjFCEgVH3*hoR4;#CsWGSQ@pQ
zbTPSNCy+I8imF&8sZ1Wcp&H$`&V!-HRs(82LrIEpN@m`ty9JCH|LS{x^3pU7|EFh#KMC*oZ(^EZUD}o4SXnI-d(rNb?jm%&k^oPXdwz0oA#~
zx#ScyTb??h9eXP_B%wnO5IQh1wWaCAo%;L@EYMfL8aF%4H){OG=vIlnY@-)7*sjXW
ziM0A9rvuVy_7#DF@;KVYX#7elY#h&(=4Op@yOD%RQpu%2j1FP5-%ACn`)(5^Y<&sQ
z{|SMGL91-2RHY+0K?p{0R((w?A^E+vd)h36%~pCVyMWJU(VW>ud+OLgPOkNzZch
zYU{uJ;^6G(BN#mZ88ODm>pFz&XZ^)#(S0mge?76PHiGMgmBPON>9VNv$@RthN2%vE
z7vWHoGU(^G(ivdKWg0ZMroUjAlcYIh8vkcX{e4sRAK6fkcUk6F-N31HDlVPS4zfh-
zvU409A_`TXviOZoJU4_J2leKw5(!WhZtA&EsBo%XQRsgl|x~GDx@m0bk0=Nb{(}8H!s;XD*N&Wzi{e#rY+k_
z#P$Q|$9<4)?{bV~D8@EWZXJ;*^3f
zc2uBMB{rI;{naW#hn81Io;%-;4XG!=_~6IdCvfLzYJ8eTy&g)81dg-^p3$XBf}ofj
zJRQk@F^oYq@j8wO~FND8NGYC(m0>08QU
zOy2Ub!&CNz6*nlJ!na-~3!?M`yCC?R?xYXvT~g-SeKm!H@?p@~#=t!86
zKT{(7zWWfmMOFa?WZK3Sz&D(xRBUkkWq7dER;NA}5wdA*%c(N7JX#QL?i@ixp;^Ua
z!iKB<-xp_K(ddjls1B+@^@dXy`=8?Y;Vt$K3UqW+f(tTgRO
zJb}?U*Y(+1#L8ApkH+gf3y-Crr~zvXB*N&u4p5V%Hoi%;mw5{8G?4X{IfXYF&o=21
zHV#lke*a$zeTUkgHlk5sF9lq*NEeH%rg*Bu$U}(uDVaQv=a>eL88EIL1F_(pbPU(=M;&|q7+@R`)l
z+mF}IC)AvFhJ6aYeEimvjat_LYSD#!GeCgzPaTn|ca3A)0|LgV3Cofgy
zz{Cr};KP8L#bG=P0{ak+?+p5#1<7{IG72@N5wPc3#Z}wICo?V98g&s30O>pi3~6L6G>SRHepaip=WeL
zpbQk5_tLh0ufwd<&d
zzhow5U}?j?w#Gi;E{XD7^Z*+sZxJawq@7SAO;o_Qu<_>8&9F+fd9~50|GWz2kreSy
zo9Dv#cN;WKSA?q&q*?rX~HM$Mglp0&<+m;kP?y!@l<19z8zhO5X
z4IYf+5_pUF@8S#r>>yj%*axocOLtB5Dw9)AgZdLdEzN9R9zqbo_+N&pS!A>IKYvHf
zI7}Q%WyV7A<#&?@UwHtzxRs@+F;icx0Z=h}3y>VeD!!rUpNL0?iCPRmxRq(W^>#)9
z_+e8ij1v!f#IX@<33kC+2PAw1)##q}9&!`RY8hXR*$x@2dhlL&U_NuHmI~{&njfAG
zpul#uLAx|}55XKaQFvk6jdp(zQWC!q%TDxPi}GY)$sWmIp^IwrZU+ftjC>Nd9y>{M
z9W^`CR(Y+K>WU(aDn~3UGZtiqhWgaB<8E3j#_ylid++6+zLdsMTw;@xFO6;w=I8IH
zO3HUZ`3*7alShP?Mo;?P6&e-A+qFy`F)C9(Y4icXd*p8kl2eqsOE0Hp;!__j62JI0
zwpO4!t4}ViZ|9&=`1X`eg=-jwb}IU&xW^KgDhE)
z5(bImTJ`u3wd=W0zO7+T^re)drdWjW9ZulSm>p1N%md6E)6t_wn3Zq^C12H3WIh}$
zw-S<&8Yn{p-8c0<*or-Jd;&8Ir@l#R*fsMUanw_0m_3%l=s4uA>7yu#sQY{dv6v>X
z=MN&o=G|5p$uU=o){Tjaz@asj#^iMl8`ST=^jdPe8Pw_*-P)_*7msRaojN>TW%ytb
zfhEf;$;S#d#YG36VBALXn;vY$QL(_{rd@W8$|2SJ--6bRD
z?VgW_iQY!<8V`xRDyaxz=yeyI{a~4lb+X&&9vS!^FlyLc
zv#LCrvAxi!)>D3opc}QGCGriA)>J>2bh(Lq;eh&9-NjOK69iMyVehoob(qo|ky{T3
ztCnBYwwI1Vc+iS*9^SvM{0@GzgFL)n=bT|H)wW~GN6_yu;968_tX(T~W0e}+*k=68
zac8$()k=GgDX*5~t}>|Q+)1yjWL5g@Q|Q{a*^6G6HGu#V0WK`Y$xgG3MTIFzGra1w
zZ^LNGMjMry6STK0^^)|_%3Mt{@gA=;+jfgffP*dSR^qqR3%4GTNNk*H@PVj_j7eL3
z{ZOuuW!TIi3z(~G#1XRkVTvQ;Gn|N(zof5*GA@Lc$nVYKg}Ym-SE4`ueEhF)8QLZY
zu<+lNq&p#B#n479bI-O$o(Z6#J-mhLm=!TbuLC}S=sJ)Iw~
z$vEuwQAk)oOb4eEw;=%Fu~oF#)-gs3J&r%}x@-)L09efDqhwRXpWYy2>Dfg>v8YnH
z@9wuEg#Qb-v=zg~o#zl6+9!w>sZ!`pgQw^CBky_pYHl$OABMK-7z%nuTr;%=Yxj!R
z9E~PCV;9j0=vNWk?KX5H3nuX0i)qVlOkQppf2)C$fi;<%Lr*C(p4XBgr1WjHoty~X
zMf~l#Gu(&LU+N(|DdA6R=F&w%Bsoy-G$(&NTijN^VEl~PQ%T@G!~NLB?_mleXBxX_
zuQs~+?(QVL_vweyuIV5R+eS*j4t>7HR|Ob^$|#R{4jBhLyMK#9Npy+%#xD~`@Xk?S
zDRH>5-xKJuOazxgI~e?`Od^@~pJshgGQ;c6t%4?8YA*Vopr8Mpt0I(MC_;aSgxeru
z&)5=WL({B2D|Y+(g573(oYP#T=_ru{l2{HjTWVKh&2M5)_r(-xjwY13n~maG2hI1HACmdM}!LgjlDb@vd}-SbGtWBa!J7r;Uv(0Hso
z?0S?!Tzy7h6tk~tzg^%6h>k`
z%90sJ+8&*Y{WapTQoM_iNd>Smt@jG1T2KLGR23@A&HJ{bSJlG-(DoKY9+Mn*xUj&2
z4FfdKBKKuR>!8LOHW5C>#BNWmVzbo%ak%ingQ9do9R3#!Q=7GdfWQfd1ADfG_*HaZLfY(
zBbzii!6by$_)t8{y}DB!7YSCsMU1-&wEYG9iX`CU_BkZC9zB|$ssCiM(3W4li_1b8
z1N}h);ejoZSk3pr8!+>4S=q-;f4~La0$P_!2tO6Cw#2P{k2g?Cxo(7^yJ_
zhdD15mN5J`y0F$7Y7T->rTg)KCMZ4;@xTmhC=O4r+VV1atyd~1Cv>nxx1oQey4%T{
zY(w}VR-D3RKTj1?(~_%-OZo>X$O5TanUGL~{fMx4FRyel0Zq@`mKaSAEXLGrMyMQq
zTi^Yq$q8f2Qk38l>p2?vpNk(2`qHn?z1YYpDc4b@54_eCy4R%lnm~KYcq{#l8+`3@
z?~~&vN=p|S+q~_%wxo~`P>mM=R9~Li#HWfIz>GY_m;LzS7X2&)u}Q~E_tOAg(tXK@
zIvR@SO6k~`1K~s~9Q-;`;He>Vl{R%SY`GKFdPL~4FTqM(uPFAAnqEhB6
z$Nw`1Qgh?QDKnBJ_nuGf$QdY*{|m-OZLSQK&cCmq-cV!O@oXC
zHvc}|?nLH1WB<7X^Q84}8$49}*Q?IQjvB&=S6CHT=S?Kt*g3hz6}XnWmxlQfO&jan
z=N7&$0zO$O+reEaTwjDfXw8F%N=FN@1RCGtPAwfqV>MWC6pR15;8k#m{u4fNrW~r
z@GAbn>ng;P6%dr*D(;iWF+`ut=|9^4F^x%I59RB|*LQ;&L}3)K@>gY1%VwR~@w}?c
ziVJ4!u|k^1cp6~>)wjZ)Kf{P+UCuylyZ!!>_spv9GXtvourDKz2Yj^
zjq(wPOG}H@a?Z{SkwlYbp2|X}vITs|B<@zl#Tr1M?;fH#COt?!nSPn55_6M{#?**a
zcP!Msep!d$M@JVih5uP_y$1UW6F+eHDYWK$U68M=C^sJ0l}2mID&2S_;YTd1dC?+D
zcZ?%3?eTO>SdfbP>P>pVroL=BuTM#FiJ5W>6m%HcLwYy8B
zQz`kXFxQu@I@t(C=bL>U=yxwJPKboyH=-^hFOevVE5=IoC8Q@gQg*|!BjvF8%_W-5SjD13w$Q{Kcau`7)Zp?-Kr#slJQv2^MrJpguzWJanWy=y=yN2sD?UyWwI
zP__tnitf3E=_mc`Z`N3zc4;TW`2=O3=4%%clZ29BF(8~%tqgi|i}@m&`XeFib~+R&
z?vW4jKfJMnx6`4P79W5z{z7w&&l%K&&1#t<;j~OVtl?kH72en|$$d$sEjIJZH=9-=
zG%e4=%l1$xlZ&L==S#Z;%{3CNhI)WYd=3xQQ%E`EBUAnq(e>bVC;-)kz3EAylvuPx
zgcvJ={^8@(2$^pOy>RWiWwY4lu+p!3wwP1GC`x1i1gd+#y+*K)oKYcX51>Qu4j$fC
zgP%oi`*T(1sE?}{zpSGCw4KBx{wMuvBu1O}%dQxWai06)*iCQ{#|Kn&94DlF+X8hF
zG$NV!X%RxRV%a6)e?o7~c)s{HIZ3`Ns5j&J+J9v2j1dfHl+5vqV?FgH`~N
zmnZ24yi^lR-fzv}%+71!EX`muqH7q^U7r&s(tZp%EsF
zLcB{Fp1eADvJ2Nf9r{17haN1$S2UIc8OyN$*}j}WYb5&<2#vLA7-UXw1YI~O#IWS&oRTg;Sk$6zQ6{tB
zNq)EZ?=OLiI^wS8vyMi-5w_tkZ=~`#N&X?|
zw3eq#h|f{@d^aQfV~rq=U8{Pstad`ljQVc2W?6+kt%F%JW2?|w@YFL`cLgC6&J
z6Zmj_>I!?e5&sME-(e(4k7ga>pfkq?v?zs`g63=i_>7{cF1?`%^
z^KMv9&ff%fgU~N%%s0*~2Bc`K`3Y+Azli{nv^6#eBvdy;-8uhG>MZHbAG#Fht&dJi
z9(~|gQ-ay;0s83GTy3TyC{muUe4q;BOH~bdb}iBM5<}n0q}A;RMyYIa83AV5>(lp1_+Q#ZXrMyx-E793@2Z5)>VVevxGu(qEoJG^!zY
zjX=w6JH?V6MtcNw8O%XWAfbmyLOK44
z>J(F9d32pV;HJ9TU_MaHM;Tz6vG}#n@b)0t&_ywPMk+VKFkc8^Qh_^6=G$}jr-;C8
zmz+rC4&)Z>gKcXzVyXB2yGsD11Z*xl)Q2)fD(Lj0-;c`}X@#3NC(C{`YRd@^Kf5Kn
z2cQ9taw%j&j{)F={u00bvtIwx@rCES)Z1yJ;r!^P-Gsk?=8$_-(uWL)x)<*Yo1j0;
z&?@O*$#h<%hE4&HE-oMuqL+h)!f!
zo)=epW4d1mIin|Pl|3MNJvk5e5BOjMI&yUH^R>$QwvmiB+2p1dNx`2Fz2Kucv8Lj`I09S63^OUU_%#i|
zvxMf2Nd_wArZeeVw?Ek)dxy9$8Hx|Jq@N{$T!JAW3CSDBmJ-j5UmuyB8AaYX2m04R
zjRM=>YX#7hK0c5cNJsyborOaf@)sNw=`2>f`yWuWA;SZmYDV}XVxJCZauNnIDr&9N
zW)W&#r?EsKb3tY3JG~kKfYUoA9B&^i&u&4#>FF^PRjsmp-!*`=td>V4aLGjmW{>#O
zrm?GY&|x1`MvKFyn}UozYn|BDW>K1E*EK5No7|0)y|vEv+s!(|9>Nsv%K$^lD_Gcg
z!apQP50T$j_azixwtm;Hq)B)ywI{|@q@wScZls1_67}x4Yuo1EO)kkfekXz6!+_b&
zgoTlOYniOqmkA^yE++r@0<(CV`)b*?8&&F|uQ3y8!HwPQpYsA836h6Q5I6x;8kr^t
zF&|h2DJ5%%O#2IU_R@xH`i$rzeH)BHr;u(i=8zX}d;v*+w;D`JVirN!3zqY3bX*EX
z9a$}-w;(a)IQId~YeCRc69l-wDvCf-_ao4!|R5CYuSuQYd`#q|;XY%G+J1_v$vEK4DSn8yy}2D0@1;
zV+%72f3UQ;j_``~?UMg2H(cjyLT+aMk1|vr4FUU8w~j$;zW{0!RsxpFu=2^4hM%4(
zMvKYfY9)k4`Yh;5sTMF%TeEag%j)aHo*1NdiUUEi$2LFg6yAAH-0{*-fv!!4X%0}u
z5hA7H-MjKQJ3(mDLeemmYz`aL7rim>im`*9u(wGFzbfNMTNnK+RN-*yHU4w2uUmYJ
zIm*XX^+GDtdA%=Olw|s7RkXPss5SWf2JX4C4rzTyc=2E=%L@RfdFxu1MbsPU?=p>{
zI#fUG(OBX6(Br6=^cQ%+w%c#d462rDmYZCy)AG#RI0_x+(XBoryA-8h@5aU6$_%1H
z9nt8XuZAc;z>Ym+Vb;SSF(XNFKQ}Gj4IpOeAD-)vq2*3~slXkv_HNNxzM%`9a=^n=
zv6C-Sf_LNaYhE;=ZXgI?98Azqx41>WR3c<9y9TWQrmerEO9dZ&#o?ULpP;9a(j%V^
zdEdzLfx8((gA?)Gp_AI4i!ohQk#*zdU;9wm$aB$w!IV9B_Js*f{_Qp
z+6R!;+z_kOAgb^}<{ye1P!T;2MT=yB^Ko2{eIK8={(H)3@b$PJALfY%=f{&K-rg^og8?R
z!3q%Wfd$JH<6V+N9a)Z~*g$jAO^;aiDaQJ&`v~q??QWHj7|VPKpT%f6+#LH%&?f7F?3!}SP|{xRi7muY%49(
zBGN?M;%#V+Ne6fwoSY@C2l!>kV67nXN#JveQx+Wpu7nR#pmzLOvJ*e{`cFwE#)Y=v
zIMPB+Uim5r>|@YJmu`{HA;(v+zI*ZKF6igj2Ibdux^0HqTmEFIGy7o1_sW<;=j{A|
zK)f0u@beABRq?gbLdK?6S^WB7LBcd8SjTOVUtoPv)z453eoR*3{GgSu?gS;Q`KiH{
z0LWPir;9lfFUWV>pRkl#cKmE&`yJ<9ajwXg#@oAEzZ!KDT(%&e_%i%8eCFEz-iNw@
zz}MAsF6xQ+B%aOEfMD%=_0Zm>QBu`Xy7dm|we|zgmr0K!Wy#_PLvXGbws@2E6gbN%
z5CgpqkL;h5tVC14Xa=>*VjNGf4Xt6nC;=x*W)*3?y7s!xT0<^6RDX3IGK{d?KKHu3&v<2Eit0u;_
zD{vK~>$NAGfOe=Ena*|hCnhO%#27hOx*$=nDc_u^vGmGOo}nq$-{cbeJM7EnEZ0w|
zBQ5$CaG8%zndCV4A4aNU@iHcYO`n+u$XyB+_2cuZWhrs>jyOVr$p8kj@Ig^?;sq*E
z59!|`m7@sI06(q>_rFYS=WjX73ahRPJ9z7#u9oZdI_dB1flGtT7?TB*ww&#P02H66
zg#4*r@sUwkzhzPd-MS@`5C7Y`T=clmu$LFoC9B;?D8b435r<`h%WfE6B|PSVkbm(B
zOu^)D%V?M*b}N&KWCKZ2Nv3xI(1$n2c+)<;a_Y>~sOgM6`>bEodCW}s9>hH&`26oK
zw_7ZIQd`M=t;830#lFlUe!o)rN#;2{S$NpMasBtxee|obIkV@3r#Q+j?S9T-QaKmn
z{R)q^*O-dFt10hALK=vrT9zQJ!YEgeaXwv)|9-akoI-*So+bg5kNlNF;jhVqgG_n1
z)c->G2QrP5Bk8yaI
z_X(W%Rr(td!N#|(J6ODaJ+Uk8zEDK}l`qGD8ple|d>(EPS#@NDJcY3-%TtL`a|vDF
zY9r;C@fdt_6axhwZp_x!mHhw-q2%|A2Kv=?GamZ6=0~$u9hR-Fo69FZr*95i{VtP4
zOU!5avbiEVXn0wDFoM1!7`~+1kt<=HzsgNsZJPNd2wQCSFnAjxiH0I7`B+Q_l7|oB
zWRMZGMai+zVhcj2@6X=S`xZmX$wd^ju`p$z@jM4r#^Q6G$LEY02E@rA{yQpkTeJg^
zK1?(*CWLnwQQ>tR{N{~P{l@EEUhc>KHHEep(_#Jhqfk
z^Xx>qk@x+?N>^{u6WyTm<@-+Gv-zU^>x1_9%Rbjp5FyOx+%$|mbFMLBzi9l%X&fJO
zl$&=^ZA3@f#lBjk5A%}h6D>UtdeXx}79p_lJgU~#$cWG^hV$RUzShpjGwdCjV*)AU
z2B{0*P@%AU4N>c@z5TpUo63A)MlBr<8wp$MFt6kHdo~@KoqSolO-^*4G00LtG1ePt
zd>Sn;Szz~#aAIh;a|Y9SVG*7Q)zC!q_<#_X(Rg-8Fzp7v#5%G$pm<;^3gX*)A2)#L
zgho)@8ycb>)&xUBEuf2U7j%78&x%CQQ7!uJ;oA&|Sf5;i6_R+y9^B78C%5+(80#TC
zqkx#$)F{4!A34UI)Anw`ndPXB`gX_W9K0`0MPlIvw{L33m^WULvVf7R?!ITX7CB6X
z7!8w`%*?&dCCVNx?kQb6{Dt+o-$2Th$c_2Yo~5zZ=`K^mDTN!(J2!C{EW<7Bb?Jq|
zY%%!23f_G5)a(@dNE-P{M^APU2KH5RJkwx*8T
zcN}#HJbk5{6sx0yQ4dmYw)%E)0zT1qqB5RAKjt3Ad@bx5QV+Z2Ke_hPBwH;Bi&2(A
zyDJ^*W+yR_B2MJ6nXipmv)50DB-B&nDzuuy;=@~HzP#(1D~x`x)W;1w;Ub`uxSKVx
z2%wrVq?d*Sqp5Lua~WRngRo2gwr)+
z%o1g-R7fMFf3UsIsJeZ#|Eg_Z=^q8tBWzLA8Mq37W|nhbD8B!@P`7F1g|$hkt~h01
z2w^}>X4QC^YzD@Ab9pas+P{j}Hj}GZ|MdU=h$IPcgsC)Kwk^h0=2p*JX-f)1hSSyFeB7R2=d8ixBIPz0lc}RBBSt8tmxyT*8CT
z_k%aMCby@Q9>ah2#PjF(s(GSq2wVQvm&l0xxaf=BIqHZ!=lzs@1f7j``RA6=|99Ku
z*+6U&<;G`OAIPij^3|UzhBhR3QYV;o=!#Z&@vdPwWzug!E9AAzZBW(WWHc)g6dLkl
zJ#e^m=$FtbjV2E36Vhoxjyfaw?1V3M%+PA;bpk1VcPT+gv<#EX{R0ML`Z=W>Wj2ei
zOVckYpjl@b4mUU|*}zg;;5%AyK6zEgo2Og0MxgOczc{G2TB-6B|H)4rP(Bw!4u>20
z5*Wm5*I%}OC+dh~p&~!n`+S7PvA(`<)$G2Pe3aZ6Y0{Z^RE}!7vuN=8)<1zkg0p7@
zq&EzEybp?u$&YKgJ^RVORM$mG<9mPCbJ2=lnV98c$$UA67)-Eu$Lzdx5OckmGSbqs
zJY3qbik|kUnIm=HdfAuX#P8O9>zMt@GTFfNQl%ld**eSjt|_vC(VAJ+RE3<)|MKtb
z$QOB<(Tj^wa@uRbf7z6d5RQUu#f1DZ%{)2F)`NF_)}MwigqqU;%b0b&3_-4*!SA;U
z?`zR{_Pa>L{+o-?nT5o9&#+~(v6t=TMWrM8XpN>9ecBOk48Qo4eqRg10`$~(vh9WO
z@lJZ%hd`IVROX)1k|k!mpZnv;MXWRVJz@OOxG>*cFC9NnmkqaF0(>X=!COv;%;xra!~
z60AgtoRv|?t}o9=P?Pw_pD}81I5UcXA?yclAa7^9E7xDGO!NvgRXk-)2^Mm=X~ceQ
z#3;+}Z^u%M+TPhn@|v6qB-URPtZ~7_R$D&Y94rl8{|s7YI^`Xw>kN^hzPLKxz5+tv
zUiqEISJjiNKb6*S)aNL)J7=GmyoQy!?|m9Z+&PYkof8k2uvkq9Vu^-HN74$44+m7;K?iRKBayDy_yGr5sBPa=cYZaXVNAwOyY_
zSZ0&|Na(htdbz3p?DjfSl*bLZIYkj9jQ_OK3@f(1sh$5(QqWv?a#dTU-9E~Je0_J$
z4c3L%p#4R6^{L}~U)TTlgDFz^9F`#8`n}#W3jV>z^1BOi=^n2azL0r%u!oi$t
z7`CGDujLv~7`p1(5>KNZG5(#H|UCBR+zf|b47hi<^kR0F>kG1|afoZ0n
zSI5#cD2}lo3HPLS9{D>V^N7w|>gjM_Q
zGI-X$on897qR8ckfOatn9B+&N{6%h^0Zsk^ern#BcliK^1W|l(@*l$szPF6morJ&x
z(m#xiH?s+5WyJxIgtS92ydY6#H>X!Nnk_d9rsC%+{n>iLYGsSYTgH{57Q9=RU1U_$F7cO5~H7ddR!kfdWg=)O1e{X5^}2+Zp~
z@uG*}7k1VgeE+wN*B(>-`|8WOV0O+_&l4^{=ZK1q=R}L+zwA&uF1J?Qm3>tc@uUWx
zOS_LFcx^)ju^=pnO^dFye-j)=i=ecB$`)1i@gK^AL0l|eM*{e5oazPN0JAF=Nvw}C
zgbv}w&H8Tj=66$NdDFGxC5_`f%J_wMm)U^d?UiCao|er&`oK*pv5ODb+}MhG-^aft
zn%k@0Z#FUC8O$smz&%g63a0wbwM_?mC9EG0m-gfoS~!V615J)3Z;3ne4lZNK`G=jJt4^;X7=134QI)#6D=3-pIw0{D`8&GpuF7Y8`+W82l
z!@tvl?TM|nCimZuaxn0R*e+_W3D2o-+K=qFdxKT{;BC(5D-_eR!&_%2_p?d+FLYYq
z{ecFQ3VL_6sRZ)w$SX*Rcl0&kG^hpV;4tzT8QHcM)d>)5M0o(0bt|^Aa*?;=Q
zy`*c8rI_-`bUeeJMch^H6QVW~Q+nlLXZx75y3rUN8!a0ey%OYE?G47i`+=YefpmcE
zsE-(pD>Dy;>yc_KoPaGl&AB-|xs;Dk%C)kF}PXlsx(<(Spj8{Is!Q_p&_rU6Tg+fYF
zdci^bXFM3#_gCasQ5uBhSq
zq_FwJU@GaWFx=LmrzHbxy|wnQk%$1Edz%qcb$+kEV9={CQx>O+u^py-BfwrIx0jPn!k#h;a}
z3|BR1TxZ}xnRVPZnd-U~Wy+YDV6^u`#PJ#zb8X>|EMRA3*V@4e8{D25_J#{Z$qUiu
z;t9_3N2ZH(h*qcA;(6=hghx&w(fY@h>d@R>x*@##lgsZ1&^|tVs1@`VFr6{-ra=eA
zUu3@6h?UM5TbyOZlE(_Q$VJwq07ekhh^tzUI}NenLQz_&)fNsiWr(1tdhLId~*AhyI#r(XU7easE@Ss5ETeoE6}8+A$!pV(xj
zw~DvQ1?r*%!>VE9k8a%pXg$8Qpr1l4l>RC!Q%fJi_dr&g{C#AK4P`!dD9(CrPXr0}
zPW_UXJ?&&uI!*+eG73MWa7;)<2%2&B
ze#Obtuwi%7xgnw*w(}VCIYAP8*(>H#?pGa0L8WX^HRFirSd)4P|L(t??8KMFRlP%O
z^7kv9Yr?Qn0=vIpgG`)lhsleLqi6<8hZMnm%QC^gB}0LN|116M%`!NBEdmYtLd!W!
zY#wO$p?7d&CCJ1vt)2_#c>`g>1glCuTViH~(cJs0Yg5`@xb7u`FFPn5ItEQJv;AX7_s(eY_Gs#1}CQ7kF>2}r$;qo^GaEDef?Yl?g@3uvUAX$~_9b+s+>#q86hd$eiY?$Voo8q2|2ghYX{o6fC0SNh&ZEV_)G71IN
z&yG{JVj_I+qL0qM6Y`(c%p4+O_1(Vu7RPQli?_ya$IljzBqtC0xeN|Z`+JBvG=_%Y
zQ9nH=;?`p?Z_LfNS@Kwq>TRI7tbOTeNINtz-7!<7H-Bmf7pR*IwRY$@g@k4DJ}X|<
zi;&InBVb*o2E~le+-D2vFXa%8wK%H8`1lSV#t)`%+jqFyFU*itrs9l9cjaH8t|FAs
z9r(n;lP{sOMmU6X9>FB2n5pDUwVQWbi+7udQ&PTK)%xHf!Y#wgcUZ~qagkmw_Mnzg
zPj95Y?(c=Ij2LSBuhNaQ#$)1lzZsdk1T%v}5KUW;?7{FoX~g&U*V)OX`-27{3W)O4
z*Z~rj=RareI7v}P^hZW^-q`AK`RbcEj{KG`+r<)!8C>vMLh$ek27@86AG7RVYMkHcG
z%}5ji_6a1;yAzgH#SWF6~vm&I@HfwfuXr$d8P@x
zUz(Z_D_k>8{}be1-Blsl*r1s2+e=o`TRKE!3cdpthQRH~q#y<9EV1%Tx8KCszn!Ev
z>dPZh@$b8rtDZ10u<_42{}HNt%lRs+9S(6#wIRH{IwjH)1@nn!;2s-w029b^``L2b
z3l}lpzO#~B4T>tv@vlj~$dgD!x6@-^2g7M_(b)jBUZ{EEfD+0jR>(XK`KpW-j}{{J
zlw5N{mXc6e6r`B}H53lgaUJ;r2?PL1lACmbwld6YEln~-iJdI&TJyjAggI6!+OLYe
zHuykD47)8l2VJE-RG4XYWdW(pI<1ZKu(9JVd-W{qM?FTZW
zU+GH?>3`n0CIab=w3fYndVXEIlug_VFK*)INI%8xC~i-!P|(7Ebs`FCdnSD>P`e1@
zumO{CQ!q{mQ<|UIwaRW{V^l&>Iu(Y7ps@9mvfu~ElM*q|uTS>dJYcap$szf_PRd3a
z(?XFCAxG0bG;wpp5F`Gy9U=3$Gc;AZg(I@NjE*tVFn#f}vRk~1zDq`7%23avhq<2M
zRw&(U0`9~Ta_sFm{YrP5S*vi+W@nC=3)pz+IuL<|iL5hy>#xCpGbr*uQH3vxR_R6vtuT}4V?&Or@v}|Ve*_3JSjOH}aU}Y_l~XNb++l8k=5a
z86KMLxkdgS3}nObkAQ-Tjawr~FCAzEf}WA?=Kb)bj`&~iJOkq0a`L$!Q05r>s5T>Y
zMbDUOaLCM#fwrL$=phU+N5OcDV~`m5=2;rRQDc(_LTU!sqr!R#(_KEM7p9!0#6VoB
zueO`p3(WuBj1Q0b6{-w2n)s1(>r8`C`-QkR2V@^6LbN#-H5pzyAJh#dQvVR2+JLQJ
zsB|I2n&x6-Lbu=WD~FZgNdXu2$#;+zRe^2W0a|XG7qQZKag9B|$D$tiJdNn`Byzed
zELhUe{GJS2e_h|&P)e|NykGVRC-&4
zrtF9PX)0eCmuSVcaG{*KAlqN{F;%*6l8^r9HPDfq=5r_KzpC83lBT0F+BuJcq|m%f
zu)(Z_qD^2`p*$eyF6r0-?ll;GAg;imX|@?--(NDA`_H##56@zlons-W8&f*0P#_;XuWaRjOS{+05%p
zDxf@&Q6Uras^xgYQ1`sO{o?%H-i&Iz>Pr0&)AA+@0xI9bzh7q|-))&^$*gQF34g&Ju_#fN)DC{rZIQ|Pe_08GG{?Bc}Sr5k-
zbX@c}2b&6!0sf$qAR@KcSPx*9ZiyWR@g30}#Qh_@UOeJ=ADw^#LTLk!-u=)e2m3zW
zH`q(3$2WdzEP6Ox5{Ic&ozGBBTlF0YsJ`E^AP2hG5Cs+lq
zxVSMuvUfxv)%!nl<5f;?ylFc;mONi5oRY{GKH^;f+a
zR{bnA=+Hc0xJJl(R1v#8FOCFZVD{mOev&a}80sF6^A18ws8`vEH(bP3s+DS&
z0;$-o>9+JW$D$5d=7MemCWSy%h;+WEFx_XA4Pri}j9;MDB+Jn&^U1^GM~@lr=|Ho%
z!MXFV7LcPCvg~*NeHB)Ou5@9
z%f>ve|0yTq(z$Q*dsR9v-Zbz&c2L&!
z7mEEyZQNzZ+Wrbz+ux3sMU6mg9wA?Aecj7-rX#2MLnazNi?EAwGbmHW3>Y!&9a{Ig
z(=QeWpzV;s+T0{kf>VVM@LuwBbs$;%4lb%1)PErGVqG9$55*BhX7%^pI{!iaH4V&1
z(c2eH=3Dw{d{uHKS9E`tc?$|kU%$gMxK13@<0!g*VcgrOs}koo3M^WBvGo&5>`gCk
zbDJ$wjN~wRj>39UaH}y1Z9k^OgTLsMRzVyOM+J?^6|n9fG7N~t@sb??y(jb>70a-Z
z`;c3Q&k*+1U20OJSzsruiLu7i7Ho=H>
z;kya!XuIjX(vyeM
z{cj8Y+YB}VAw>o@d5IvnaaPa=tK;|^I-H49w|~kCZ)`hEI{fgmHA&Pm{}R1F*_~Ei
zd`uTX;rm4|Gv$!}4m|;Qa4I^IS@9cXVn3{@t3Sy0
z*=4JORBTQXW;=C9aQk~JcAk@2z>(!Ig0{x8Wo(NM(g^*JeQ#H^V}6ss2{v$xIY>@(qg
zx=+``7o{8U0q~Jk8&s1gYXr_@0}`~gr&5%M*e0w>rODy^XviJ}0oVakc9~)z6?Ko%
z5+N@`f^gW6fR~F(~kw&&b$e0SU*_q*S{=g%38GtPeZUVH5|=X~b#JQF_|s)GSPQvdEU
z5%#ReceL!WJiOf2V$-yQ_BBNog|}{3*ywBFFl=Wu&OT8%u!^Cf>R9r=7;QdT)yA>{
z<1X_^_Nc{S(Y~E_%?Z0J!MhI^j|4yl@7}uD`W%%*s0SP(<&8%X0;FmycuIVFa;c0t
zho(NUt{-7|J4*~oUBRLX{f0VplpQN=x@hH#XhgTb6K94tQD+h4o6m#f(Qx?T5u${A
zv&Z}_)pJnvU`Or+Zi$QbUo1Ew>fCoZ(ip=Zn9=wU`S!ro6Tm7nz)y(*JzqmPfX%L0
z6JA=sN*uJu>Yo&4puv3*X;MyDo=DXK6MQ1b4AsY)mz3G(KTE3d!TQfs^s#JlIEa0k
zKascu%+B~hKp3P;IJw{-SR2!^WT^$3BQ#To!SMGL4n|EVpB%fLUBncs(2W7(=`bQ7
ztiuRXmSX}C%4PsvZ4RSiK+R?mZDZB1le89d7xC8cqiPzQ6c~cEu16~++HXyK`M3iG
zg%ojclBA^Alax^nHK2<4#yt|ppEUC!OXxL<6jYO8Z^@KMrDT0yjPrM;z>vxe4R|-`
z6ojtYDt=4zff-u5KIvN&tvD+G71(Kf4inE%dVW%skG@c`OQ&IfPVm
zMc+H#?>5To*KRU00Z*AVeUBBE4ubl|-IhMQg~$FdJOU!IRNBr-I9C6?F-^|4^1KLC
zf68xzPq*)hJ3iV2X6a@lbO{xD-
zX#8{bEAt?~AnJ8_MMH5q$#)u!&naZ2+x0Z%hs%@H1GS%FPZfx)U-JY!LCKV!dNA9(
zCB6#gK=!&6+IHRb2rs?HFw^t8Fd-s1nUhO7_`1S5$E&vKeZKIZ{=TcumM%Rf==>}c>Vxi2R>My6ZI9snT
z8>=p_`${>3$Zq!(axYc~trkpf&Z@^bV{;Z?s48?d78o}<)qT}hN_r+Vqus@3|C=t~
zNRh;w!|8adr}=o$X-t@}nejNwrejS%z
zw8`mSWD
z(tfwDD|X(uMVIjv{;(sYj|#0{*q81YqYl&-!XgFJCT$vbIOnn@;QZF_LO=75o4aul
zzabHzA9UuGDwqq1fAB(Ty4TX2SV5f9w5wq4mNPNfbb4$@O#F)u>T-ll)SS^e?WZ~4
zDZ{KT+5TDel4rM~leQtAI#2hTX%9PuZx67?Yv1eFf}!J~gDl?U-JWfD)Ccc7XP=CZ
zX?e>@n+dJ^3n1HIL%oJNh15-gz-ZS9I4;CTJKw0F+?_Cru#T^G3b_>phHzvT$IxpSu9jaZ`vjD<*?G!zfNdRf<#r3`kNokszC-ITpeNa
zOJ&HxWAlnb*#hV<`eYu7W+AqfMOXQu=+SIZ&Ja${4vCMPZE~A8SL3VrqGmo=Is2Ri
zf?ND9q{y6Ki+#!86Wx#u$Bi1loeP?1RQe&td+mQf5s2Zv8T)={6(qy4OW6rpy{_Yk
z(r5-IDx_4un&f?$zh$y5^5WGJRCt^l1T_Lpv)a^^^Zj2zkACvbI>y4RGn}Hxu;<@$
zB2~QGNf(NL#*i5-9M%Hc*o@AXY;%`$8Qot8RKQc!vmAL?^-C2ESucrDzYZuI&?h4(C%Ll?lS6
z3WS#eSIuDx8XfVH=*8qLQiLr!By+(gqA05z}c_Dxw+sc7ov9v{yy~iZZ_QQ<2|nV^Q~<$RR)LJDOF^
z*IE@XIrImQOeSh6+*+m2B#!LZRfRD~d&cDL{WThAak*)toJ!g5U)~|l?g0h0N)Y)!
zy8tGNHGe8pF@E9La^7wz8}R5#1_P7k^OoSY#O`eBo3K=eI+rc*ycY;msy`>
zHLH5m$8807QMgV?oG?!&886gVlo!3j1W=NXcqWbU4i-ACpLD#Le()s2xjq5gjsE+6
zJlx2)L@hft(;X)MD6w@N=gRJwJInm@uiIVLxxcYkTm1?dl@;%#GvyoE{U%ndT99xt
zMa`{eFC;r4NRXM`TT+x$AgRsf)K%3VBn@_U)ibfw_YvEvRLVI2J{0>u4@L6#q24@^
z{C!^s^}JHZtBkqsu-tw{>GphHEbLuMO*Ngl+z3_iOLh!++UBf=I(+%}vnV<1-(eNy
zGern83~E|B49Aj2ekbG3^6pF=zn&g{;<^b{MI`#MB;H!*5#@UcREPLyI67}_F%PIV
ziGP$GBO-*nt`k;894*%XUKgGmXOh>>>e&{_*c^b`^7Cna{hA@@0mYBLseZSW{WB@y
zVn6TtCg6h<{AeIL?HMwoF9LSdL=fu3F2P$PnoZj!8jG#rIE`StG^qHdAx27&D(V0n
zy%c8H5+8w`rQq-**u>ijb2qd=xntj&a3{>=cpq3M0UNQ(Ee@~OQe@_!E-j^9QtcqyS
zPkNEjw`}Sb?n6St@l0uKs#hInCI%X;hhuJ843uTx%SMiIF_>iFkMTT0sPa7Ewm$P^
z4RToLcsQqa#DZ3X#$2T+3BzLz1xG{I9ne|CE_SYZI06
z;Ci^F_zkq#e_vKr9G($q5mCKNAt?ll8uHJghWxXrWzeD~#4mbp$>NfP{yxVOMkA$s
zBVqq-FAf!}PI>vst77R-7LhP@uG@02n?fq##5z)`#adthliG1m<${7|g?N2B%
zK(+Kh(V=DHM^A?^Bd^MA4%WY4pzoXX`&z3O>T{Q3T7k{#Y9q?AHBF_@a!iDnlgfJs
zKjAETI2f-1)+;6K2tlPY#2wxt!}>B~^Vc;eO~-_{gJj0U4^wJeIkM)H
z_Jf{A^64
zXCRh5Q7RitUn<5t0Um23-%7a^
zC5{~*W_#VEAM7ANVc%bKNCgwus&-yQ-V$PaX1vpG?VHrz=uWZkG_GALt6<*z^Pg(2
z01;|Uv!mzufkK^23}HMNIM+zOq82avktcP^U(}&NJh>k}%GY3VVnx$|r4=T^;h$7v
zoIx#k1PS9*Paq{(OZz#i(STA)ZdC(5lMT{erT{%IxUeLW=>SwFI>9Kp4?$>KW^LLR
zI|HPw2EArCS;897T+s7Sp?W)Vm4)}&q&h;(x-3ycEX*nC(E#LZ)d@B9$WgqX<2k2fB35|;N0^i$P0I+C;kMYN?qvRgqOFEGQIr)8)hZtvOv
zlT2H{>wG6ZR$CMC`gu1+%(%x*lx`G?BY+aJ>lz$4h9xunihydrWTfe+R~~(tV6i`l
zoRCmCjs>!l_9L*|Kb%K;eQ^jCiW6&Qr5d&3c@<;A+
zaNQvfL`zBs9kjdSrRg2RvjBPPkb_K#*N)|_y#_y+z(4*J)yS1daPR#=l__vWp1aop%e*B+NOV
zD^uWP8FfeCnkr6Tp;_;r+2p#`jNe%8FBS{=aG=8%n
zL1Xahyq1L|7|u{58tRgKdRX=;hB8VDuFCFkeB(S{pPTO5r3;j7Vqv@>Zq))m)OzkQ
zjrMA@@0s(%MPQEmV@W1xCuu>F9F}JWZcycZ56OZm5GEc*rA!e?y7BVJI{}iT=muet
z&EO01aHuT;lsq@40Hk*W>aDxA(^+Tz;O7b?
ztBPpl(SJ;p{B+-eS5*8FARTH5lMPT&?SdRUn@H0>i?(BjVqMhgEaWvO7kf&GFl@A4i^aq{_
zY=8nqsv*&=mRZ*^C$hzTpW*B^g&4M?5F(|bb;QtRs9gv~)>F517)wqA4daSC?+W*MB`-)=F?0X{ChV3?Sy6l|ki`MB&j@PylYA4S`hW<-
zy^>W~w%_j6sgaV1o=lMvVKwpN6g*nmH0TflDWoZWQ8CysG_WD*
z*o5GbaI6co{<~*MQikpPIt=H}Zh#DXmE7yx0E#Ss#nv9`J#QbNjYxi2aKf~3$-r;y
ztPP9TXx#aRYgK;wDn{$7qK`E;$_40>5~tr~hR<+xlP)zl@3H#D5k%%Ec%Eukbk1lp
zwweg$$5}9oeud%kyRk4mivY*BmMV07Pff7h*Oq!ydfv6DynP-H8}B;%R>cLGkdP~O
zzW977oG~m@G^TQR0r)!LJqg&6qo{^FL#X6^$9@quw#Zq^^wfJkn{sg1yy~
zplpxQo}q@=5x3Kz*IK%)vO(cZXaueEm1=EGj5#aeza!LfGA
zqEObf3Oa||%0w5-a4p^AP5kQ+gY(GB)UT;J=DqKl&)@6Ybw0+L0p1tVkV#gs6KDtL
zz7KJJ!*)T^Ij1X=FO9^$bM@Fy0^F2Wm9`fTxT);_!cA%QsH1)vW1v!tIR%@y9w2k`
zf}jo(^WvTNaF9j)l`T(DZc0prrD8QH#76j;sPVgaApGtWVszpg6dej|m-%UIq%?U{
z74-!cg4JQo`%gD=ugqjB_}8n(lEI7NU-2!>_qE+hr9JwBeQ*|s=PLnG0rbT8T|zu1
zI`1@?(0)Ex_D92;0S$_+zod%^qsV$-+TK0uIHDNy2#NRM&1-LJqE*gcs1XzQbZ94J
z!t4Rh9xwzyOxtXI*q9z)5YTyNB$Ohb1n$G}Kknn&xo9Yr`^+OOfwA%bv>=b~jL5{{
z=0{);Hvp@(iCNGdx4Aw)umQ68Xp|33MP*{*s5Md&{it@8yNWt*_NQCGsgng6(>KAR
z7?h1fc-x-;lD8K+s#eq?_H?$>6~z5$K3|%&r+Mwn9PE%EVN~_IWz(U>(J`A1?BlsD
zoOydgaQYmd70GfTPr;C0d^V&|IS?L`MT$os3dVcd00zMIJz--`L}#grV&0zupb`xR
zNk<{h#UZHc#%goTMfhr-X-Zy(g?DuUz`R&VCjgK~KunaGhkd1gO!t?Q6zzUWI>sI)
z7p9@gU*owu2a^X|ZY?R}3~|oqB{iBKC6=1h{{%3Hr@Gqf(ToqhhGiyiPT=pKbAV7J
zFpo0w8_~$V@Sm(Z<5zR>fqcqB6bKmsN|a6}{ivM7M#
zTqD5M+ni2s+oW9!1zNcP4!P?PPPb@2|Nv5R@j;keV+kwX+wejsES>Du+Xl*QLpk24$S|$Ys|tFMRC*
z&{Khc@u~?RH8L(`AYsw<2yPG1hw(Y3%TPO*J4rIAz7EgTgnvJPNSLh)kP{d4j<$7m
zyukjqd!4FCTeieJ=1$xwJ`9%Nd8~;+LT>GLX}upP;z@~6u4*6ZgqJ=(@={>n>T%@b
zbZBl-UoptBai0;qN~P^$F6(2hkcWQg#7AvJX$_pfYOnb0<@t}
znoEa6e|r$=U3WUy_B`#W7mSzomw8$>tzl3fn(WJOeo5_+?-GzrMQQ`*KC-bB;1Vuw
zyDTZjalcZBaHT-0eRA_}!I5_#%0k%Hb5GD2@=7}Mm;|VoGw?U5
z%f9wy*L|C~%`O`;jhk<@9c2hKaH@;KcNdXY!2D%aMVf4-X5P#FJEnSY6o#KZYnc7$
zQ;u4rzs;`#6sTO{#LEc+2~r$}kL=vkMds5^z@2jdRw_}@EQ@KwP!<|LGW2%SB!j^F
zoQX7T1rplSPRw$E`_Ss`jaJJu?{Nf7OBS|F)11_NP!#MJB>idvljoSAY+7W88Z6rB
z+K?1PqD4cdw3bLE1pVwS?-9jaa|)$IW=oA1R4zwXNey2+pN0R(9;I!_PZ4h`iq5#m
z0D1&=OaC%zu?M@jkSjveA6rpFVg?&|m(hWaX%T31LFFE%@MeD?x`%JO_|RcF3&0J14NmKgf*5BW0?axM|q?!=ncoKC7M9~H}gVS
zn7kjyJu4zWe4f_b!u#-+sB2U9;UaJltL&V+paJbehNRBS*E
z{{b?>F~Z4U%|h3QX+@}WoXJ}okQ7=AdUS^*ch-#6)a?3cSSNR0HampFYOCMphu7YR
z{aJW)^l|t>Y{EqlKD7#MhwSgMQEjmq)b`UhbT;@2UhPLPl42Ss&^pa&3`c*F%f1^f
zhLq&(A5xTXq2*^~^2?-&-}J{m$YPfMVhMptZ9bBopt}&A)DB!Yj4h=2$S
zLy}%`jB?I%tA4Z=I(hX|_4K8T%8vp$Uy=S<;ty{ouS7r>=r?n{{>7fgtISvAfMiMg
zi4L%t(U4vw8B)A-Bs}8_kIvidhHg>U5bXvG(3%Cg6bt&c=_hkKwDu2>4@bO4WhJdN
zj?(@kO_tc0wx!;?FCxB^g!BIM-p*{7?3VW)U^zm@X4;0qv@@a)$Y|7#jr$jDA8nI>
z$#J-6#h9f9xqF&?B{eM+M>MD$1>2rqrYwjo5@t%TkC^gR7$O0`3Rf}K1T_vBkzAo1
z`ze2zduo@=n-d7?*<_)zh6yvLzi+*%5m@lYn*plA4Y%XE^>r0xWEhG%erJH
z@5=jKhIuEwfgKcEufgLRU?({PcsA?6e`gsIfe~$=&NwKI7pj*Aeqa;_vz2~6Tq^tl
zaKuQkcJxGaF&)o@F1r+k9(IF?3!PdoRVW#(bmPbrctY8I9072QgD{YVsH?Jmj--vO9ZoW~YFIad8GPmk*f~{(Vc2;+E9OwK|3({y$5*PDbzU-wDCa{6pvH|m*A|^VF-?nqg!8zK>3{+S@qcT=#4ZD{V9}3fJ
zz=JSJR!f>swV)Ix1p5Sxn|OLVN^D7(7|ZY)je}1uf{-akYqc%@ve$?t(}d4g>*8|&
z|Fo9@vc;B=vUPPoZ%eOt_o4atume!bgnZF`j~Yk%@23%Yr3t=R@nFy!WKs|GAAdG!
z9^!(Vn^L1<7{qn}xS-ouK*}I1Qw}P#dWiK6jeE06&@{zSM=uEw>BbS=QJ3F&UR<<|
z{m_P{PVNPW^}AsHS$t=p=hdkb@Ca-@e^uDku+K_^rQO
zme#FfIRCzCip&4v3RY;#+^fE1{0>OvN}WJqcyrc>hDRsEZ}vpl5j5ZMCw>Wi#sDk0
zI+9Z%Opo{Ur6V-hNFx5N9aVWCT4fEOl*_FOaj7djF7(J`xO?9Drq4rA4PTop6soP6
z<~c^kdtH!2>anA=Cf!BBp*PRR^uKRHLvn>FbGyi4jh;?fRb8#tH;4Gs&uAho!O0AO
zw&3|~pb2By#XTQ7-JP8t05n)k8@z)oc6?1PYcfZorxab^f{Hw87QT63mNf3#3*TK=
zYIK1#*}ZnVqK`+T{p6E|Lf>==p^i58w1-i|uR5pQj~-f6_4d>-2Z}G^PBZA`Q)-c2
zD@nq@?n?xWfdS#VkQyPnubKe|3yn1zAIf@V{OB(HvgCxOUlX`a_(AxCJi?w-!MVr9jvmRfu>!4We;t0X#SOPqM8ALFE-l0<&
zuR*{U9Sk@g%&~9Q7GX*aGWGbeV^Ij{w3VIg&FdTP0rpLF1d8e1^_nmVbIw!?od{~2
zag!XJK{}k67XJVm%ryXv>9G3tfmJ&T)mk0KaO#YO({_*DUucjJDFA}iP^ko<#EskM
zBkr8?06vDy3p7znkuZd>)OO4UiLi8!Zf)>m~3=i`WX
zYWtw=3U>l?Lf8@l`~h{R#_#%UdvYYYmv|dwX4BWnLJ-#Z31TBERu!}TL(GubcwzfT
z#2LWY@)Z$4IxX`X#Upq${L2T~ay+I3PzbM=fbmk$gui-lLQm{89sS(>b`Lx5Krxwf
zQhMwM+)~os-okaJr~KbXxq!H4*kl5bsgqLxLc&l_>{B$v-&H@e*y&i=zIH>y(rVit
zGRer)0B8B30RTpE-fGbVhQ-s63f~^bHm)RS&w#p;QSGf*e{{tsRJ`G?#)z`y0FAe0
z-cSk^4yCo>FPku@Vedjwqim6Ie;f+Xexxb*mW?312&_TXGuU9(ixL!p)(evOI7|gK
zD9=iiY~tzq&&8M6ZfaY(Pw(9Vu!FXrcx*5Cvs*6<7}U2rB#!L_P2M_J2r`l-5!ceS
z-~M3rH;opAiY#)|UtLf}sDkQ`tjzXNA*RTW-3q+d7HSObwV!FT5Tpj$mt+8$)|Rnj
z^-U_&yP|i_UwU{#8PaukdnW7*hO6-bWV+^)B=A0Kcjl`P7~ia~;ukdghobi%j^v>r
zvt5=H2{xLL*`f!o%VKtHgupAH-2`bIiE~mk(60O=WlnTQRYO_i*j&)^-G2L-7u9U#
zZU|FJ)H`A@KQ2xHG|Of<`Ni{UDL<_*a^~dY^cx)(yZcu>Vro}a$d3F
z`Q1*29dMkAx(JPC*dK^;Ra5{}e^K(3@UK_?z4`YS^Nik-u8Z>sq3(ldwgsAgLee3t
zV9;ET)AoeQD658Ad)-4ubIiY006il3X5{!0K1w}Y4%)M(Pc^2Gl)p5#5w{-j}c8N6ivv8uq=TNQnekGS@8
zD+uFAg0K01&rRl_KOgBLRoRJ)ToKV)sT~QCT)JXmIc_FS?~114
z8kqeh9HfAl=y#>@A+%9fVIL{Q;7=7(*KZFgW-w)R4gm4LQIbISH$*(NxdDw;i1=TC
zU0xbS?%>h)E_ztGhy8Z2cGj)1adpZvfHd}w~j9(TXd4ye6uuEYT%@K^3TFK}4k0<{sr#
zZ=5P(<8mWYEzjf?EBXPfdH%p--0u3FtF8h8T*C|6fl6-?u
zH3=5lIlgt58_DeBk$XVAJS_QuXGEoV%o5u%5B(|3#)Go
zje8e^=+}bdXAYJRx4PCP-%T=KzAF5e2Dq16a*pA)LUefy?L?#2W5PJ`KKowgwNxNE
zU+Yh{g3cxe{MdwHjVepi8)0^gu-?UR*
z?}|QIBx^?!nlFq7&;}OwmFv4<^nNvYZj#{e6Tr|8tA7n9f72krq-8iZB4j5-U+5d+
zE_sRY@%%8Qex(V77C#_E%X2J!w~g$KJ@65(N1Tl<&?abz#n}E4P*`nfy{L%ZrA?-y
z?x6MIP=&ujV0lfVSnU7byc1@msKwejx4v1RaNGr-VuIZ^@QN~YGVz%OzJ<<8%oo9|
zyJi)2V~PvnrM7-EG5$+{AL{@W$Uvo%N`p6P5JWZuaz*Bi-05n|r$lGRTGSm>zN0Or
zN5v*Wp7o83du9KP6=FuJQ+i8F_o^K_xqm%X(=w<1i&c}ffo8}AdyOIaFw2d~C?5d+
zg`#Ew1E?{G+)bvfGn|C?=MHF3?1D@$AeT&c@px}eAt3@S1^Rw@f3%;u*1$1J
zIe&~lO`PRuqi6Q9cTlIy@43b7&BxiSzj&mKM&I&m$EW*Sm{RG3>zt9vGg%i
zraAzUTWXSN~#y#A+?hGYLEoNP=!>#WXOh3uYpp-vp
zlt{9?_XKl1K%=8W5{w+Tu?69`k-CaVsL|iRXlbnhMr)2nB>8}LEi1ldF@$LbSRwrR
z@kQD=xW)5|r-PJkw``NO7v-)>B1j}`=buh7FBJb%@~eEH_|E`Cl{K!5w8AfL2956B
zWe{_r;t{mVQmJ`3Y#vIaek>B>Der%{(IJ*Hp(Q4znhpd|4>?+wW8@{CI`RRZ@ea>>
zPZTIFE_<9=zm|~w{f!|ykO0om?S{YI8&UFkT~83tT?u#Fr+K~-p6M*Z>t
zNNd@$l0f;OhUJVhx&{aXc;lEw?V#1-JMDdU6A)+FZ$R6mRj{kIS}=a}PqTYy47&W7
z=}Z>{s=DGR56foSrW+NN5(n=1qO;nT-k!DEe0E)P0;PH#)K>&a-34(`WxWibPc9Qo
z(J6jf2C4Wn%^B$qbjR=SUBIj@+%0zW-QQwG6~mYEg(Ii`{t!OIJis@b?Sj%k@Iz0E
zvUvinDh!Brfs4Ms0SO?aX&Z%e&j1F-pC88EzC0y;lKc*%mK61JGaSHMjv$y<0ksaI
z2qbaCpD)b+(8#@6%=_9G3H?gnXeng&3G(s(n9TyUyd|llXxdSg+t8lhK#qxEL+xq2
zmA*lHno2pjfZE=5k(I6X_#G<|Z7<50L0dB>36Fvf*9S1>xE3(VdRuxU8Bz+x!>lZg
zz_kKJSfET9-)z7UlrugR)S%sOr}>3kUw7s)WOSV60_uN2rsH|1@iw$Z9LksK!hbfPpu=2&@C_CE{H`
z>p{0vuX!dyV3+>um}#;J{>BrH8PIehNLzh}Dz^^f1QYVGJK*eeKXvfHqLqEWjWRzsLIo
zI015KjfCeni`1Dqp2Tggj7yNz_ANF;X%i+9X9o*VrGYW3vl<1_0j(9R=klkCA5zDZ
zv;+VZ3%YPIR8183SA|yw!iLTfI2d^qucNjKH1ZE{9ZueaTxwWXmyZ47r>SU&L^%U+
zM4T}hN%>pce1;?}H6Yn2RleY2OElNn^MgVN7Ul1&D#1a6BUo#KQHaOwE
z`urX-J!2$~8L7bP$)=S0v?wC7;oi)XoUbC0qaXP35syps9~D@uF@9CrPE)?tRVMF|
zf-~7AYNQ8>=pmn1bbBnEaAcV1eO19#6@yT_h>914RXQVKPwN!3{|Jc^*7)3e&;T{L
ziaMas!R%r5U3<(o)TGYbYRO}43b;krH#V7^)3IFvevBPdmz*=bUSvdM2!c^lr>9C0
z_bumOWT;SM#bK%6+PurqidXCSLR_Gi{)6$MRvPv5ZL>$IpU3qk4C$Z18Z82@EpWRFN(Z
zq5JR7z=8d@Qw<#zHlZvvQS^9q#!>#6lPMyP9e4qe1b>O}jd*gg(|Dj~g15fP5T|-1
zV0JiES6*sKeim0=F%k{SC-!vokrAyn6XA!=V
z^G0A4`X836$DY(38+97RRLY{r=NSZ-6`7yCepUCE+J{NRL+tIu%&^XnEx&3`xL)FF
zy(hI)KibmLg`S<<>EGjS7(*b4N#@RKy>xrLJYRjpte
zQLT0G$0SR|k0*=IipDpc+(=bJS~#5ja2Dxb_(^f(-5=0CD8Y1RIcv%IVp4K@EKvCW
z{;K0g2z@c4P1+f+0cPgP>7EP09yFtz1`{s@cDTktv#c9QpoS*@=lNEyLj2KmX={V~
zZu2-qN{GpDois^wf-;L~+jdN{1S6R;FA0tEJJdISZ`$x{xF~m=W_=^i?~LD9A-)Oq
z%Ul0HR``&3NgU%>K-D5}JgWm|?%)7u_U?lAltYS5L%xO!RV5V_R&f&^okA45W$qO+
zX`O;200@?0ZNSWe-&J@;wn7AZkxWnhH^#qrnqhkq4($fD+Y-!bhEZsFS?m9Q?9k$(
zE)6hdHR?@_Nty85ZwP4Z5IinZu;Pcs|HFD!_5cGECCKckoKRat4Y+g7dsLDbPZ?Q(d62
zR2BK*EaF1l;vN#vX3*2ls0V|?YZxfsbC(RO14U49{)FnS_eHo}N{(~3_Hz8sGnEtn
z-X)L%nPbRyGWMqeD~9=ivRBe_Yfz(Y7QEbuWwLWzh)G%EezuE=zCEPJYlsEeecjE^
zP5QlwLAGnEbBM(Aix*URM1Xwn_4nyN*J2#($M^JVOntwTC*^%bmGVu#ZyMqo>`p?T
zlmsV)C*`l3(}eiKgW-fO?yql(s^{5T^5@bfT`BH-qz6+r^7C(JZCG-m3|caRG1SO13*l}3hgTfA0x#C!WdquMk0aHdn+tMs#Y
zoL&VBPR9#QD_?_2AUoApMkB%I)^!0hm{Yy(r^D8T3
zySlpvbPR(P`v(uoYidk8*hAM^oAPlf9^B7sZ51}+(wzI+mB?-6RW_i7JkxK0^iKb|
z&U2JMTE{!+zI6znP(l!pD5G8=Qd?=xXk{cxyG2Gs^wS@lp4JfUkdcyd8B7!u7KV?I
znud#4_oN!l#kjtE2fw_$46}XNV!V%lEP{aiFdYHeZeg554i$-VKNhu&K0!r?h@qvq
znHzm2At7P?_&82WOY5DnaR+nN)vWg0ZigUsH8q8#YCpew7VqCb)%!R;H6@pwoh{ts
z&~zWVVn_=>C6o@w?l6x@xZ
z2&D`x#gZAG-nU24ML9QNYdJePG>A7ELMs8|uL`DVo0z
zBmf?00%r*Y{1G4{!UP{_#LDSp8Ke~w5XkK5k)4{D_>z)BQg9&U|CEjno~!&uRh3AT
zIkPw52c`)UA`HPthXy=MXf;wgcrg3V-wJ&v)}F6jU7iT
zU0?rFUe0m3zc9F#hiiVooY^PjaE|`Zy50k~LHMPO2K5mEVlpL6&7zh8fw<5Hzx~>w
z_3jh>Dvln}%F2tT@XF*`WAoiZgxS)4
z+1c+XE0K39FQ}y7i+uVR(NY^5w=y--`-PJ)!I+)LBG^=yOS1xu2W>?tWTGE@4;Ma>
zAX<|+Sn6vPE*7RZxjr;^MAorT(AQ>Ft7mrW`xSrP853ITrlea$H~7uvkJHZ*y;kK8
zBCsE$@&4?JPY2kl7i_((#z$%SS+E=-gt;l@=U=qE*F}B!X
zX9*zgZgY{5YyWa~(+XWoX^BmEnxQDUKBd;)Vb%5Q1?vKu;T?`?dpgCP6Y`>^zLlnt
z?xxnOwD}*8Sr8Q!C*S`bPpBa)bE+w*wYtI^tw(>*oNK5$Y&AzW__4V?F4)S+-yLik
zD&)nDb8g+douro7n)Hy}7veKQDFbw->7PIMkNu2!y6(zDeU^FjC?QG2V@Li?|Gl^&u@(HH^zO&IJM8-Ywxx8Tx-sG&FeY=$`Bb`Y%**lBqUtf=aMQ&NNDj$
zNXRF*Fu)c(`(r*Nq}$@=5)#U?5)#zPb~dKwmL^C@&jTVfF|}0Ni4%3hzKGw#7Z;aX
zQN+(gPJRCi<@q-6GXm=H`>0P_g4viVobDo%S22AXF?VY2`8IO?`l*yQ369gEBKAsE
zzPnAG&DO>b-lVNb_Sld9v8#0vTM_
zQ_E(5t
z_&I+{eA$3b@C6I4;c5Hr;OAk-A7^;(5c-HcB=ElYYKy#Qfc*IV#qdK7TSp|)y{TuX
zA1QXw=7jO@*v;0eiOO*=u-+B+58R=esw~)hSyNfiads^t_S4f$>q~$#XW!G1+hfUe
zPd?s%ewz;Co|P@?1j%vhqnSY}4YT-ww|9Ext3_t9zQT9Dz=D2BRq(vfVmW2(c#@2>
zhRJLndS%20WB$JCk2xc%OvyA~Re=m^(EmzByoD)J{WLN+P&bmORcXvC?gyTdgt?3p
zP0GS6W3Qs_-baI*1C#!0#+6r3#6D^Df7t7Ouy#5scK%^w{}uUFFAmg;CM2^sR~6Z>@0v_VP%h+t&BUeS1MIl_YJ)uDeJT46!~A+
zB^Z+dyvYo|a8`Iqa6EjDjF41Y9G<9lAsfB6WWkni;pD*L#bIvgC?v~yVBynyiaq3a
z_?pU=2GT}afvWf8s|!j`6T^J*PKyg&9i>gf_zv?4Y7O4CbTYwhtRpmbln-ANe$pyD
z49D-l(#68W%9yDhP;`-@C2$NFlEgbP?+pe-PwS*F>OARtw#h~f0h
zx955)$eHg;B1_;7fetYPif75+vR;3i%OS`K%c4;O6}=gX==)Aj2Vxe8Ew?m)w|V1)Q!~qvh3BE
z)sDX>s(U1#y-<|zh6LsELKL&gB(37cY)f^aHs95=hilH630YqPeBHRUhW9di0sCV6HB&un*e|)SG#ekB~OsS9qdj1M5h3t~i2i&(_SQ
zH67#DTYV%OBW)#v@J(2bSdZ8kTN1ve<<+rp==(mbH9RuSKkgE-`(pmVy{drxfM3QD
z?N8v#w<$3`hjxB{S@Pse0asB%F)ck#K}bO?PCJe+nka6Qx7rNy#4OeqXS!jV9NF{1qcNP1cYG&
zj)5>1Crbx+fxg$qYd;qs^#)!nEi8qvm$a<*JkEXbD&><*X`tJt<#LyOo?YGAGe<0^
zn9aV0y^g^t^_i-v!*udVtH5!Ta*gu*tp{5K$8N_D@Nh!7L!cq#3Rb4v_D}Y67=Cay
z*q1H8>J2g2GC(&tuesWD+UePyn!U6vIehbDg*AohH2M_g!F%d(%IV(k&UfZ?8gpiQ
z3B7o57I(gXS$-yFGFnumEu_tk8jnJYjEOo`Tsy)w+J;)#@TH-zA(%Qh`F(On^7#+b
zA2B~1e|S8!e%LP&{DI(ElSI^qshRt>F7Y}L!)Te2u7WaH=}yH?$IgelPItpTMm|}I
zE_lM+HW5@3NGQcC?eiEi(DD84@1fuD6ucIEqi;r8uM?YtKPB9KOCS7z?}@d{MD>aH
zN!qS6fh9pIR&GE^vu!|Wz&0EOu0iWa7ow0D2{2=Tczam&RL;06g(ZASY;I|e(K
zr`abWC{#bNfArr@3M3-!<@DgxG(9ptHHk1g#2#&wo6X+%wShajZU4=#Z1MI2{o+=S
zYP)==1+jU6oum~!kU=qFfU%4u>SHziTSWtrN+kle(b$lMkX{?6U;biyn=0h1?0uMi
zb$;r8ROz&kQ89JhgSk%DVNE^0++T~opO$*RAJdbbVk5ItzhS@UU-#4X%Cjb<2!$9NRlCp0%|!HT3TU$HeXbdD
z6`4KjCZD%o%4C!
zsoDQ{ywWm%(Pmh+EcR8D(F?j)aul;)+$8ctBq}k)W9stR#hkrOds3{IMtzB^>kRvK
z{n&Zfd6l880d9@Kh4giIS$Up~?s>}jc75mD<5Q1S%uBp+F;20>)9{1U)n!J*=Y~vm
zW1d#0#8;bJ;!_RY(af_QUg#WJzXNY08Q7qD$D$xnCiXryB3c%6eM)GiA%Jp?#oY68
zZ|;t`$c0zPs-G7hAJRxM`h)spQ7a0h-)cy6BFJlVoNAc8&^`OK9Q;{~m
zHlOCYP9-M9%Ei;yusyA>(GyqQZAX7ff#d?|lZlqBsiGnh6Zm`!2@RPH2_1Yw22W9B
z@_&DpMt+Qhdb1q`3F(75653z;K)^fV@dZ2)$NYIm4f99B1m6h2(gsd!hS2eOTF|oFPW8>h27c&etV8Nbi+anKT?D~LD-(xT)Gk(**7kxfA~ZL92!hXu&FnPPH@i4k
zh|p*$DpO0?*qKoCvT?9+(1>DFQ&S7u8Jh~KNJ{^8IQS+)^TxpeCdkh2?Ci|u%*AG7
zXU6_SKtO<M*h`~q=~(eojJ_G+{T(3(eA6)HjWM=
zG&G14{rmCfI!#>6|L08B_J4H?bdVkK3;Po`4)%Yy4GtAXY!y^CcQLWlmNd5lV+PJ4
z%EQ4ee6#=m`sIJl__rgq{^!UiPxv|he(2wR`p-kv?M>_?Y^=aJ9Yp`r>)oeW&p*5;cDoz)>+Z9=lFGO6snyK=$(~`Md=kGU
z;_b~Xfq#p-uevYwas{99>vOEy_vt7o52+I_d*5EiI67J9dmgjBb;HY}
zNGNFWC%FHsN8kb$n8X_xH6a8N|GP){)HBUC|7Ei{wI=9mrCr$l|1wBO$PAvS|Lp=Q
zvBB6yz?=Wu2;Jh}CI2r&ivLsH+gmj+p4R_A?gZkictgPSf7$FUo(KABw@CZsKW`A?
z#NZZT{I?7E=N2Js?QCP;d{;)zFo5o6W)S#fBzcYnQVQ{&
z3cqYXDxMD(qEE8$xEGl=ZdIP3{dTj|LO)^A4*%qAJ-_=YCS`bPNhe!%w7P~i-Dwv&
zV$%7Hq1TSGCuGlP!U(?|K!f^*Z2W`V({B8~;0$(4|<5
zys>+x?RseR3ehjGPTIui%_+Suc1_DhP31-R(`~`D4H`GeJDqyF9pk#3z_(xRW)@5#
z&`04sVSAX@x`&HRVfXXl(gIv5c-X*gHLd$Id)>%Oxg5l@;gHc_czveH<+3wlylfWz
z3S<9dJ|yny@|IyoQg?5LWHz!gZr#_I4M-An6rG)|_CRHSw~b0u|LN1<%j0RWJ14yY%kk<_WqM_TeZhi{L1;s
zslo6t>7H!%Um(*B@K!al
z&hZ1I#P5^i4X;zR(4Umdbj0rLgWTfRx9{dL1-D%B)-8TI!kVYR5ePzN22_=Js>*(K
zWAJrzcCwfrPdf8u=a$84yYIFrCW(3kc2sK`dhk3Ln*a8hjdQJMBi)Z!=cn+=jIZge
zABj`3i&Yr#YxF)@c3tt?9Wy+mTQQ@Ed0T5rr*Qp!CixkS9-&%f`h2U
zrdY}+?09V7o0v18#pl(XK~oC9Pe?Yj%kF$a+}_9rtMW-xj5`$38w1?^3PyKC4wU!f
zrZ3XxP89AjK)9>7s)d)?4QQ^Ixk9Zt&aXM8{Ai3A09R8~7-J>)pw@T_8
zFsa<}r}b8d)8M>`id^bTeVkMw~`k*LjzjOiiW=;>BBLTTF8K~Vq?t^k)x5=L?p7vG_-hv
z#>m=-GXtDZUJ#p5(k3$$uRX-E7F-Nhor_f5vS-b=slRl(7^upxJ7Y4?(_c3L6E)U)
zWFSnmGaPtcCZ2YSJIEO|v>B=QG{SW6!p=5|d%JMhYhEULUAgZ2Qe99#;F7z1H|So>
z06$vn5!&WE|;N{;HH@nV_|IW}_xixob}wGGp1M9|2Djf!^rdKYew?
zm(p=8L*+r3&wqK)-=@Ew6=ZckGVKr}{=gw7Bhjs+La6)l>@aQ()#12Ae$si`gCr`d
zYDGCFy-0mgFHQCkRm4{P`oO^CTZakmLY~nJb1<^9AGQ&TkP32y<9;_^lC2L-Q0)O?
z3aedhl#N?2DS4f#7KMT}t81g6=}!Byoz1t$oHk&xx{IW)KM}D~8@6N4tN5l3`+?q>
ztKn3am~-60oZoz1ce+I0Uv4vf;@0i;$$T_I_d-f34;71_XZPhO6`g7@%8_kbsEA&>
z7&)xt$)SS^-vms;nE7`oE(_hb{dk#gpVWG8xq)$t~Mf0_F|0PYq+Z!(r{FD#fVJ#vGw(lE;xTj<&=*%mH57q{mi##$?
zt}m9wO#06@ZM@=gY<$&BqULdK7HvzP`in*Oc2~9KX|IcUs^2XnhVijx%(bB%-g2s1
zkz?MfX)W{H8^6C-7M?R@V%w
z+JJ!?eQwf;#So7_nlUJKL@&Pf_S!eEC0O)qhqi++DlcJJaJuWR4Vd4lUoK8RL|$-@V|t0V+QsCs#F8t>?uFVh$6$%uIwX(mimQ@#!Kz
zS?oEFt)KNL*QnVwY73Oxlu0YG#EU3eeE#Su1^URu(GrL+iiDDm9bZ0jWsMW4dye%h
zt>^07ete@flB;v(`P^srIn#qR(dG2h<)rBmVo}?2KAsq_jl#CTp!ekCD($SVc}HHN
z+P6_U8#^%q5bI*4H;AL^|M*#dSY&1>$dZlIfMObT2$-y
zCZ%36m=&$AYWGwe+wHsMN*jQiw%Mv$XR`-BtF1FT&Nucb8z*6Dy)gO8c>5q0%&)d2
zqIykLuearb*6C|?YJ80#W)Ze#%i40asXI+CbRG^$B%D=(eslYQPI6K_ckGbK{O}b9
zNJW&R#7EK~%P$?1iX*I3_G_n0w|>h|1;w41Sy8jdGdpG$vxapAFeFCPrsTbjvn-O0
zFSFV-PITXsHDX@KEKD7sn*moB(wS)7!e~Rrh-0}Z!e$ilK2g$nF+!8ReGExM??I-5
z3W*(`RdF}3Y*dB5(`buj$#3ahO{U|GpyZR<#5FSutJbMir);|XG8${{o(~=RicFse
z7aJAVM9U9{blXCv%5nqdjgsv~G0=lLl=)V%p09m+;MAKUpKx!E2&9wW6~%|S$k-&|
zR*Hm4x)!>{g=vYdOQc3Na~VCW7P+Mw?wchIC^+{WecoOk4$pHcn|u`;9cnXOPH;Xl
zYuV1P-V#jNlQjvUPfM{=oJ2iL6^;<9N~hqn*1M>^Qau*L4SOIen;&WoW$IPWvrrLO
z#xM*qQ#j2h9rg)Y80@{b&3r4hQOSL!P~1h6cbgb;goQ3UF#KTXxwDGc=>j~=eO%5Y
z)fz{q^|E@W5l23<|8~6}TvsDEv^AKLeAJeTCfAHPH*}LEE@!(OX1Bgke|_~kRTds*
za?l#QOqh9|pxatI_6au8O;cKM$zj?RJx~Pgh~dc`jFgwpuhKQh!%4(#kowG0^t`Ah
z*1?nqZn==>q%jr!0TE?ni&qju_9_;_
z(402X2|RUIgE!{C!xu{~U!+J!uw;-1g`-F4@K*+XCyF$*9{o&ktiCpAGrJI}IqWdV
zV2Li~w(|pXUZW)=!AYmcpdz^H)%UmVL#fq`YjWFtL)ozA#}7|hy=LGP_=mA
z2I9}C)ZypZUv+f&dFBNRLTe&7IJh{`S5%_f`%bzF!Yna^KUarj;%MhyA7IAwnCoGB
z>7~7D@;70P>?-~}{oF{V0`AjV`jf2b@oj$d2}~hzy)ej79Eevs%9swc;fAixuD@mT
zCrUQU#_3(lawFx4`(^v7nB|Dpp{g!-!+D7Pl9XCuS@a#pAc_{x6nDuRybrlb-9^?H
zNFII^BHVW^=t>ot2Es0}%T*=#!G`|GbNw=AMTP_im7*G}Omg#y3>Y+(<&9HAJ06?g
z>7be8Q|COgb;fn+@cKmSs>dG}he!n-zF#|DBzmi2VR0eCfFcwnu}cR#$YAB+aQ&6z
zsLB3GqbN0FsYry)V7lSunr5bBBl!-Le`dP5P(+D|-dy(?-RfwhI$b9(L31WC3_5hP
zevQ5|HAVm!#^&y(TCz?Nm2L(hf@|NqZl4fY;9}=lsmF0Af3M&4#S^VCjsQdQ<7c*_
zXM?P3JGOBpH}^_>5@u;)7We3ub^G3@=4zjgNkKASS=7p`-h#fvwgOn^`~0d~yZbvI
z#4aA{rGBj*qYL0b1(R~+wGR}TA;@f2jOE$#NzMmd5C&^BthSQdC?pK?V7w}oWzFJ_
zOk&34PE_S5Vx38??q1Z{sj3;b-fzFJ0c}_BOsyX8dFou)1Y-TiH=Z-O##@J^(mu<;
zYPetzXL+alaM+NFwXm7MHam^fEWU8AGntP@(1~!HAU|eK#^k6d
zlFIMC!(SP=(&}DmL02C5c97$d=YzHos_nW@hK^Q?Vyo(l#qX4Z{_4M;!Cu`ROWJ%k
z_8JXh>KV1sj4hicxuRH-wfCyMVj@=5@q}o5O8DCItnb$=dao*ooV;!Mgj^3%AyxZ&
zoeP-pSv;hrzO`w4o=2l*niI{}m($m2k-cks%1@BDLZh<
zT&NIjR=dlKp?w3^8izI=BDZ>rD$0TyT9D`bdr292S_vDNJO+U(#yU_z^o{-<9+#*8*^!~6b^qTf!=ni?fuRE
zmnq;khPo9}?l;P*g;C5wD_Uhog{G$=0kmr;84o2Vl2A<<*
zgnFw!KzO#&zPkO%YqVSZm%TJm&adbM^1b2GSI0{Dr4DcHg$S>Z{kj=0z2S*&nh2xl
z;hzuul>Ht#18T%JNCxYRCWfx^yln6e5877S5<$-R^dXS_E?Cw4(V)2ejJqI-VR78j
zKp#dVr+r}A$r}Kfga`D}ZuuO#PZYhI@eMuR0r|!H!AeSqG+FbY&2L?+>qF3xj-U1&
zU{61Ze>nzF4H!C4Iu?_3x#m^9Sl8+DqH$(j_F#n*!BmbM`f1!_%{5|+dju^?0E`jk
z@lwVGS4V!h9t^*$AtrCwa6Fz#8@)^e
zpcb1^TYn^c>D|BbJLR%FqQ*wLK~`x-*DS$N<$Q5FWh%ScJMm?PhEjgbp4`GRNQ>KF
zy+(vqzl?m`KpH+W^TStldAA8qOt?ovE7Bi1qgV8tr8Ke1H@j%^XFULCL`tWF(BdyX
zxmJ?%Y3e(wGxf4nM2=NlCi`e!?kOy4vci*WygZIQg9Vm8a;K*RQn@aKzL{z8X?MEC
zKSgDQs?S3|tT!TCa
z=2B;yS=h_jJ{~nodalHQ*MB6oo;f#rnAZ1(_M`p9ZX3h6O7>z-=1qLV!)(*V49Wm%
z(7qIbKSr?CaOO3lt#rs3wae8j%vA~!k2BS3^mxMGci2_bLWhjLI=+q^1o*8(ns-}F>R-dawul5
z%Nl>joRT5kunJ-n`LcZX?=|DFCfrBr6Nd+N0rwap7pC#T?!uU6|HQH7-mL<5CO!s4
z&2Jp~@E>z^bE}3;f#f${ZVk-G&uY@Aj}_WM
z7QyOSH*s_bOE38BcE35(Bs#q5ju6XeMvk{?aUN<@%}^g%=kctED}eJBt;o*kb7+@|
zV0}~t=e|SPXWc`Bln%e1wpWq$KUd<~$#BBq_fslVl`;udtRPNkx4YN?-!v!$eIUOQ?OwM@OPSQlYS%y73s$3
zN1Jgu{cGO+2()39t*o614uiXRgF5CMba49I*Hda?x>046Zh
z?tEBR3F1vvb3diiqx|iX+}fit=04wtOp0Vf%@IUygA%l4F>0dUHw>IcO;lGaH9FY3
z$E~Yb4=*k9YnSSn&a=E@I*l|MGPQ?&(BeBDggx*AFi6|`RkT>pd2tvS;ov1Q)0ysi
z$ohC`}XxA@gn7jAMrwHX<)vln*Og91la=iBW1-#aKAD>XjTI|mOP_H?q>$Ln-n
z8~7yY(BpE=^$ld}2%o~s05I7rJ#6sSiqMJgILdx|umcKwno{3{WpVd}=B~wvL`G!B
z#OZLFHh}l^F$rLDlvR3Sh-wfQ(<;UnO&kW3{%sOr0DqV`k>fZsPlkg4|5#G_HMz*`qr)uU^i;=o2r;kZsD(F+w`F2Xjna;N}B<={%Mp$b^?QvYs
zN_np#&q_8h63%iVk~)3yrxe$Wqg5KN*O$lH`75l20Ch?4S)WxzKAhOmE!!%e_M949
zoc5oe&Z^mE2s&KoU@Ya$Gub2OeLq<|C^eOqp*eV$Ns+1kV$1DcUC(kbb~~a(&PY6s
z$eGL`hK&8Hu$@<7C;*{Kl;w2NSJQ|qsoEg|BzpAh2%fZhm&U2ee
ztTk|+pg1?CoMD@WKH6y~-*F|HLjw?UI!1J67<8h?H~!Em*3o3#bwhKKjc>>pp0jU?)p4ZKqXX3-MrBFk98i
zH)B^#Q@`BkM)F5h0x!%}1isoj=)1j&$;!w&S5njmNOY&udB6CKMP8+8SY#jYr9A6`
zUqF=jXtH?w7XM*azVW6hMtn)3;niMLrdTt`c+-r<`B^h|*)eY4|DxkG?QuM)NrzZ4
z2jn^vMh*m_1K-0u?6@4h4YYR{8f+JDq2a^qpfxlAZ4AOXpq)u&wJsghpj);`CP6JMsoJ*;t80+bcgnNfxQ^ZZQj%JA
z;W+$^hF3*0l#XgDyGQ+bd^3b(Z-nXfONNS}y5|2$htWil?29`BkdIW4)#elCop#?J;H+Au5=~RjjVI!^KefyM
zmz8x0cAR!Snh6gv3X>~Fg$Vj|0~eDi_FN?N<*>eUP-`IRy;aCE035+v{<+cMx*T&Z
zA){S9PpNK$ERkt_eZi5EB0mBtlmTdo;lJ@`kE^SP$zdw;`5Yfp
zi50T$J-(kt&R$iV>(2OdX)l)={x)Awf**qznc%i7$AcMPyw=HKwJX-r0TtN?#5!-j4)BDxI$$$I
z1bIe@FPil$@&yG05dK8R0wAlueJ~$HS3OBF0Yxh^dLpknP#O!{toBe{X9=48z8j4I
zLI;lgLF~wqM1)8jsgX0fnxZ-tK(UH0iZjMt9!*~+(L^FNhiWD0?G^&Z!x$t}fO{1NAV98`!IuSlJPWac=Z7a4|8
zd#86b0tEu4bZ8|tOVwfbTR%@CTBw|Phr?tlF)zp{KA#_TXh4F6y|m*0;k-_-L6%(Y
zShzg?S`gI2XvF}?Uh+)`dOAsVQPOm*199#eoSeAc0>HlPUNRqAyb6Uo0&!R)j^;L3
znXu!#J#(@=m2>Q-<5U@`=t)0d^vL2e#}(T;^K;xZlli3M@F84&Dhbwzl}W9v;dWKC
zSw3C2z_=p&`Y0&zPF@_>m7w-E5r?XHyGIlVEUUUJ?$FLGP!+mQgXuC{oayWTL0g?p
zQz@YnyXMVQgAeK>k=pdJfna2YO?a$TUj5ZsyKH+x{6Q8xmS)MQEm*ONr3S?1nI`O&
z3t@z~$Qgu~R0#K7g}!%--#o=Fyu=HVPYAP%aR-3loShP?&-r@QF*bLmP!ot2H#IWP
zvNp4b3gw$>*XEx3hOA?Kj|CxhCQ;}+NXKUcBJ^Y~9XMJYO}?6g1yQe>+vT{6&cCHd
zf(F9mNGPoPCauf6wyL+cOxyDRJyvAIzZ8*6v9p|v#3y%pK$`IBM;ymJCg)2Hg{}BJ
z&B>R;rC~bNRkD0~6P!%s+_&Y2Qpu&UAtw4}P>*iS^13*iIsuErFxNGWIuO*DM!o=x
zs=~#ARxY>gTr;f~NUU|(w%5f`ASzZp+(BWbVr1#O#0C0`ft2!%!uwrZt%>}BxfJBO
zt~{XdVMxBMzNzg6;JHANP;zo*&N2cU5HtuFDe1LNx#o%7jg&-0Q7iY6b$xh`e)qI$
z=ykutVS8gqCwj#P8sjSoIl_`Ky*Sxj0tf-$ey>=4VMt1F=a@f1F|#75E7yR4rM0Yt
zr_91{wLc@IaPlFUB3o&qM^<8CNN;ebq)@AWp%NKq*?D~7yj^PKJStcby~QoiH?$O&
zKoNlFsP%&@sE7n^I*}OWj}j}kVgv05|5-
zTg#uMi1Pvv?{6=^B0=?UY_A~H{HB!ff4n4DfZzT(4$LKB9e;cIXI%cTw-aDC60F=A8AIa2~sIKuPqUl5qfe;5Qce#OOJr>{WE
z<;Wm%#uKAf!sDM`xc=JjaePDF`4;)|YIa=;P81&}C|aN5baA|LiGMtddpaHls^jhMsYRxuQW4@ER8p4vn`s99@s{y|*g-
z>)Tji5JO`ZiT>GtlJRE$s{NDV;YkL-dpHjkcpE7G;?M3cLVkt2gCzF^nda@ERe(^f
zLH+0!KhXhFC@Y#BXg{3mar;AW@g|hKI{;&P)i{*%ydjgP#}fT!4){Rs!6HOZAPG*!
zqf}@`fMsV=%|U{Uro(>I105T~VPY))!IqZBzZMw|shjq9;o`|c0Qzxkvo&SE`vwzP
z6Z7GW+D?j8L*@+T$BjRHKxJiQ%~6og{6dv1!~dxb2yZ>fw4msKi&G(Z3pv9dOShN?
zIb(>wnCQ>Y3M$^T?Kl={;sx*YQ3|4@nO(f4}D!wB_tuiK}2WZdKw6C
z+HY1u@!0~5z5&X%m|DqXO0=7i{1HNoobir|x(HF_0ITy;bUl+0Z`G%G_@mFL%|N0q
z;2TDPa*LbgrlVx^mffGw;&tY`H2zq_3inOh1LiW3mrtp6!L^s+*aJ$+;h%9lJaV)G
zIGDa3OWw6xi=d`}OtAl^ZPg4)?ITPdOK|O@Y+X`F
zK0|-TacF$FR0;*+Xj{nfr}Iipv7Og1NNS@jUSaq8++O?_!L;i#hZT&<{yLk
z$6)?hVg6ZR{&7kFxTJq#nE$`TFeI=n3p!%y{|Lsx*Yt0o`kMLCurpmINU%pCddHph
zbJ6X;f}Ou5zZ`?;e+Bu?YP~YKq|x+6s<}ADAk6#QPX9`n2SNC%es2y@8~D#N`c#46
z{ucE9>yVpf{yFa7$-qD3^2c)iKeQKU-?5?BWoeA(*=k(4U^@cy{|{qURRUfNXCn!4
z?(6}o8zZz;(R8Cr0EH1QZ2oT1^Nn=p?WuIbdQa2&AU4UEGCFO$miPMJG
z{z1P|8x|YjqMNS#`g%$Sk-IsA6`+
zL>3#+wg4)2+?Wqsk}Cm+&tj~@pTW<7c8l|59V*Huv2kR0d-WztaIgKFV^PGeEswpLzzw0bQtg!Y_&S9e!60TODG9
zJd(BN2rMf;bJ*{Z85Y%YUqA3Xd6g2!R0?^OR{J;AL-$=7idXcCvBqj*00~%Uf46vZ
z6yn@Ub_xxd3~o8Pv>=01Q1oK9`u<`RM?tsRW3u8h;{**O!I(f4>e)QX_@u+d}xr*7GA7b4r|_HLR{>=kt<%?odRFk4MV~JBpj#dT%m}j7jkl
zFzF6@Mg)#fd@w))&2vlBng46z4H)dQqMC2H+z#FpUtgUweAWl-o=jvdIJ?WuH1HPx
zfz}8#A0O%u`s8KV5ZVWq+bPDuJ3!&N@cpHF(zSYYm~>&=AVfi4yY~xlHSK^
zwuANI{5IdPtUjP9a*hSEiH@9tMr_l}v`D$V;gvYRFX^fQh5sc$PUeHQr(JbJNqM`u
z`?+I{x7N+;4c~6^>;q;*G@?kh>v_C6UcNIAUA*)39b){0P+m2x+IXGEjoP+Rb|WYU
z865u-IGEqn7+c5X=SgA72~FO3EwZTsY;rmVL3*>TEZHdPY-Mdlh)E(Q6YG?yvEA47)RpfR55oUX2cJA!iI5dQA$0T9LGproM5g)SO*LhKP-W
zNajQBfnu4(F@(xWEnN{9R$6k`>TP5pWgeha02G-B=_|<9D6yPlh9@W&OGfECX*-;6
zmdhOB)vlc#;qi_^vva?>F2yj6=5_k!DogV|Cmj9kowYhLqhZ`O`tkbmsJuQXN(>O#
zADwG0s8y}!*L#MsTMg$LwdG}1;f|xQ6g@5Yi4mz{&QxFA#VKDh<+d)RB)ls*=r9Bd
zp2pSSnw16@OTGJ?T|uqHzBA8gyHy6rRy2W*hbv;?#p%XmwQ~tz>q+AQQO_v%2?|)z
zR-}=IJYTKVoQ8N^JgNegth#Tx$XP_x^GUeOE>5QnBc6#ZpM9SRM<(!oXgCp5J~W1R
z%4Ob|lKiE7?(1rT*6GoVgR~>r#bRc7kKlTaG37X?V2n+hRN!)_x=9H0_#u?)8Nq1W
z({{Hl1k>vtAQzhceul#ut~~_Rk60JlD3CC=Ijb0yGq?s5IK9mIbTKN5r3pbsK=Qf9
zdT$bi%YV7u`Jk>E@LfE3DLO%8Aiem-14$$6
zHf*uC5r>^(lp)VFebH1DFv(T6a=szYt3S+B39hz3`wSn*f5jJ
z*(&(E>ncEGkWTVEGat>N@HqJ0jwR0U9+XFUfG{CNOly3O0V2b|c$_d56=%u(b!A!X
z+O;T0mtkE!V#g?0fc^{!|2pYNa?8e`vN{qU?yy$JU;FKCmT7LyNj*)q^Pw-#yJq5|
z|1%!!UjWO6&ldw%uBTq`gNBf^f5eg9vgLB3nf7;bwk=_sYP2dvHTT0#J|PYlsJ4)@
zTUeqzpSuVsK*1dmx;A6iaRSDo+*q23&$EJO?!eVCtTTShc&RyLx46W(;{Ym1^yViv
zxA;%VYGgp5k%e#ziO3A&ulXH4%UNBsO;_IEgFGKXI6AJVVcdI~(%)G`R#V|L<8Hh$
z%XK)0o2r^AN}{K70Ug1;+;zthyM=T)~dOyRIqQ1|JhoPX>KgYW1&
zPcHJiNP)4a(n$tYUm~OHrH>uips}JHbuDvH6z!;H=@Oc806ty@`g7?=A?tH&zRS(3imCGCYQf~<@iw_`Uf3Ic8+>>dVyv6T+)UQktr05{_fuhk|qw1v=
z5qo2VOhfwBx}m<;sP##vv7&s>U>2=5N_IvmtYd8k6k
zjf6y!gZM81gIYH_G1xI?x+V|v09ABVg~!S42V9#=pmPbZG#oZ2XU;8AF>bSFlHCTS
z)c{YR3#9F2#7mJ5V$z0iU3kMgi(?J5iq0nNd!^RyWDH4q-n#v>c>P*?$kD`6!QxRfDwX}%|eP=u)A8f3brj+arU3R#ccPbbHSC$t^HO6gMrmLS^TS=NRANn!LIT2)_|F(~7K7dX<@liAC0HC!N_XG1DHx*%pGx42FR>x&lWq
zG_gRi^KDSmur|*NPzAatl$omrGAVv59^3IrhCeAKv|9`^P~ZBX3aIo5HDHC-o;Kg<
zC9zu7Lm~)NYu2V*#Z5<3qP=3#YY(3EzJ0gS4>83*in#7AxWKr1ES$woEws
z5JNPVJ99cKsRzir)XaBJgwTsGO#RLt-Od1fTyd?^_Ij6J=de9?i~$n}!yFW@qkMXv
zv2|;908HcQgstX#O1Jr9&T=llgjBI*F~1Myxd(EBUz;d^@t&oYm1Do`GCA_oO<7XQ
zycdw9vRPPk8f54BO&neKy)4$=ZB?;ksoS%{b@Zy|za0L;LxGe&zDfFb#K1V%EswYv
z3|R7>5ugA
zq-M1z#cfb^tx;BS@6v?ut%7|bB!c|Z_(nUi-`I)yZ93|9=BPiDyX
zzlWTm{Js|vZ<&C;?sZn_Oe=MJ!&^0T7OVPf6he7;Rqn$Cfj4Dt8nx*K%<5F2p{mG{
z)!&Oxar+f+kvi-AYS_^+ck%TQZ_KbgSYt%^a+uMjoChZ%z9tqhTPfHi733s#utzgs@~Vl^HP5hE1hHw8AH+2>IRvVqd}mA
zjMj%ziVzM<=4Fc@y|r
z`}&(5GBHkeKGp%8#IW@=ka35z5MabR%-4+(ifW}!1bK=)nTXKWHWFFAe_}ETVmVc-
ze)nl(gfGF!V{nzSLU6fhy(G_!RQ$$l#=eJM4o>{O{Cc>c9`V9!4@{AlgPiJs&+c_~
zn(1zed!=tp{)*5rxA7vA6qz9{U&F9!M7be1EEi&&l|0;s-POytjo{`(h`;m9(E8qR
z^Ak6x>%IC)*>Xxg0Pbs~ACMx5Twm<-TpO#kPn*VBsVEiZszp`;#^azu*G=l6{byzG
z*U+_6cbdLnM^L>3iU!jG-JZ;-BSPN|w_g;b67X#j5Y~k~5E4rtleZ2GCWc)-fN0JIA>3
zExnKqnqXZq>p$S>Kkv;=0NX=#oNbYhW)~4ueefy%d}{Ws$ga}m`ytK!U>L%=s&uia$HD_YWDr
z%J2kE1sgL85xL0coX&o|y-Zi*(ynLTpINQ%>Pf!Gs8eK7v{LD!gIIU
zyNYjZs~E%m_*l^wg%go~PO>T6G{_og>e))IxsT-=)>lLncm;P0n(<|`3Z{9HP
zCB}ec-Z()6Gae|hQ=TiW+qw?<@&cr1HtW>DaZnxZShPlPo6I2M3pyf!3Ks{GB>bUX>0T$Xf}mHvx1Gp3^Uj%;3o5Y?5d&2-WNdiFH($A<&N$J&)!i0!Z}Y$Gpc`
z*Ymw(KXW3x6Mz%Tbl3tK&;ckSqulezH>g!H5>6w&Eh-EaX4_--%NJ|!??YTM;|Z;X
zl9zfUUmWRVfb$7yE6r>9!67tk`nU`FR@l{#-;=Oo)2=q>7N$U5!`=beCR!9G?&BT=
zI^<9-{s@^NW>t8rC&O(L{1JspQj>kzkhzAo%R;CO{kTT?Ar$_A{|U%v>DEgC?S5(_
zD=n_PgJUy}tJiIg73h3q5^olb5=6gW^@i%Sh7MBCYza?;&SsvoexBq>_j*KUSr96!
z;tov%0DpYxrTE9IhWyH<*sAiGBnrZU-;?rQg4;FwVek)Sq3U;!qnx)dtAAjBao=la
z*vdZP+4hDL;QDfs-T!~u`|^0G*Z1!dA&DZAwK|3D*(SS6l925C(uqc4Ci~vBQ1(-{
z7*v+AOZI)rR>TNnUxo=GG#LBx+@DeBe7~LNkLUIL@w{HY=hZ*wrQ>#g?&Z3#`?}uO
z`?~JxepkT$O(XP+YDBp&Ii>C##r}N%k49ItoiO!>v
zGtu*WnA(3#+rNiuyfo&XOcmmz_qoG+F*zx93Xttu1x>K5PjbV+&~&iJCn>9YmO)CAkc#o!=s64Ac;7x$u`;+L
zo&{ZZGsVI?QZ+J@q_&Gk!NQoYsgN8sAs`Rs1K9W147T-O=&9I#ij(-OQF;LbaOb8i
z?Iw^8Ek-ml^;wzYj^<>ZgLv+aHvus}1mx}SRi64%{lMD4M~3Fz+qpQIQ-suOw?j_{
z)B;dC_KME21N@48INk(}nQxWzHKVqqN#He}i%!q61cd#rx8A|1{hH*I4N+bbb}`Po
zZ&aV9Q|TWUP{_tVn@IGY&iwfHs@_Ai8MNH5|8I@tk{g
zuEEiYNOzX*XbkOi`keCdei17GX`bsBNikAXY*KvOq*FP3U+?zIgcE0X-lhXo`_%g9
z2>+<&poNawfSqRze`jrG2(*8?|6HbOZ6X2FHZpycO^Kv05?Bfd{ayFua2~))<^hcb{qjPxL(nB5+^<+0;|v@^e?(2Ie*u0pYm5N3ml2v-DG^XJzw{ZCEv5e_s!F
zFl5=RCvIB{-5<`SDXj+q{I1eZzDhK4J@2b%Or&nE&I5RmZt)pXbIEobl*Xt(lXeg8
zP;<6~-5jCXr|1MyQ#ke8;q5O~KWgOPP$DOu?503aRnsA{mfnI&1%{fMI^Vp;p7M|F
zi8U)3YzR3!;eSWG)VJJ-Cb`IY7Xa7o>b(E_AYM&QVKPSE{>~b-Hkk#ytS{*o5BnSL
zQGds!c=x@Z5s)ZXydq9yvi1;O;*
zhu|#LMz9)a0V&G393|h_VS-_1lekti_U2-B^O(>g
zsWMp9eu3fiS}zEa41HUTzONVjkO?x)3{ZyD=qP%(&)oB
zqPzql)lYxL)u?+)n#)$LMO@1Q1uydQLByHzS*zn@mm{#fnEl5%sU=Eqxdj26jU`x#
zlC;nQ)#p5u@53MdndG-@a#Kg#4iwjr0`
zX!tcO7m)yteg0@`FCnR5h&hb=Qd{rUqJoDnkNfbKjxI&1pKsRR`S$n%T6r9*2jT>?
zFr<*(Z|A8D-+I;jjYMop0I<2DXrYm%*Lc~WgR9uL)v(LAVjMr-xof1@iP7Pe1V*-O
zyt#wohJJNf9tnh4j>}uVp6ba@E*P2&oo!1t4Tsib57n&5OP8u@(qXHOsraU0W?6Sw
z0cGdbmuK&QYD{Y|
zt%3gD-eHmQbRAno$SrfZc;nyEcQ$$e8@1&CKakW7>IAvpY{E;s3lFn7Cbo8gnvR)<
zf-(Q9>4?fa`|_2J3@A)=v#Bt65sBSPdrZD&PQR6f6Zbch^p{V?HB&ipsfGDukb-9)
zW_$v^CD-KDn|uy~7s5tc^c8?N)gXW73*9f%*-M>+1+mM!kOqMxfiV;hLC1^ocG`a6
zFZ6bfMeh6W`Gddzz+48d(pK-8T%(27%bbpXI)Mo7VA7K5+r4&6#z5sn&};m=!zOYd$bV<`kE|o&VRb_}W<^uhQnU?!UgF^3n%f*lzO$
z_Bh}i{<2D_bWi});egQ7|4qbtNC=F?CqmID{NF>7QUj}@XRN{cOMl>>UoBC22Vq0t
z=uV_WC`}Kiv?ZNtzmEkKiJg}s=z%Gx`Oq5(j;Gs$CQ`M9w=M-4FL
z+YZMqZjk~^>}a!3OxQb
zcG0BUqz6R^mx^~N8ihZQ%z
z$aRgmFaPc^VmgP|Jj{1p8?-;qG4X?py@x879no_WU~2!t8Ly|BqgKa0<)x+?Isx`v
zK3viV0+XQyn>|74{phCW4?6N=Rs=tcO8c>b!k-6FgFv#zwXZ(-DXD{+fAF+bgbCURP%BoI
zubmq}e-%VnA>@@q!)fQ)?fqQ@`~UI6^a~P}c0d{5ogHq)56Pfpa~g!(&koTKirliG
z{eI%l!;(hdFOE5#HtI4zvMLaxdE)Ae43S7%(c7;A*(Ru1Q7?|#es~=DUL^Am5kZNR
zKO~>tD5Mh=9lbDT_vq5e49r@x5)L+xb{Te=7%aynx=hF?GocsTHa;ofe3LiY77`p|
zbhG
zX_fn+SS)q7F&}pXg#QQ?Mpe?G4b$_bqOjUWuL!|Vo!Ybeqgg(j;X^cE&OJ#*4XO{T
z+{c=uToukB;x&t17|PzmC)cz6q-i=1XcLO!w=j6>{sVOA{$N2JO5b$My-2Dl&ufGt
zVyOI!LTo0>Wl4@W71MY0=>6R!Hjg({RG4?})inIOL-7`f3~!>=R{Vzceon3J#yCPR
zd?wNmL4|3kiaPmb8Z2gEzkKKOhghePFYqCtdxK4;_G7*_MP3f0BZKQe8I_5qW9urF1o!%bQCS}A?BQ*wL
zR2W0^11!fFQjemsAC>8->X?~fj48--N3Z1JcA7UEab#S-oUMfw7RH6i`v*VH18CKXh(y+yw9-0}vdL7@v9Cw-z
z5r6t7xa=qk!B?vy$HM{}FLgFZ!Db$feNWv;ncM=?1FSe0ZQWOUO^w}6&IzP6C0Esg
zy_@H2ok^qYuy>#0akZB&dr^9msdiU>$b+#dW!GZPe3E>H6^tk}?bf8sYzChn6NnYw
zi|Q2SApRWh8chc&4l7vemwlW@JGYGWj5r%Kx#t1Q)PX1X5XUbon_b-oj88ixzGvMiI%bmbuRYREZ39XgPlAi$4XpV^<`lY?A0{w7t;yx0aNdndbW!OHtd=
z)1mD?9{VZ3AH*npn7eF{Pq=};nD3jZK$R~afj8=TT@5T{mBlc2dpV*b&c`=k8
zPX5ZGw;)BvEZrk6AO32tLg+f5$?>BpbqpJ2*V5=0uL&TUi8(RkBa{Q@P0mg`A+D)H
zkkV}Q{4rh?e~RQZJC9^tM(GKOKBf<)OzsOWHOhvL4juRz7XvDeLamJ%DNU!n0-%GT
z8sDQykumaHAE{uKNpODJG+HBfoASLWqU@T8R-F9>lpc?LaZW5{X5HCVB8(^#(AeZ$
zBg^j8s23=bqvyY2D188JiWIzNEeuVLe}|9m;6*UnQ2&ys-SdNWpo4@=54WL7=vq9~
zQDu1mlCjL#p%h(eId*24o3=yXZqq%eG|C3U;qMh#4xkrc*|(~xDVoG`%K=XJ=?F8d
z^_fJ{kMTxYQ6y(!pfpRD&=ss{Lv@ofxiwl<>tkTFHcN$RKhC@1#UHA{>bGhDEAU%2
z{8kPBlT|}Hc8U}cV4idUf5DoOdU&lZq*0U9TFqqkFs*=&n(h-zFS%v@ID0`Znty!d
zr)uHeRowE!-jxnlP@V3r_4Pk~_2YsAcV{S28=<`|`sAdQDohzj^^SefB}Kho=#Aq*
z$ve?X8h&wo6rkr+KG`|=_utA}S%Vm{&>@BI*u;@Y8nZVo8C-0_*~k9w_3s~0<)HiW
zO9v?T^xyv%`l0ABGpzXYjhG*r?T3*9+F9p;%U$%ZABz7!f9(jaT*soQA2u7s5ZnEA
zoDjISHBt_Y#B6vWrU3wQCZL>np_e@KjDaKFR=zS||p
z|4L;@lhSg5W~;Q}wICkv+eqMPh$=>;os~IE5%jMr1l;yFTrj^9=_wu!)v+17$h&?W
z!eaD^Y-4q+=BXd(sEuEm;$g
zbJC!*v!r9Bym0}N)g3WJvmk~Qs+rk9ir86=XaK#pPfxbiNMXX>BHxc6&G&4udu~u$
z35uBpt1C|H;&FfgYe_0p-YCT5YM6Wbz|jo%vG$?DcDSo>qc=gfS
z`?Wu}mwB(eZ4ni6LWYwccfpZuQfxnnwpHJ7@~9lRB!bLb-`T|Nup$Sr0K2d-2Z278TcCtLVJv@V
zJzo}WgBJLcdUwsAVvDeX@oe@89oXoj$7bc>s7^qvxV~Ahvw7(jA0kV@_XP0Xt}^%%
zIY$KM5JB>+P-)Pn79@BXfz{b(U|>R2k85WZC_FWE+^ZB-ZePOaCIm_s%ZjF+{
zHYq}Em=x|2YIK22s-YN^s2ciD2hd~P1x)_mA2w`(($kOQtH5y0M%KGeCaFd5N9jHL
z4x9@Vo_)1|ccWko2iBm8;YjJDfKdjkxXSBfmctSLODQ3qNqXk5SnEzUMFK=j@32Q*
zy-2$R^kPE86ed||doF-_{UmUK%J^gG(bHOGfJqx-Y%}CZ48wozsh)Fd00qjwK?@J5
zXcb->I~wiJ-DPTgNp}i9FKV~`#u=XrP?
z`fg|KU#bW6Id`G6Gl8|$tHo^i#^xv7<~97=%E56_wVWcT&Y}ZajH0q%I#ab`r+mPv
z2#N6fcGEyIV7ABKar0n`Lw%?i6^28cL!AMA&Ne%E4=S3yx5RNEP_{)4;kxu$-MPY?
zl#_<@n{y$a3)oo+u!2f4sVOwc29~Lbl{_9HagRuBd-d;Ft~DDOI=hAu>w!q^EC|HF
zuQ$%>L!!88L9P8cwTyAT)!E+#Uoo;ZG$N9;h@R9}#%&xC$|y6Pb}y~8AVmf#r1sh;
z`%P$#?cTrEmDKU5PBnH5eJ-~yUA)TyqGJy7&d?SpaIQ7eH;ff@C+v({ZKth58%uKZ
zC3#OJZe1>$txlT*GGItz+WF4Z04Wb!K-K59k|^mzUD-1Naz2P=Qe!ego2E6u%Us0AN%wA-HW!B%=|%s
zRE-NawRG#mMjtM`6kpIZGV-Q2b^%J__g`gnF$_FGV+az4Xc@LHn1%b#9u2GSOv
zg!=7vJvA+q@>ZvEZi!;S?0QeYR?p{z;iYs&V$IG*ZNS{}B&5{?;cb9xU}wOh9E+$z)Ic1ak2Sj*4j*_vho}(xZ#=5m{rM(K4ju12vR&?g3r8~LXlAKAR2l;Nwt-@u?RZlvgyuP#2L
zs^7u&!-=5K=Ir#W1-MV7QcF;5gyq7s*wALeo&LLx#Af#U`U4pD+SLXkQY>JtMZG{v
zWAQ2O+~#pVz=h=6*)9#(D9wg9%dUhqMH}40P1$WUmJD@OkXoqh4UC^$;*iBzf9
zxDZ&V;i^RJ_%BXr>+HZ(24QQPoH<=`Td||@)B=M`1mRGljVF4pC;ETF{YJ9q{
z_-f!tG}G05|JaFv&CSG-wM2*b+O2`w+~!#43hrnl>9Bo;6H=r_tIY;0{murBRJzLa
z=mcreLr0qJ{q+|!0uICQ(!St6#QLJj+WB&wPkkQ|uJZbFiq|As5tMApdeNi-9spgK
zPIvHKY=OkiVEpwasO~&!_m{30&F9rWHRDH4Ca;t=DPB%q@4}p!IC{!&9iG@^@5gmW%VblXdfw
z*F>yv3KF#wPv~N88=gG
zTaX*<1P@T7Uw=-dF=-1&B$
zUeZDoX?4{?aVe8l`>-K50=t(pU9&~Eh6Y~uG{de}fB1}qcXwfu^g7vUhpg*mwk^;W
z)nuSma5HJ*a5C~D1*AhY^Hqu&vW*3Np#{hczWm54F3@VeKi&J-SUhJ!ycUCLcWmU9~SsSKa%
zBpp1dBpsx*Uz?1`>>FM^pJ#qG4{5lX4a~$MTYOnBGJ;u1i-nf1Rh7`iN|FS2);b2+LigOKqez`Mnq4hrgT%b{>
zO}|v*I0PWx9lk|iW!kGFl&~5qloWpvbn>UyFth#rPG6$xox;GfA%aY4xt4(p56pg7
zk_xHg<#R~w-`BqbP2sO!^EACbuRa`@wu{O=A)&QmM_>)P2jFIG$t12iuZw8a+>tXp
z{08wCN2oBK;hi~!9htMpgbQ-3PlU?ZIGSZ?4E@!)koEO{P+{ngK$n%c5uc^@UnN?g
z-gnbikU@ivORwRMFPROtmrL`yR%wyvzgKk-b!4D>of&5x{PN6WS@Pr-z6D>~M4zB<
z@0$byvt+A?TG@S=GDYWMVE>PC7$h(%uRc^Rd&P}ZsOn>8H%oPI$|VMF19)0)?z!kb
zOznDhZPxbvF($!n>jba{SD9|#iOJsK5{g_3;#k?QBVWfkJ`=kWFzMkxDKIB1LxCXx
zuDeKuiJN2ECNO0=UcVc1a`pDGWyuu+t9%8RKh8aly*X8;$5|x8{txM(8X9eqLX%n$
z%-Y!1jN6&+s(Q
z8KZBP&C=JpFi&OQrOW74nwDC2|0DUCJgfD*9S~dmbH6u%)jo`!W9(jo@w+tTwvqMR
zk$5>1KYOXUOzGXJwoKAT%#MHoisxo_JP?WGlmd%f)}=`d|2bJN#Jqg-!_PhEe4i3N|@A#oIAM10y)?G7W=g)(JtC#TGoIoz^M&7
zV`|2P9Ed`rT{$H{V27472c8&agQDJQ8;yKSerdRFFdHFF=2grfLydm5=1x%
z1$vbPw`4flP_jU!**>-G-f%Mw-d^`ULdDF4(
z3aA`AD=sp)DXV^8EitA_Dt~>l3LNK3!1%T6j`i1NLZ57pm+b=5?F}DB0Mkr=mL1mG
z*?+#49p?58oM!#nZ_0*yI(Y(3!CdjpA%|KgFE%9jPhZRl?YKG#{KJiU4uZGI2xY1&
zbi&7BYJH_u<05$XGbOULTnH7nJ44`$PD~K8A#*Lc#KciKfk|xEjNpnlFrw+Xa8aR(
zEU4qv99Y;D;z@^Q8#8zUE`J94t`RQpCi&rl_%lfn2}#+kGZS!U1Fgq1&Tm5o8ao}4
zWZGLzRkle$r{EQwe6p>O#UEr&G=E}1k5S`JUQ|R>%sM*Ddpz?dECCVVgj6mDB1nXD7iZc`#|T{QjF
z+7d%7$*c7a@~i_XvEZR9VqYuxP>w^te}nzt4W4{g%ZXaB6hmaSV)hf1)%ofn4N?;3?NRwr7U~JPFYJuJa*C6>pn>nBi%P$ETL35AA8~s6Q+H91qL1rGW0WWSj
z8-M&%Vd2z=6+C|Qgr4bWJc;+M&&$OX0Vno+`e=HVi
zODp9VG8U81;)T-7=uTE$dKO!iD*4qL;WFR?l}PZ!gu~>$-Rj)kz(37|gv_6lF|{aWqqq7Y{6JI3H&AWvz@X
zTaso!*XRo80k6~acgZwHYqhe-Av;d+eBcH`E#yOdQPcX02SJaHm-DwYR3Q}Q42Dis
z96&=4ML66#A{2ck2*Wr4Hssbi{PEFb!Sne&+#kzO6ys9(WV;L^*lQc|>jE8htD4uq
zGiH6_a{&HJ%Gd_l@=pW1!on&RmNt&VqXzvl5JHfsx4sil4PX|B_(4=BMAr_MZA+JF
zGFgPk!%me%!^cvsQp!w>$(k9^N9+zk;FN46C}pty3En9-mZ}=xq^r&?
z&BM)qp`&c#lx~MBl;me{rnyn$FW9@nK4#~Knu}pLqnd?imWCN7MvuqPI!OX(Lee^h
zdq|DID)b1#zt>YDBx^|b@$kB3Af&bHCVjCrOKHTj)AFwXtTtTa5O#_JCbLkrfZsnq
z6%KpdKhY3ACz(VFWmMK-KvOV-Teb-t_O9$4c~uL|x`V@P{3c^pvnCLb-?M1(Wi}u1
zV2QUuaf6)nkK8b6CSlvY2}YZvEis2g)2qjI2vRzq=fU|GHzU;XZX!Paxms{~qQY58)8J
z>U9{zZcknnX}${(82LPMVF`(L=K*__wH-r=EW&$e#?mM^a(N_R=d-=?M&Gm}4LBRQ
zmytVfes1fVyM(T)Vo{nCQ!b_i{Skk)a`>(E;_{lXFxmo{QWtVzhr~$PgWH9#){cam
zpgNN`KPKxB48%E8%XJ2p;1F3OJiLpE?g^I)lgbiLHmC2{TD?9`hmJq#e+KwlV^pM!
zXP(xcIrhZVOIu&CCz-_R~>gAhH}i9;tfF&y+BaH2}2MDWDyddae{0wCR=w`p&Lfxylk2Rg5L)
zrCRD|QtTN?k$6|}$bJbSgm+KnutBkOvvy_0*=aZ@4A1-F_~OvFTy=>Zx@Xf)5?bc7
zgIv_wT8EVZ68JJv0M{zA3GxORWXbFM%RDRF0i2@OD(j^F
zggL9cj;C}2h|fw^bDBEm(&zxnLGp@3;~NCUs5YE
zd$0_fnK@|>OsXOl7)ad6Ci~yj?2xhUc6aC>B+`JY{!$UEn;o$=Qn{<1=2c-*S}e)n
z;mGMvZ;_$i82KUi#kIHz$aby=3j+*NHo#I5x!;w3MG}#c-I$dHFm5l`IJKEzCiM+*8yWY@*xut#8NJR}Io
z8>a^7pN{@aUr|kUtD}=-1>nN6C)oh-QY%4;cj+aqqnsbw{E7FCwbjtlzb<={hgWJm
zSd9h&f%ZiTc<>u@jT97Jz{pu9RRyDUXOb1~39@Jh2NI|%g+Gp061!|nxU=1?DmWzW`+%L~Z
zEV(>Vs0FxMEnKX@C2_j+LMl8V`7q&9oSyPNMIl7+0pfDigu>XQr=Q#Lejs-igZ=FJ
zRY@}Q6J-J(fB_sj#umIjFA7R~cReCuu<(6Byug)s6Q#0<6eN?kUQ1Siav8NYeu}g1
zr4v=d>)oYJo)6)Eej}Sa{DP1<`Psxi(E!haTL_cw!2?UxqHaYEkd8vGiWob6#tOFG
zYdpOHU7qSey#A{K!zGIovbA2UOpMNwu0Rm{knjM%@kJ0>tNb>Us-C>|$-d(c7v+@U3HldtR(I=&qePNn@-a3>
z^w`P34_;4}z&fpCoooZei=DNcbMq(54(6dg;sHrE5tqKP(!>uMiAMXZSY&s6P31
z)m0BZDmE8;px)fm{UfG_-`>(h0y8$uOg|}8Bx$(_L(XuErv$%e{`NaNm{h~;7=?p8VtkUOc
zLR>pc`V_Qq;`N>KZ*0Mo>*Sx$eEYFY_>#2DU>MId1u11NMgac7T1x^WS}gxIP}(RN37(`!#=E&94ws5#sIr
z*Tz7q#{l?)xuy|tv0poT2@$y<#^d2%r*EhQtWyWY^y+_gmINqp5Ft$c*YE#7o6NC4
z39i$b7}kLji(&`Av|opaRiP=l+gA%Bmn=qhQ?$T$0@b60I#rKf{dL52C{Qjc;1=J0
zZWuR+^a*w9{?n#C7kdYI=cI$R$WnG!`I|1MR9?nXm98#v5Z%uo`UZHJU0kT5)+4Z1
zRDWNswh_z`ux0IK)wcd#FnJ9Eh`n+5_;$wh%%!qr#Oy(#sVbd)w#($2Q0MV@e6&ix
z9X-0@$dKydVc0C6ap6x&Moy$kzZW|!_c{iC7Bvg5U`N^{4UY;+b9Zl}yTf}>ofAs_
zKPBMU14?toSEVASP_LO`YesLHso)6^eNpVdf9=%=zDW0B8f}g@2C6S&8q_Hb=LqmQz3>T^Fxo|iRteRHjv4RUf76P-&
zV*DwzzZc@iS@^vWzZc^7(b!d%zjefKW%>Ko_EEu<&mRWF_z?a6
zb=-16pq61;Z^>*Hw`tIepII6|TTxdW>3w@^XABet{N~^;@2gZ9+H4cl^P1|v-9O07
zcn2_%{hfHWs9&5MzDRWyN~YA`mhq1te*eYqwfe{J{4FKF&&N-t@>?_f&(REoojqGQ
XT2tO^t}j65@*WK}?MrzVtRMU@x`j7-

literal 0
HcmV?d00001

diff --git a/meta/reference/good-docs-project-template-1.5.0/index.json b/meta/reference/good-docs-project-template-1.5.0/index.json
new file mode 100644
index 00000000..e98a256e
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/index.json
@@ -0,0 +1,663 @@
+[
+  {
+    "name": "API getting started",
+    "summary": "API getting started describes the easiest way for readers to achieve a result that shows off the capabilities of your service.",
+    "last_updated": "2025-05-11",
+    "contributors": [
+      {
+        "name": "Elliot Spencer",
+        "id": "elliot_spencer",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Michael Hungbo",
+        "id": "michael_hungbo",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Sakura Ticer",
+        "id": "sakura_ticer",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_api-getting-started.md",
+      "guide": "guide_api-getting-started.md",
+      "resources": "resources_api-getting-started.md",
+      "process": "process_api-getting-started.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "API reference",
+    "summary": "API references are technical manuals that provide API specifications and integration instructions to help your audience understand the service.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Chris Ganta",
+        "id": "chris_ganta",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Mengmeng Tang",
+        "id": "mengmeng_tang",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_api-reference.md",
+      "guide": "guide_api-reference.md",
+      "example": "example_api-reference.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "Bug report",
+    "summary": "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.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Michael Park",
+        "id": "michael_park",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_bug-report.md",
+      "guide": "guide_bug-report.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Changelog",
+    "summary": "Changelogs document significant product changes in reverse-chronological order. This template offers a more technical, comprehensive alternative to standard release notes.",
+    "last_updated": "2024-12-12",
+    "contributors": [
+      {
+        "name": "Cat Keller",
+        "id": "cat_keller",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Deanna Thompson",
+        "id": "deanna_thompson",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Rob Beg",
+        "id": "rob_beg",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_changelog.md",
+      "guide": "guide_changelog.md",
+      "resources": "resources_changelog.md",
+      "process": "process_changelog.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Code of Conduct",
+    "summary": "A Code of Conduct helps you govern your open source or developer community to ensure it remains healthy and open.",
+    "last_updated": "2022-12-15",
+    "contributors": [
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_code-of-conduct.md",
+      "guide": "guide_code-of-conduct.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Code of Conduct incident record",
+    "summary": "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.",
+    "last_updated": "2022-12-15",
+    "contributors": [
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_code-of-conduct-incident-record.md",
+      "guide": "guide_code-of-conduct-incident-record.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Code of Conduct remediation record",
+    "summary": "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.",
+    "last_updated": "2022-12-15",
+    "contributors": [
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_code-of-conduct-remediation-record.md",
+      "guide": "guide_code-of-conduct-remediation-record.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Code of Conduct response plan",
+    "summary": "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.",
+    "last_updated": "2022-12-15",
+    "contributors": [
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_code-of-conduct-response-plan.md",
+      "guide": "guide_code-of-conduct-response-plan.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Concept",
+    "summary": "An explanation of a concept, context, or background information about a product or its features.",
+    "last_updated": "2023-12-14",
+    "contributors": [
+      {
+        "name": "Svetlana Novikova",
+        "id": "svetlana_novikova",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Ayomide Yissa",
+        "id": "ayomide_yissa",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Ophy Boamah Ampoh",
+        "id": "ophy_boamah_ampoh",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_concept.md",
+      "guide": "guide_concept.md",
+      "resources": "resources_concept.md",
+      "process": "process_concept.md"
+    },
+    "packs": [
+      "core"
+    ]
+  },
+  {
+    "name": "Contact support",
+    "summary": "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.",
+    "last_updated": "2024-06-13",
+    "contributors": [
+      {
+        "name": "Christine Belzie",
+        "id": "christine_belzie",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Njong Emy",
+        "id": "njong_emy",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_contact-support.md",
+      "guide": "guide_contact-support.md",
+      "resources": "resources_contact-support.md",
+      "process": "process_contact-support.md",
+      "example": "example_contact-support.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "Contributing guide",
+    "summary": "A CONTRIBUTING document tells users how they can contribute to your open source project and join the community.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Kayla Morales",
+        "id": "kayla_morales",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_contributing-guide.md",
+      "guide": "guide_contributing-guide.md",
+      "example": "example_contributing-guide.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Glossary",
+    "summary": "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.",
+    "last_updated": "2024-06-13",
+    "contributors": [
+      {
+        "name": "Rachel Stainer",
+        "id": "rachel_stainer",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_glossary.md",
+      "guide": "guide_glossary.md",
+      "resources": "resources_glossary.md",
+      "process": "process_glossary.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "How-to",
+    "summary": "A how-to is a concise set of numbered steps to do one task with the product.",
+    "last_updated": "2022-12-15",
+    "contributors": [
+      {
+        "name": "Gayathri Krishnaswamy",
+        "id": "gayathri_krishnaswamy",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Ophy Boamah Ampoh",
+        "id": "ophy_boamah_ampoh",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_how-to.md",
+      "guide": "guide_how-to.md"
+    },
+    "packs": [
+      "core"
+    ]
+  },
+  {
+    "name": "Installation guide",
+    "summary": "An installation guide explains all the necessary steps to install the product and set it up for further use.",
+    "last_updated": "2023-12-14",
+    "contributors": [
+      {
+        "name": "Bolaji Ayodeji",
+        "id": "bolaji_ayodeji",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Michael Vallance",
+        "id": "michael_vallance",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_installation-guide.md",
+      "guide": "guide_installation-guide.md",
+      "resources": "resources_installation-guide.md",
+      "process": "process_installation-guide.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "Our team",
+    "summary": "Our team documents help you clearly communicate who belongs to your open source project or organization and how contributors can contact or work with them.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_our-team.md",
+      "guide": "guide_our-team.md"
+    },
+    "packs": [
+      "community"
+    ]
+  },
+  {
+    "name": "Quickstart",
+    "summary": "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.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Gayathri Krishnaswamy",
+        "id": "gayathri_krishnaswamy",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Chris Ganta",
+        "id": "chris_ganta",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Nelson Guya",
+        "id": "nelson_guya",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_quickstart.md",
+      "guide": "guide_quickstart.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "README",
+    "summary": "README files include information users need to know about your project, including how users can engage with the project and get started with the tool.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Joanne Fung",
+        "id": "joanne_fung",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Sachin Karol",
+        "id": "sachin_karol",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Christine Belzie",
+        "id": "christine_belzie",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_readme.md",
+      "guide": "guide_readme.md",
+      "resources": "resources_readme.md",
+      "process": "process_readme.md",
+      "example": "example_readme.md"
+    },
+    "packs": [
+      "core",
+      "community"
+    ]
+  },
+  {
+    "name": "Reference",
+    "summary": "A reference article provides users with descriptions of specific components or characteristics of an application.",
+    "last_updated": "2025-08-21",
+    "contributors": [
+      {
+        "name": "Michael Addison",
+        "id": "michael_addison",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_reference.md",
+      "guide": "guide_reference.md",
+      "resources": "resources_reference.md",
+      "process": "process_reference.md"
+    },
+    "packs": [
+      "core"
+    ]
+  },
+  {
+    "name": "Release notes",
+    "summary": "Release notes communicate new features, improvements, bug fixes, and known issues about a product to users and stakeholders.",
+    "last_updated": "2024-12-12",
+    "contributors": [
+      {
+        "name": "Tara Sweeney",
+        "id": "tara_sweeney",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Rachel Stainer",
+        "id": "rachel_stainer",
+        "roles": [
+          "author"
+        ]
+      },
+      {
+        "name": "Leigh Hutchens",
+        "id": "leigh_hutchens",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_release-notes.md",
+      "guide": "guide_release-notes.md",
+      "example": "example_release-notes.md",
+      "resources": "resources_release-notes.md",
+      "process": "process_release-notes.md"
+    },
+    "packs": [
+      "core"
+    ]
+  },
+  {
+    "name": "Style guide",
+    "summary": "A style guide provides project contributors with general guidelines for writing project documentation.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Alyssa Rock",
+        "id": "alyssa_rock",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_style-guide.md",
+      "guide": "guide_style-guide.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "Terminology system",
+    "summary": "Using this template, writing teams can ensure they consistently use and translate the same terms across all the documentation in their system.",
+    "last_updated": "2023-12-14",
+    "contributors": [
+      {
+        "name": "Ane Troger",
+        "id": "ane_troger",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_terminology-system.csv",
+      "guide": "guide_terminology-system.md",
+      "resources": "resources_terminology-system.md",
+      "process": "process_terminology-system.md",
+      "example": "example_terminology-system.csv"
+    },
+    "packs": [
+      "misc"
+    ]
+  },
+  {
+    "name": "Troubleshooting",
+    "summary": "A list of common problems (referred to as symptoms) experienced by users, an explanation of the causes, and steps to resolve the issue.",
+    "last_updated": "2023-12-14",
+    "contributors": [
+      {
+        "name": "Christine Belzie",
+        "id": "christine_belzie",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_troubleshooting.md",
+      "guide": "guide_troubleshooting.md",
+      "resources": "resources_troubleshooting.md",
+      "process": "process_troubleshooting.md"
+    },
+    "packs": [
+      "core"
+    ]
+  },
+  {
+    "name": "Tutorial",
+    "summary": "Instructions for setting up an example project using the product, intended for the purpose of hands-on learning.",
+    "last_updated": "2023-06-15",
+    "contributors": [
+      {
+        "name": "Deanna Thompson",
+        "id": "deanna_thompson",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_tutorial.md",
+      "guide": "guide_tutorial.md"
+    },
+    "packs": [
+      "core"
+    ]
+  },
+  {
+    "name": "User personas",
+    "summary": "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.",
+    "last_updated": "2024-06-13",
+    "contributors": [
+      {
+        "name": "Ailine Dominey",
+        "id": "ailine_dominey",
+        "roles": [
+          "author"
+        ]
+      }
+    ],
+    "files": {
+      "template": "template_user-personas.md",
+      "guide": "guide_user-personas.md",
+      "resources": "resources_user-personas.md",
+      "process": "process_user-personas.md"
+    },
+    "packs": [
+      "misc"
+    ]
+  }
+]
\ No newline at end of file
diff --git a/meta/reference/good-docs-project-template-1.5.0/installation-guide/guide_installation-guide.md b/meta/reference/good-docs-project-template-1.5.0/installation-guide/guide_installation-guide.md
new file mode 100644
index 00000000..853f386e
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/installation-guide/guide_installation-guide.md
@@ -0,0 +1,158 @@
+# Installation 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).
+
+## Introduction
+
+An installation guide covers all the steps necessary to install the product and set it up for further use. You need an installation guide to install:
+
+* Operating systems, applications, plugins, and extensions.
+* SaaS (Software as a Service) applications.
+* Open source software (OSS) product documentation.
+* Hardware device product documentation.
+
+There are two categories of an installation guide:
+
+* **Standalone**: An independent installation guide document or page that includes all the necessary information required to install the software or application, including system requirements and step-by-step instructions.
+* **Integrated**: An installation guide document or page integrated inside an existing README document.
+
+## Identify your audience
+
+An installation guide is for users who have the sufficient technical expertise required to understand the installation instructions provided. If your proposed audience requires some technical expertise to install the product, you should highlight and list these requirements in the prerequisites section of the document.
+
+## Why do you need an installation guide?
+
+An installation guide can:
+
+* Help a user get started using your product.
+* Reduce the number of support requests related to installation issues.
+* Establish consistency in the existing developer experience.
+* Ensure increased retention of a user who explores your product.
+* Confirm a user has everything they need to configure, customize, and/or upgrade your product.
+
+Installation guides are often confused with how-to guides. It is essential to distinguish between an installation guide and a how-to guide document.
+​
+An installation guide shows how to install the product (as a procedure), while a "how-to" topic shows how to do something with the product after it's been installed. The difference lies in the purpose of the instructions. An installation guide describes the process of setting up and configuring a specific software, application, or service. A how-to guide describes how to accomplish a particular task using a specific product or technology (which would already be installed).
+​
+The key differences are listed in the following table:
+
+|          | **installation guide** | **how-to guide** |
+| -------  | --------------         | -------------------- |
+| Audience |Systems administrators and users who require detailed instructions and technical details when setting-up and installing a software product.| Users with a less technical background who want to set-up and install a software product.   |
+|  Scope   |  An installation guide provides specific instructions on how to install and set up a particular software product.   |  A how-to guide takes the user through a series of steps required to perform a specific task to solve a particular problem.  |
+|   Format | An installation guide is a prerequisite document a user reads before considering How-to Guides; because you need the product itself installed before you solve any problem related to that product. Due to the broad scope and availability of different variables and conditions in which an installation guide would function, an installation guide should be independent of a how-to guide.    |  how-to guide (or even a Tutorial) may include installation steps of the software or an application that needs to be installed as part of the How-to solution process. A hyperlink within the how-to guide would link back to the dedicated installation guide.  |
+
+## Before writing an installation guide
+
+Before you start working on your installation guide, identify the following:
+
+* The target user who needs to follow your installation guide. This helps determine the appropriate level of information.
+* The specific version of the software or application to be installed and the system requirements for installation.
+* Software prerequisites or libraries dependencies.
+* Installation options such as following an installation wizard or customized installation.
+* Identify common issues that may arise during the installation process, and provide troubleshooting tips to help users overcome these issues.
+
+## Writing the installation guide
+
+This section provides details about writing the installation guide.
+
+### About the "Introduction" section
+
+In this section, state the purpose of the installation guide. Optionally, you can specify the benefits of this installation such as increased performance, better system stability, and enhanced security.
+​
+Optional: add a link to a demo of the installed product or a sandbox to try out the product.
+
+### About the "Installation types" section
+
+In this section, explain what is included within the installation guide. This can include a list of different versions to be installed as an option. Make sure you highlight the differences between the installation scenarios. These can be outlined in a table with columns indicating the name of the installation type, a description of the installation type, and a link to the relevant installation steps within the guide.
+
+If your product can be used in different environments, include a table specifying the different installation types. This table can help users choose the relevant installation type based on their needs. For example, you can classify the installation type based on:
+
+* Main or lite version when a product has installable options with different functionalities.
+* Operating system types such as installation for Windows, Linux, and MacOS.
+* Cloud providers for products that require self-hosting to work such as CodeSpaces, CodeSandBox, and GitPod.
+
+Add an introductory sentence to the table. Also, include links for all the available options.               |
+
+### About the "Overview" section
+
+In this section, explain the intended result of the installation, such as the commands, command aliases, major flags, available plugins, files downloaded, or application programs.
+
+Also, include a sequential end-to-end summary of the installation process that can serve as a quick link or reference section for users. Consider displaying this information in a table with one column summarizing the specific process and a second column linking to a relevant document.
+​
+Optionally, you can include links to previous versions, if applicable. Consider formatting this list of versions in a table.
+
+### About the "System requirements" section
+
+In this section, explain the different installation types and subsequent requirements for each type. This section leads into the next section on specific prerequisites.
+
+Based on your use case, you can adjust the structure of this section by using it in reverse order. For example, you could list the installation type as the heading and system requirements for that type as a sub-section. For example, "Install on Linux > System Requirements" and "Install on Windows > System Requirements", instead of "System Requirements > Install on Linux > Install on Windows."
+
+### About the "Before you begin" section
+
+In this section, explain the prerequisites. Prerequisites tell the user what they require to accomplish a goal, such as:
+
+* Necessary dependencies or packages.
+* Required version for your system or other system requirements.
+* Specialist knowledge or skills.
+
+### About the "Installation steps" section
+
+​In this section, describe what the user needs to do to install the software. When writing this section:
+
+* Use numeric steps.
+* Categorize the steps into subheadings,  as required.
+* Create subheadings based on the complexity of the installation.
+* Add a one-sentence description of the step.
+* Start each step with an active verb such as "open" and "download".
+* Explain the expected result after completing each step.
+* Include checks for success if each step is done correctly and/or tips if the installation didn't work at each step.
+* Mention installation options where required, but mention which path is recommended.
+* Add visuals (GIFs, images, or videos) where required.
+* Add code block examples and snippets where required.
+
+### About the "Verify installation" section
+
+In this section, include test commands, intended outputs, or other steps to confirm the installation was successful.
+
+### About the "Post installation" section
+
+In this section, provide an overview of options once the installation is completed. Include links to other relevant resources if available.
+
+### About the "Configuration options" section
+
+In this section, provide information regarding post-installation configuration options. Describe the requirements for configuring the installed product. Provide links to other resources if available.
+
+### About the "Upgrade options" section
+
+In this section, provide information about upgrade options (also known as an update options), if relevant. Describe how to install updates from a range of possible options. Provide a link to available updates with specific version numbers, release dates, and key features.
+
+### About the "Downgrade options" section
+
+In this section, provide downgrade options, if supported.
+
+### About the "Uninstallation options" section
+
+In this section, clearly describe the procedure to uninstall the product.
+
+### About the "Troubleshooting" section
+
+In this section, list a number of anticipated problems and associated solutions. This section helps solve problems encountered during installation. Start with a problem statement, then indicate the cause and provide a solution. Include any important additional information, such as restarting the computer.
+
+You can also include steps or contact information for additional support.
+
+### About the "Next steps" section
+
+In this section, include essential or recommended steps to take after installing the product. Provide links to further resources, if available. Also, include support/contact information for issue reports and feedback.
+
+### About the "Product version history" section
+
+​In this section, you can list previous versions in a table, providing the version number and whether the version was major, minor, or a patch release. Always ensure the change history is consistent across the documentation. Refer to [semver.org](https://semver.org) to learn about the semantic versioning specification.
+
+### About the "Definition of terms" section
+
+This section is optional. Provide a glossary table describing the terms, acronyms, and abbreviations used in the installation guide.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Installation%20guide%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/installation-guide/process_installation-guide.md b/meta/reference/good-docs-project-template-1.5.0/installation-guide/process_installation-guide.md
new file mode 100644
index 00000000..42b4914c
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/installation-guide/process_installation-guide.md
@@ -0,0 +1,36 @@
+# Installation guide 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+This document describes the step-by-step process for researching, preparing and writing an installation guide. It is designed to be used by novice and experienced professionals to write a successful installation guide.
+
+## Before writing an Installation guide
+
+Before you begin a first draft of an installation guide, it is recommended to:
+
+* Define the purpose of the installation guide.
+* Identify the intended audience of the installation guide.
+* Source knowledgeable individuals.
+* Consider utilizing AI tools to search for existing installation guides and as a writing aid. Consult your company's guidelines before using AI tools.
+
+## How to write an installation guide
+
+The details of how to write an installation guide are contained in the [Installation Template Guide](https://gitlab.com/tgdp/templates/-/blob/main/installation-guide/guide_installation-guide.md).
+
+## How to maintain an Installation guide
+
+To maintain helpful, up-to-date and accurate information within an installation guide, the following is recommended:
+
+* Establish version control of the installation guide.
+* Use JIRA (or a similar tool) to implement and track changes. This helps reference back to previous versions.
+* Schedule reviews of the installation guide shortly before every release. If that's not possible, set a schedule to review the installation guide.
+* Maintain communication with the development team in order to ensure accurate information.
+* Consider conducting user tests on the installation guide to discover documentation usability pain points. Adopt any user feedback you receive from these tests or from other sources.
+* Test any new installation update.
+* Ensure visual components are also updated, where necessary.
+* Document the changes made.
+* Review and finalize the updated installation guide.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Installation%20guide%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/installation-guide/resources_installation-guide.md b/meta/reference/good-docs-project-template-1.5.0/installation-guide/resources_installation-guide.md
new file mode 100644
index 00000000..cfc63c3f
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/installation-guide/resources_installation-guide.md
@@ -0,0 +1,30 @@
+# Installation guide 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+## Examples of Installation guide
+
+The following list contains high quality examples that may provide significant value to readers:
+
+* [Docker Desktop](https://docs.docker.com/desktop/install/mac-install/?utm_source=https://thegooddocsproject.dev) - Docker's one-click-install application lets developers build, share, and run containerized applications and microservices. Their installation guide makes "System Requirements" a subsection of the operating system types (installation types), which is helpful for users in cases where all the installation requirements and steps are different for each supported operating system type.
+* [Nvidia Cuda Toolkit](https://docs.nvidia.com/cuda/?utm_source=https://thegooddocsproject.dev) - Nvidia's parallel computing platform and programming model that enables dramatic increases in computing performance. Their installation guide includes a list of separate installation guides that discuss how to install the product for each installation type. In each installation guide, the required system requirements and how to verify the installation are clearly outlined.
+* [Reactjs](https://react.dev/learn/installation/?utm_source=https://thegooddocsproject.dev) - React.js's JavaScript library for building web and native user interfaces. The installation guide is separated into sub-chapters to make navigation easy. It includes different ways of installing the library and interactive code sandboxes, allowing users to test what they want to install before installing it.
+* [Apple Beta Software](https://developer.apple.com/support/install-beta/?utm_source=https://thegooddocsproject.dev) - Apple's beta versions of iOS, iPadOS, macOS, tvOS, and watchOS for developers to explore and experiment with. Their installation guide includes a clear categorization of all sub-products and different instructions based on the version of existing requirements (operating system).
+* [Nextjs](https://nextjs.org/docs/getting-started/installation/?utm_source=https://thegooddocsproject.dev) - Next.js's web framework used by developers to create full-stack web applications. Their installation guide includes an automatic command-line wizard that takes the user through the installation guide and configuration process altogether, making the developer experience more streamlined and faster.
+* [Google Cloud Text-to-Speech Client Libraries](https://cloud.google.com/text-to-speech/docs/libraries/?utm_source=https://thegooddocsproject.dev) - Google's text-to-speech libraries for converting text into natural-sounding speech using AI technologies. Their installation guide shows how to install the library quickly for all supported programming languages on one page and includes external links to further explain the installation requirements. This makes the guide concise for users who already meet the requirements and want to install quickly while providing detailed information for others.
+* [Adobe Creative Cloud Apps](https://helpx.adobe.com/download-install/using/download-creative-cloud-apps.html/?utm_source=https://thegooddocsproject.dev) - Adobe's collection of software used for graphic design, video editing, web development, and photography. Their installation guide includes an additional video guide and a section on commonly encountered installation problems.
+
+## References
+
+The authors of this template want to acknowledge the resources that were consulted in the making of this template and how they informed certain elements of the template:
+
+| Source material | Best practice or section |
+| --------------- | ---------------          |
+| [Survey Question Thread on X](https://twitter.com/iambolajiayo/status/1539627304015601664)| This public thread details best practices and common issues relating to installation guides written by industry experts with experience writing and leading documentation efforts in both corporate and open source environments. The suggestions were used as the foundation for the template research, which greatly influenced the "installation steps" of the template, the recommended best practices, and the structure of the guide. |
+| [Docs for Developers: An Engineer's Field Guide to Technical Writing](https://docsfordevelopers.com/) | The "planning your documentation" chapter and writing how-to guides" section of the book helped define the flow of the template following the best practices recommended and the differences between system requirements and prerequisites. |
+| [Diataxis Documentation System](https://diataxis.fr/?utm_source=https://thegooddocsproject.dev) | This documentation system explains the implications of tutorials, how-to guides, technical references, and explanations in a documentation. It helped us better understand the differentiation between a tutorial, how-to, and reference document, as described in the installation template guide. |
+| [Semantic Versioning 2.0.0](https://semver.org/?utm_source=https://thegooddocsproject.dev) | This specification standard informed the "product version history" section of the template and the structure of the installation guide semantic versioning. |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Installation%20guide%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/installation-guide/template_installation-guide.md b/meta/reference/good-docs-project-template-1.5.0/installation-guide/template_installation-guide.md
new file mode 100644
index 00000000..5e0a9bc1
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/installation-guide/template_installation-guide.md
@@ -0,0 +1,192 @@
+# Title
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_installation-guide.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.
+
+## Introduction
+
+{The installation guide template includes information on writing procedures for successfully installing {product name}. {Insert your preferred description of the installation process.}
+
+{Optional: Add a demo GIF that shows what the installed project would look like or link to a sandbox or playground to test out the product and explore its features.}
+
+## Installation types
+
+This guide explains the steps and instructions required to install {product name} on supported operating systems. It also explains how to configure, start, and uninstall {product name}}.
+
+{Include a table to capture the different installation types, such as:
+
+* Supported operating systems
+* The type of product installed (if provided in different versions, such as Main and Lite version)
+* Cloud providers, such as CodeSpaces, CodeSandBox, GitPod, etc.,) including a link to the right heading for all options.}
+
+| **Type** | **Description** | **More information** |
+| --------- | ----------------- | -------------------  |
+| {Name of installation type}   | {Description of installation type} | {Link to the relevant installation steps section}                   |
+| {Name of installation type}   | {Description of installation type} | {Link to the relevant installation steps section}                                       |
+
+## Overview
+
+{This section is optional.}
+
+{Add a list of the available project versions, link to the installation guide for that version, and highlight the latest, beta, or stable version as listed in the following table:}
+
+| **Version** | **Build** | **Release Date** | **Status**                               |
+| --------    | --------- | -------- | ------- |
+| [V {versionNumber}](#link) | {versionNumber release} | {dd/mm/yyyy}      | {Latest}        |
+| [V {versionNumber}](#link) | {versionNumber release} | {dd/mm/yyyy}      | {Beta}          |
+| [V {versionNumber}](#link) | {versionNumber release} | {dd/mm/yyyy}      | {Stable}        |
+
+{Explain the intended result of the installation, such as the commands, command aliases, major flags, available plugins, files downloaded, or application programs.}
+
+{Add a sequential end-to-end summary of the installation process that can serve as a quick link or reference section for users as listed in the following table:}
+
+|      | **Process** | **More information** |
+| ---- | ------------ | -------------------- |
+| 1. | Before installing, check the system requirements to ensure your computer is supported in the latest version of {product name}. | {Link to relevant documents}        |
+| 2. | Check the system prerequisites to install all the required {software,  dependencies, tools.}.   | {Link to relevant documents}                          |
+| 3. | {List additional steps.}          | {Link to relevant documents}                                    |
+| 4. | Verify that the installation was successful. | {Link to relevant documents} |
+
+## System requirements
+
+{Start by breaking this into sub-sections based on the number of installation types (product type, operating system, or cloud-especially for projects that require self-hosting to work). Based on your use case, you can use this section reversely by having the installation type as the heading and system requirements for that type as a sub-section.}
+
+{Mention for all installation types.}
+
+## Before you begin
+
+{List and highlight all the required prerequisites here. Consider making this a table.}
+
+Before installing {version number}, ensure you have:
+
+* {Prerequisite one}
+* {Prerequisite two}
+* {Prerequisite three}
+
+{Include prerequisites for all installation types.}
+
+| **Type** | **Prerequisites** | **Note(s)** |
+| --------- | ----------------- | ------------ |
+| {Installation type name} | {Installation type prerequisites} | {Important considerations}          |
+| {Installation type name} | {Installation type prerequisites} | {Important considerations}          |
+
+## Installation steps
+
+The following procedure explains how to install {installation type name} and {optional version number}.
+
+{Provide a short introduction to the step-by-step procedure based on the installation type.}
+
+Get started with {version number} by {write the first step a user needs to start the installation. Use a verb to start.}
+
+### Step 1 - One-sentence description of the step
+
+{Optionally, introduce this section with brief explanatory text.}
+
+{Continue with a list section if these steps include a sequence of instructions}
+
+{Optional: include a code snippet or relevant screenshot that helps your users complete the steps.}
+
+{Optional: show the result of completing this step, such as a text output or an image).}
+
+#### 1.1. Substep 1 - One-sentence description of the step
+
+{Optionally, introduce this section with brief explanatory text.}
+
+{Continue with a list section if these steps include a sequence of instructions}
+
+#### 1.2. Substep 2 - One-sentence description of the step
+
+{Optionally, introduce this section with brief explanatory text.}
+
+{Continue with a list section if these steps include a sequence of instructions.}
+
+### Step 2 - One-sentence description of the step
+
+{Optionally, introduce this section with brief explanatory text.}
+
+{Continue with a list section if these steps include a sequence of instructions.}
+
+## Verify installation
+
+{Include test commands, intended outputs, or other steps to confirm the installation was successful.}
+
+## Post installation
+
+{Provide an overview of options or link to other relevant documentation once installation has been completed. Also, account for anticipated problems during or after installation.}
+
+{Optinal: include short introduction text.}
+
+### Configuration options
+
+{Provide information regarding post-installation configuration options.}
+
+{Describe the requirements for configuring the installed product.}
+
+{Link to relevant documentation if needed.}
+
+### Upgrade options
+
+{Provide information regarding upgrade options, also known as an update options.}
+
+{Describe how to install updates from a range of possible options.}
+
+{Provide a link to available updates with specific version numbers, release dates, and key features.}
+
+Example: To begin the system updates:
+
+1. Choose the version number.
+2. Download the update at [link](http://example.com).
+3. Double-click the update file.
+4. Additional steps as needed.
+
+### Downgrade options
+
+{Provide information regarding downgrading the version installed.}
+
+### Uninstallation options
+
+{Provide information regarding uninstalling the product, software, SDK, package, library, framework installed.}
+
+## Troubleshooting
+
+{This section helps solve problems encountered during installation. Start with a problem statement, then indicate the cause(s) and provide a solution. Additional information can be added (e.g., restart the computer)}.
+
+{Add a warning note and highlight in color if the action has the potential to affect security.
+
+Communicating with the product engineers and programmers is essential to keep this section up-to-date.}
+
+### {Problem title: ...}
+
+{Optional: More details about the **problem**.}
+
+{Optional: More details about the **cause(s)** of the problem.}
+
+**Solution**: {Solution to the problem...}
+
+**Contact**: {Support/contact information for issue reports and feedback...}
+
+### {Problem title: ...}
+
+...
+
+## Next steps
+
+{Include what to do after a successful installation, such as a recommended next step or links to further recommended documentation.}
+
+## Product version history
+
+{History section with major changes to the installation guide tabulated following the Major.Minor.Patch semantic versioning specification.}
+
+## Definition of terms
+
+{Optional: Provide a glossary table describing the terms, acronyms, and abbreviations used in the installation guide.}
+
+| **Term** | **Meaning** |
+| ------------------------------------- | ------------ |
+| {Term, acronym, or abbreviation}  | {Provide a definition of the term or acronym or abbreviation used in this guide.}     |
+| {Term, acronym, or abbreviation}  | {Provide a definition of the term or acronym or abbreviation used in this guide.}     |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Installation%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/our-team/guide_our-team.md b/meta/reference/good-docs-project-template-1.5.0/our-team/guide_our-team.md
new file mode 100644
index 00000000..3f8988e5
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/our-team/guide_our-team.md
@@ -0,0 +1,148 @@
+# Our Team 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).
+
+The `Our Team` template is for open source software projects.
+The template helps you clearly communicate who belongs to your open source project or organization.
+This template:
+
+* Lists the teams or roles for your organization or project.
+* Explains the purpose of each team or role.
+* Provides the names of team members in these roles and, optionally, the contact information for each person.
+
+Think of this template as the start of your document.
+You can feel free to disregard some of the suggestions made in this template and write sections with your own unique content if your document feels like it needs something different.
+
+## Why do I need the Our Team template?
+
+At the end of the day, open source communities are powered by people.
+The success of an open source project depends less on the cool tech or resources you're building and more about the health of the community of people who both contribute to the project and use the technologies you create.
+To help your project succeed, both your users and your contributors need to be able to communicate effectively with you to accomplish important tasks, including (but not limited to):
+
+* Joining your community and collaborating with you to exchange ideas and help your technology improve.
+* Making your technology better by letting you know about bugs or usability improvements that can help increase the chances your technology will be adopted.
+* Evangelizing your project by inviting you to speak at events or conferences or sponsoring meetups to learn more about your technology.
+* Supporting your project financially.
+
+To make it easier for people to accomplish these tasks, it helps tremendously to have a page in your repository or website that explains who are in key roles and teams in your project.
+
+Additionally, creating this content will help you and your project better identify and explain about what roles you have and what they are responsible for or should be responsible for.
+Sometimes the process of creating a document like this helps to get more clarity, buy-in, and alignment throughout the project.
+In that way, using the `Our Team` template will help you think through these roles and how they help meet your project's needs.
+
+## What kind of teams and roles should my project have?
+
+The teams and roles your project needs will depend on the type of organization you are, how mature your project is, what your community is like, and your community governance style.
+In other words, it depends on a lot of different factors.
+
+For now, just focus on describing your teams and roles the way they currently exist in your project.
+
+However, if you want to think more deeply about effective open source governance, consider checking out these resources:
+
+* [Leadership and governance](https://opensource.guide/leadership-and-governance/) (opensource.guide)
+* *Working in Public: The Making and Maintenance of Open Source Software* by Nadia Eghbal
+* *The Art of Community* by Jono Bacon
+
+## Content of the Our Team template
+
+The following sections provide guidance about how to fill out each section of the Our Team template.
+
+### About the "Table of contents" section
+
+A table of contents section is optional, but recommended.
+
+In this section, you'll list out the major headings of your document and provide a link to let users jump to a section of the document.
+
+Your content system might have the ability to auto-generate the table of contents.
+If so, definitely choose to auto-generate it.
+
+But if you must hard-code it, you can create GitHub markdown by creating a bulleted list with hard-coded relative links.
+
+In GitHub-flavored Markdown, you can link to specific sections of your guide using the format:
+
+```markdown
+* [Heading one](#heading-one)
+  * [Sub-heading two](#sub-heading-two)
+  * [Sub-heading three](#sub-heading-three)
+```
+
+Just make sure your document actually contains these headings or else the relative links will break.
+Test the table of content links if possible.
+
+### About the Introduction section
+
+The boilerplate introductory text at the beginning of the template explains the purpose of the Our Team page, which is to list the key project contributors and team members.
+If desired, you can explain how to volunteer for one of these roles or link to additional pages, such as your Contributing Guide or a page that indicates your policy for nominating individuals to project roles.
+
+You can modify this boilerplate text as needed for your purposes.
+
+### About the "Community moderators" section
+
+The Community moderators section is optional and you should only include it if your project actually has individuals serving in this role.
+
+If you don't already have this team, consider creating a team of community moderators to help ensure that your community is healthy, productive and welcoming to newcomers.
+This team should be comprised of individuals who occupy a position of trust in your community and who come from a diverse set of backgrounds if possible.
+
+Perhaps most importantly, community members need to know who they can contact for support if a potential Code of Conduct incident occurs in your community.
+Ideally, your community moderator team should be equipped with adequate training and authority to effectively respond to Code of Conduct incidents.
+See the [Code of Conduct template](/code-of-conduct/template_code-of-conduct.md) for more resources.
+
+In this section, you can describe what tasks your community moderators are responsible for, adapting the provided boilerplate text for your needs.
+
+Then, list the names of the individuals who are currently on this team.
+If possible, indicate the best way to contact these individuals.
+Remember to keep their personal contact information private and only provide project-level methods of communication if possible.
+
+At the end of this section, link to your Code of Conduct and your Code of Conduct response documents so that contributors can know how to work with this team.
+
+### About the "Name of first team or role" section
+
+This section provides some placeholder text for one of your teams.
+
+In this section:
+
+1. Change the heading to the name of the team you want to describe.
+2. Include a sentence or two that explains the purpose of this team.
+3. List the specific tasks this team works on.
+4. List the names of the individuals who are currently on this team. If possible, indicate the best way to contact these individuals. Remember to keep their personal contact information private and only provide project-level methods of communication if possible.
+
+Listing the name of the specific role these individuals have is optional.
+
+You could also include the role for some individuals and not others.
+
+For example:
+
+* Chair: Dorothy Gale, [Slack handle](https://example.slack.com/team/U0123)
+* Vice-chair: Frank Baum, [Slack handle](https://example.slack.com/team/U0456)
+* Zeb Hugson, [Slack handle](https://example.slack.com/team/U0789)
+
+At the end of this section, link to any documents that can help people know how to contact this team or how to join the team.
+You can include any other helpful documents as needed.
+
+### About the "Name of second team or role" section
+
+This section is a placeholder text for another team.
+Fill it out identically to how you filled out the previous team.
+
+You can add additional teams as needed.
+
+### About the "Thank you to past team members" section
+
+This section is optional.
+
+If you would like to list past members and thank them for their service, you can list those individuals here.
+
+## Implementation and maintenance strategy
+
+Even if you're just a team of one or two people, it can help to add this page to your repository or your project's website.
+
+After you add this document to your project, set a calendar appointment to review it on a regular schedule.
+Alternatively, you can simply make a mental note to update it any time a new individual is added or removed from a team.
+
+## Acknowledgements
+
+While creating this template, the authors were inspired by the [Write the Docs Team](https://www.writethedocs.org/team/) page.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Our%20team%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/our-team/template_our-team.md b/meta/reference/good-docs-project-template-1.5.0/our-team/template_our-team.md
new file mode 100644
index 00000000..9d85a3f5
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/our-team/template_our-team.md
@@ -0,0 +1,107 @@
+# The {Project name} team
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_our-team.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.
+
+This page lists the people who currently contribute in key roles in {Project name} and what their responsibilities are.
+
+{Project name} is powered by a great community and a team of dedicated folks who keep our project moving forward.
+We are always looking for more people to help with:
+
+* {Task}
+* {Task}
+* {Task}
+
+If you're interested in helping out, get in touch with someone from the team you're interested in.
+{Add a sentence or two about the best way people can contact the team and get involved.}
+
+## Table of contents
+
+* [Community moderators](#community-moderators)
+* [Name of first team or role](#name-of-first-team-or-role)
+* [Name of second team or role](#name-of-second-team-or-role)
+* [Thank you to past team members](#thank-you-to-past-team-members)
+
+## Community moderators
+
+{This section is optional, but recommended.
+Only include this section if your project actually has individuals in this role.}
+
+This team ensures our community is healthy, vibrant, and safe for all who want to participate.
+
+This team:
+
+* Moderates our community forums.
+* Ensures community discussions are on topic and friendly.
+* Serves as a point of contact for any issues or questions.
+* Handles {insert link to your [Code of Conduct](url)} incidents.
+
+The current community moderators are:
+
+* {Name}, {link to Slack handle or other contact info}
+* {Name}, {link to Slack handle or other contact info}
+* {Name}, {link to Slack handle or other contact info}
+
+{Writing tip: Consider listing people alphabetically by first name.}
+
+For more information:
+
+* {Link to your Code of Conduct}
+* {link to your Code of Conduct response guide}
+
+## {Name of first team or role}
+
+This team {write a sentence or two describing what the team is primarily responsible for}.
+
+This team:
+
+* {Does this task}.
+* {Does this task}.
+* {Does this task}.
+
+The current {name of team or role} members are:
+
+* {Role, optional}: {Name}, {link to Slack handle or other contact info}
+* {Role, optional}: {Name}, {link to Slack handle or other contact info}
+* {Role, optional}: {Name}, {link to Slack handle or other contact info}
+
+For more information:
+
+* {Link to document describing how to contact this team}
+* {link to document describing how to join this team}
+
+## {Name of second team or role}
+
+This team {write a sentence or two describing what the team is primarily responsible for}.
+
+This team:
+
+* {Does this task}.
+* {Does this task}.
+* {Does this task}.
+
+The current {name of team or role} members are:
+
+* {Role, optional}: {Name}, {link to Slack handle or other contact info}
+* {Role, optional}: {Name}, {link to Slack handle or other contact info}
+* {Role, optional}: {Name}, {link to Slack handle or other contact info}
+
+For more information:
+
+* {Link to document describing how to contact this team}
+* {link to document describing how to join this team}
+
+## Thank you to past team members
+
+{This section is optional.}
+
+We are thankful for the hard work and dedication of these past team members:
+
+* {Name}, {Role}
+* {Name}, {Role}
+* {Name}, {Role}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Our%20team) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/quickstart/guide_quickstart.md b/meta/reference/good-docs-project-template-1.5.0/quickstart/guide_quickstart.md
new file mode 100644
index 00000000..c526f8bb
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/quickstart/guide_quickstart.md
@@ -0,0 +1,160 @@
+# Quickstart 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
+
+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.
+
+A good quickstart answers the following questions:
+
+* Scope:
+  * What is the core purpose of this application?
+  * What is the minimal use case that is covered in this quickstart?
+* Install (if applicable):
+  * How do I download, install, and configure the application?
+  * How can I get any required access keys or authentication credentials?
+* Hello  World:
+:memo: A hello world approach is the simplest and easiest task through which your user can get an end-to-end sense of how an application works. It also serves as a sanity check.
+  * How can I run a simple workflow for a core feature or a common use case?
+* Next steps:
+  * What other features are available to explore in the application?
+
+Quickstart guides are often confused with getting started and marketing guides. Though these documents help the users get acquainted with the application, they widely differ in their target audience. The following table describes the differences:
+
+|        |Quickstart Guide|Getting Started Guide| Marketing Guide|
+|--------|----------------|----------------------|---------------|
+|Target Audience|Domain experts who know the problem space|Beginners who are new to the problem space and the product|Business decision-makers who need to make strategic decisions such as whether to buy the product|
+|Content|Minimal conceptual information|Detailed conceptual information on product/domain| No/less conceptual information; instead focuses on the benefits and the customers using the product|
+|Focus|How-to| How-to and why|  Sales|
+
+## Why do I need a quickstart?
+
+A quickstart is often the first opportunity for your users to form a positive impression on your product, and form an opinion on the technology it was built on. It can:
+
+* Make users comfortable using the application.
+* Motivate the users to take up more complex tasks.
+* Reduce users' onboarding time and give them the feeling that the application is easy to use.
+* Improve the user experience, and help reduce costs by lowering the number of support requests.
+
+## Before writing a quickstart
+
+Before you start working on your quickstart, identify:
+
+* The primary feature of your application.
+* The quickest and the easiest way to implement end-to-end the primary feature of your application.
+* A use case that your user can complete within 1 - 2 hours with a preference for a shorter time.
+* The audience, as it helps the users determine if the quickstart is relevant for their use.
+
+## Best practices for writing a quickstart
+
+* Lengthy quickstarts can overwhelm users. Consider condensing or removing steps or reevaluating the scope of the quickstart.
+* Avoid complicating the quickstart by including error scenarios or complex use cases.
+* Remove the burden of setup requirements as much as possible through sandbox accounts.
+* Ensure that the quickstart works and provides the advertised result.
+* For code samples, ensure that you include:
+  * Any required `import` or `using` statements.
+  * Code comments that explain what the code does.
+
+## About the "Overview" section
+
+Use this section to provide the following:
+
+* A short description of your application and its purpose.
+* A description of what the user can accomplish in this quickstart.
+* The intended audience for this document.
+* The basic knowledge that you expect the user to have before using this quickstart.
+
+## About the "Before you begin" section
+
+This section is optional.
+
+Use this section to mention any requirements/configuration prerequisites that the user must complete before they start the quickstart.
+For easy understanding, consider classifying the prerequisites into different categories such as software prerequisites, hardware prerequisites, and so on.
+
+## About the "Install" section
+
+This section is optional.
+
+:memo: Not all quickstart guides require an installation section. Include this section if:
+
+* Installation and/or configuration is done at the same time, and by the same person running the quickstart.
+* Installation of specific software(s) is a prerequisite to running the quickstart.
+
+The purpose of this section is to provide instructions to your users on how to install and configure a particular software/tool before running the quickstart.
+
+:memo: This section may not be relevant for Cloud/API-based applications where authorization and authentication information is more applicable.
+
+Use this section to provide:
+
+* Basic instructions and commands to install your application.
+  * Always validate the commands and check for technical accuracy with your engineering team.
+  * Provide instructions to verify that the installation is successful.
+* Link to the detailed installation guide if you do not provide installation instructions.
+* Links to the upstream docs for common software installation instructions.
+
+## About the "Steps" section
+
+The steps section is where you describe what the user needs to do. How you write your steps will vary depending on your organization's style guide.
+This template breaks down the quickstart into parts. One part of the quickstart may focus on completing several related steps. You're welcome to follow this structure or use the step headings on their own.
+
+If your quickstart involves many complex tasks, break it down into different logical parts with each part consisting of one or more related steps. For example, you can structure a quickstart guide to onboard an app as follows:
+
+Part 1 Configure your local dev environment
+
+Step 1.1
+
+Step 1.2
+
+Part 2 Build your app
+
+Step 2.1
+
+Step 2.2
+
+Part 3 Deploy your app
+
+Step 3.1
+
+Step 3.2
+
+Part 4 Test your app
+
+Step 4.1
+
+Step 4.2
+
+However, if your quickstart does not involve many independent tasks, only add the logical steps. For example, you can  structure  a quickstart guide to create a new project in Visual Studio as follows:
+
+Step 1 Create a new project
+
+Step 2 Select a template type
+
+Step 3 Configure your new project
+
+### Tips for writing steps in a quickstart
+
+* Number the steps in the format {part}.{step} as it helps your users to easily identify and locate procedures in the quickstart. Also, this helps in referencing a particular step in a lengthy quickstart.
+* Start the heading with a verb and express the step/part headings as a complete thought. Don't use the *-ing* form of the verb because it is harder to translate. For example, you could use the heading **Connect to the VM instance** instead of **Connect**.
+* For each step, provide some background information about the task so users know what they're about to do and why. For example, while selecting a template for your Visual Studio project, you can provide details on the purpose of choosing a template and the different types of templates available in Visual Studio.
+* Remember to orient your users when walking them through each step. If they need to open a particular file or dialog to complete the task, provide that information first.
+* Provide examples of sample output such as return data, a message so that the users can validate that they performed the step correctly or not.
+* Use plain language and define the terminology of any technical term next to it.
+* Include one action in a step.
+
+:information_source: For additional tips on writing steps, see [Writing Procedural Steps](../writing-tips.md#writing-procedural-steps) from The Good Docs Project.
+
+## About the "Next steps" section
+
+* Use this section to provide links to other tutorials/articles that the users can try on completing the quickstart.
+* Consider a logical connection from the current quickstart that can act as a basis for your users' next learning.
+* (Optional) Provide links to relevant resources, like blogs, reference docs, videos, how-tos, and so on under a new heading **See Also**.
+
+## References
+
+* [What is a quickstart to you?](https://ffeathers.wordpress.com/2018/10/08/what-is-a-quickstart-to-you/)
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Quickstart%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/quickstart/template_quickstart.md b/meta/reference/good-docs-project-template-1.5.0/quickstart/template_quickstart.md
new file mode 100644
index 00000000..4e809bba
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/quickstart/template_quickstart.md
@@ -0,0 +1,91 @@
+# Title
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_quickstart.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
+
+This quickstart guides you through:
+
+* [Part 1](#part-1-task-name)
+* [Part 2](#part-2-task-name)
+* [Part n](#part-n-task-name)
+
+:information_source: (Optional) Link each part to its corresponding section for easy access.
+
+It is intended for {audience}. It assumes that you have basic knowledge of:
+
+* Concept 1
+* Concept 2
+* Concept 3
+
+:information_source: Link each concept to its corresponding content that helps users understand the concepts and ideas behind your software.
+
+## Before you start
+
+:information_source: This section is optional.
+
+Before running this quickstart, complete the following prerequisites:
+
+* Prerequisite 1
+* Prerequisite 2
+* Prerequisite 3
+
+## Install
+
+:information_source: This section is optional. Use this section to provide installation instructions.
+
+## Part 1: {Task name}
+
+:information_source: Use this section to summarize what users complete in the following steps.
+
+### Step 1: {Step name}
+
+:information_source: You can use this format to describe your step:
+
+Explanatory text
+
+(Optional) Code sample or screenshot that helps your users complete this step.
+
+(Optional) Result on completing this step.
+
+#### (Optional) Sub step 1: {Substep name}
+
+:information_source: Beware of asking your users to do too much in one step. If needed, break a step into one or two smaller substeps.
+
+## Part 2: {Task name}
+
+...
+
+### Step 2: {Step name}
+
+...
+
+#### (Optional) Sub step 2: {Subtask name}
+
+...
+
+## Part n: {Task name}
+
+...
+
+### Step n: {Step name}
+
+...
+
+#### (Optional) Sub step n: {Subtask name}
+
+...
+
+## Next steps
+
+Now that you've completed this quickstart, try these to learn more about {feature}.
+
+* Reference Link 1
+* Reference Link 2
+* Reference Link n
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Quickstart) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/readme/example_readme.md b/meta/reference/good-docs-project-template-1.5.0/readme/example_readme.md
new file mode 100644
index 00000000..d97c73b9
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/readme/example_readme.md
@@ -0,0 +1,4 @@
+# README example
+
+The Good Docs Project has an official example of this template in action.
+You can view this example at the Chronologue repository: [Chronologue README](https://gitlab.com/tgdp/chronologue/docs/-/blob/main/README.md)
diff --git a/meta/reference/good-docs-project-template-1.5.0/readme/guide_readme.md b/meta/reference/good-docs-project-template-1.5.0/readme/guide_readme.md
new file mode 100644
index 00000000..8aff8946
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/readme/guide_readme.md
@@ -0,0 +1,147 @@
+# README 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).
+
+## Why do I need a README?
+
+Your README is your project's first impression and the first document users expect to find in a project's root folder. A README tells users what they need to know about your project, if the project is relevant to the user, and how users can engage with the project.
+
+In some cases, large projects may include sub-READMEs, or separate, smaller READMEs that support subfolders in the project.
+
+As projects evolve and grow, so should the according README file. READMEs should be revisited regularly to ensure relevant information is captured for new users.
+
+## README best practices
+
+* Write your README in an approachable, friendly voice.
+* Use strong verbs to describe your project, such as "instruct," "discover," or "build."
+* Be succinct. READMEs can be long, but that doesn't mean users need to read pages to understand why they should be interested in your project.
+* Avoid the passive voice.
+* Focus on why users would want to interact with your project, not just what your project can do.
+* Use all caps to name your file. To make it easier to discover, open source projects name this file in all caps: README.md.
+
+## Content of the README template guide
+
+The following sections provide guidance and context on how to fill out the README template.
+
+The README template is customizable; you can **reorder and remove sections or content** that do not apply to your project.
+
+### About the "Project logo and badge" section
+
+A project logo can be helpful for users to visually identify your project.
+
+Badges highlight important information, such as status indicators, health checks, or social media accounts. Badges can also provide validating information for users that your project is current and updated. Embed relevant badges to your README to add credibility to your project. [Learn more about badges](https://github.com/badges/shields) and [view examples](https://github.com/dwyl/repo-badges).
+
+### About the "Project Name" section
+
+The project name should be prominent in the README and easy for users to identify. A project name is usually included as an H1 heading. You may also want to consider adding the following to help identify the project:
+
+* Project URLs
+* Names of project owners
+
+_Note: Consider the stage your project is at and how much information is required in your README. Names associated with the project may be better located in a separate contact document, such as an Our Team document. [View The Good Docs' Our Team template and guide](https://gitlab.com/tgdp/templates/-/tree/main/our-team)_.
+
+### About the "Table of contents" section
+
+A table of contents can be useful in the case of lengthy READMEs. As the project evolves, the README may require a table of contents for information organization.
+
+_Note: For Markdown files, GitHub now automatically generates a table of contents in the file header. [Learn more about the GitHub TOC](https://github.blog/changelog/2021-04-13-table-of-contents-support-in-markdown-files/)_.
+
+### About the "Project description" section
+
+The project description is the most critical part of your README. Describe what the project does and explain why a user should care about your project. Avoid describing any languages, technologies, or tools that were used in the creation of your project until after you have given a strong description on why the user should engage with the project. In some cases, you may want to specify any project limitations or when a user would not want to use the project.
+
+Screenshots or videos may also be included in this section to help users understand your project. Any assets you direct users to should exist in the repo.
+
+You can use the below project description format to start filling in your project description. An example is provided.
+
+With _(this project)_ you can _(verb)_ _(noun)_...
+
+_(This project)_ helps you _(verb)_ _(noun)_...
+
+Unlike _(alternative)_, _(this project)_ _(verb)_ _(noun)_...
+
+---
+
+Example: With The Good Docs Project, you can discover open source project documentation templates. This project helps you build new documents and transform existing ones into relevant and helpful documentation that serves your users. Unlike googling and searching for an assortment of document templates, The Good Docs Project provides a one-stop location for all your template needs.
+
+---
+
+### About the "Who is the project for" section
+
+Identify who your project users are and state who can use the project. Describe the problems your project can help users solve and what tasks the project can help users accomplish.
+
+---
+
+Example: This project is intended for software developers, technical writers, and project managers who want processes, templates, and guides to help create open source documentation.
+
+---
+
+### About the "Project dependencies" section
+
+List any prerequisites a user needs to interact with your project. You may want to consider including descriptions on why the prerequisites you list are required for your project to provide context and awareness for your users. Include relevant links to installation instructions or resources. Examples of project dependencies include:
+
+* Familiarity with an application
+* Software and tools
+* Environments
+* Authentication and authorization information
+* Guides or informative documents
+
+### About the "Instructions for using project" section
+
+Include clear instructions to help a user understand how to use your project. Instructions are procedural steps that are typically formatted in an ordered list. Start each instruction with a verb.
+
+#### About the "Install {Project Name}" section
+
+Describe in clear steps how to install or download the project to a user's device.
+
+#### About the "Configure {Project Name}" section
+
+Describe in clear steps how to configure the project.
+
+#### About the "Run {Project Name}" section
+
+Describe in clear steps how to run the project.
+
+_Note: You can include links to Getting Started documents or Quickstart Guides to support your users. [View The Good Docs' Quickstart template and guide](https://gitlab.com/tgdp/templates/-/tree/main/quickstarts)._
+
+#### About the "Troubleshoot {Project Name}" section
+
+Describe in clear steps how to troubleshoot common issues. You can use a table for troubleshooting common issues to clearly identify issues and solutions.
+
+### About the "Contributing guidelines" section
+
+Provide clear instructions on how users can contribute to the project by linking to your contributing guidelines document or by embedding the guidelines in your README.
+
+_Note: Consider the stage your project is at. While most contributing guidelines are provided in a separate document, a smaller project may include guidelines in the README if the guidelines can be summarized in a few sentences._
+
+### About the "Additional documentation" section
+
+Provide additional documentation for users by including links and brief descriptions. Examples of additional documentation include:
+
+* Project website
+* Twitter handles of project/project owners
+* Relevant examples
+* Next steps
+* Features planned
+* Known bugs
+* Documentation files
+* Sub-READMEs
+* Help commands
+
+### About the "How to get help" section
+
+Provide guidance for users seeking assistance by including links and brief descriptions. Examples of help resources include:
+
+* Google group/mailing list
+* Email addresses
+* IRC, Slack, or Discord channels
+* Bug trackers
+* Stack Overflow
+
+### About the "Terms of use" section
+
+Include your project license and other relevant licensing information.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Readme%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/readme/process_readme.md b/meta/reference/good-docs-project-template-1.5.0/readme/process_readme.md
new file mode 100644
index 00000000..e3e3d36a
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/readme/process_readme.md
@@ -0,0 +1,70 @@
+
+# README 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 plan and research your project's README file
+
+The README file is the first file that displays in the main folder of a project's repository, making it the first file users encounter. Whether it's for an open-source project or commercial project, users should be able to read your README file to:
+
+* **Identify the project:** Readers should be able to figure out your project's name and find key information like a link to the project's website and the owner of the project (either the business, organization, or author).  
+* **Evaluate the project:** Readers should be able to explain what the project does, its core function, and what problem it solves. They should also be able to identify the project's terms of use without legal jargon.  
+* **Use the project:** Readers should be able to install and run the program for the first time. After installation, they should have an idea on how to test the program to see if it's working correctly and to get a sense of how to use it for its core purpose. For example, it might provide a simple "hello world" experience to try the project's core functionality.  
+* **Engage with the project:** Some readers need to know how to engage with the project (either as a contributor or to submit bug reports or feature requests as a user). They need to know how to contact the project owners, interact with the community or how to propose their ideas.
+
+While working on these goals, consider using the following strategies as you plan and do research your project's README file:
+
+* **Identifying details for the project:** Including the project's official name, its website (if applicable), and the project owners.  
+* **The core purpose of the project:** You should come up with a simple, straightforward description of the project that's written in clear, plain language.  
+* **How to install and run the program for the first time:** Try running a fresh install of the program and recording every step you need in order to prepare your environment and get the application running. Note any dependencies you need to install and how you can verify that the installation was successful. If the install process is overly complex and difficult to describe, consider opening up an issue against the project to simplify the process.  
+* **Design a "hello world" experience for the program:** A "hello world" experience is a small piece of code that you can run to get a simple demonstration of the basic usage of the software. If there isn't a simple "hello world" experience, consider opening up an issue to create this program for your software.
+* **Determine how you want others to contribute to the project:** Spend some time thinking about how you want people to interact with your project. If your project is open source, do you want people to join a community forum, open issues, or attend user group meetings? If your project is commercial or closed source, think about how you would onboard a teammate and what steps they would have to take in order to get access to the repository and begin contributing.
+
+## How to write the README
+
+Now that you have gathered information, it's time to start writing the README file. The following list includes some strategies for writing effective README content:
+
+* Consider explaining why users want to interact with your project, in addition to what it can do. Doing this creates a more compelling story about your project that not only piques their interest but also motivates them to explore and further engage with your project.  
+* Describe the problems that your project solves and how users who are facing them can benefit from using your project. Think of it as an advertisement on TV or a YouTube video. This creates a stronger connection with your project's audience.
+* Provide hyperlinks to the technology that's used to build your project. This can help users gain a better understanding of how they can contribute to it.
+* Use screenshots that convey the steps of using your project and clickable code snippets. This can save time and effort in writing the installation process.
+* Explain and provide hyperlinks to the places where users/contributors can share their feedback on the project. This would make it easier for users to directly report issues.
+* Mention and provide a few examples of contributions that you encourage (design, documentation, and code). This not only gives users an idea on how to contribute to the project but also reassures them that your project embraces many ways to contribute, which in turn brings a diverse audience.
+
+## How to maintain a README file
+
+A README file is one of your project's founding documents. So, your README file grows and matures along with your project. When your project first starts out, it might be a simple stub or placeholder document. As your project builds momentum and attracts users or additional contributors, your README adapts to those changes.
+
+At first, your README file usually doesn't contain much information because your project is new. However, it should contain at least these core items:
+
+* Project name and project owners  
+* The goal or core purpose of the project  
+* A list of dependencies and the current steps to install and run the program  
+* Terms of use (license)
+
+As your project grows and becomes more complex, update its README file to correspond with these changes. However, maintaining the accuracy and relevance of a README file over time can be difficult.
+
+When your README starts to be long or overly complex, that's a signal that it's time to move some of the information out of the README and into other important documents:
+
+| Document | Information |
+| :---- | :---- |
+| [CONTRIBUTING](https://gitlab.com/tgdp/templates/-/tree/main/contributing-guide) | Create a CONTRIBUTING guide to tell users how they can contribute to your open source project and join the community. |
+| [Troubleshooting](https://gitlab.com/tgdp/templates/-/tree/main/contributing-guide) | As your project expands, its users may encounter recurring issues. As that content gets more lengthy over time, you could move it to a troubleshooting guide |
+| [Our Team](https://gitlab.com/tgdp/templates/-/tree/main/our-team) | Create a list of your project's core maintainers to communicate who belongs to your open source project or organization and how contributors can contact or work with them. |
+
+Breaking your README out into other documents helps maintain a clear and concise README while providing necessary guidance for potential contributors. This separation fosters a consistent and welcoming environment for the community. Remember to interlink between your README file and these additional documents.
+
+### Additional maintenance strategies
+
+To help make it easier to maintain your README over time, consider trying these strategies:
+
+* **Update your README along with the code**: If the dependencies or installation process changes in the code, consider including a README update in the same pull request or merge request.  
+* **Add a table of contents:** As your project grows, your README file may become lengthy. If this happens, consider adding a table of contents for better organization.  
+* **Review your README file and make updates every time you release:** Build a release checklist item into your release process that includes reviewing the README file's content for accuracy and freshness.  
+* **Plan a roadmap for your project**: Create dedicated tasks using the project templates on your project's issue tracker (GitHub, GitLab, Jira). Categorize these tasks with labels such as "Planned," "In Progress," and "Reviewed" to organize and prioritize updates. If you work on a team, consider assigning members to "Planned" tasks to ensure consistent progress.  
+* **Automate your README's updates:** Implement tools like CI/CD pipelines (GitHub Actions) to automatically keep information like project dependencies up-to-date. Also, use linters like markdownlint and Vale to automatically check and fix formatting and styling issues. This approach can save you (and your team) time and effort.
+* **Get the community involved:** If the project is open source, encourage users to be a part of the maintenance process by having them share their suggestions for improving the README's clarity, content, or organization on your project's issue tracker. Consider inviting all first time users or contributors to create a friction log where they write down any places in the installation process where they became confused or struggled to complete the steps. They can then submit this log as a bug report or issue on the repository. This approach not only lessens the burden of doing constant updates but also fosters collaboration and shared responsibility amongst users, and makes the README file more comprehensive and user-friendly.
+
+Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/readme/resources_readme.md b/meta/reference/good-docs-project-template-1.5.0/readme/resources_readme.md
new file mode 100644
index 00000000..efff8ebb
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/readme/resources_readme.md
@@ -0,0 +1,27 @@
+# README resource guide
+
+Thank you for downloading this template from The Good Docs Project. Before using the [README template](https://gitlab.com/tgdp/templates/-/blob/main/readme/template-readme.md), read this document to see high quality examples of the template in action and to review the resources that helped create this template. Want to explore more templates? Check them out in our [templates](https://gitlab.com/tgdp/templates) GitLab repository.
+
+## Examples of README
+
+* [**github-changelog-generator**](https://github.com/github-changelog-generator/github-changelog-generator#readme) - This project's README file features a Table of Contents that makes navigation simple for contributors. It also has an Installation section that provides clear descriptions and clickable code snippets, making it easy for contributors to set up their development environment.
+* [**Mautic**](https://github.com/mautic/mautic) - The README for this project contains sections on what the product is, how to install it, and a list of people who previously contributed to the project. It also provides links to the project’s community and other resources like its user and developer documentation, making it easier for people to learn about Mautic and how to navigate the repository.
+* [**freeCodeCamp**](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/README.md) - This project’s README file contains a Table of Contents and provides clear descriptions about the type of content the project contains, its deployment process, and links to other resources like its documentation and community server.
+* [**LinksHub**](https://github.com/rupali-codes/LinksHub) - This README file contains a Table of Contents for user navigation. It also provides links to the project’s website, its social media, and the Contributing Guide. This helps contributors see how the project looks and gives them an idea of how they can contribute to it as well as stay notified about its updates.
+
+## References
+
+The authors of this template want to acknowledge the resources they consulted in the making of this template and how it informed certain elements of the template.
+
+| Source material | Best practice or section |
+| :---- | :---- |
+| [Write the Readable README](https://www.writethedocs.org/videos/na/2016/write-the-readable-readme-daniel-beck/) | In this Write the Docs talk by Daniel Beck, he describes the importance of the README file and provides strategies on how to make this document digestible for a project. For instance, Beck recommends that all README files should help the reader accomplish four key tasks: identify the project, evaluate the project, use the project, and engage with the project. This template takes inspiration from this source. |
+| [ddbeck’s README Checklist](https://github.com/ddbeck/readme-checklist/blob/main/checklist.md) | As a companion to his Write the Docs talk, Daniel Beck provides a checklist that maintainers can use to ensure that their project’s README file is effective. It also has some suggestions on how to structure the content for each section. For example, when creating the installation section, it recommends writing a list of the project’s dependencies such as the latest version of Git or Ruby. This advice inspired the authors to add a Project Dependencies section to the template. |
+| [Best Practices For An Eye Catching GitHub Readme \- Hatica](https://www.hatica.io/blog/best-practices-for-github-readme/) | In this article, Faraz Ansari describes best practices open source project owners should implement when writing the README file for their project. For example, Ansari suggests using concise language to ensure that people with different levels of technical expertise can understand how the project works.|
+| [15 Elements to Include in Your README Document \- Archbee](https://www.archbee.com/blog/readme-document-elements) | Davor lists 15 elements that you should include in a project’s README file. For example, they recommend adding a title that names the project, making it easier for users to understand what it is. Davor also suggests adding a Support section with links to the project’s community pages so users know where they can receive assistance for any issue they encounter. The template’s "How to get help" section derives from this source. |
+| [The Power of README Files: A Must-Have for Every Repository](https://deploybot.com/blog/the-power-of-readme-files-a-must-have-for-every-repository) | This article describes the significance of a project’s README file and provides tips on how to create one that engages users. For example, Facuno recommends adding a License section and being explicit about any restrictions or requirements to avoid legal repercussions. The template’s Terms of Use section derives from this source. |
+| [Ten Steps to a Better README - Mike Jang (Ignite OSCON 2015)](https://youtu.be/PC05prd2usY?si=HQ6_xlOs6Xy8ux6x) | In this video, Mike Jang provides 10 ways developers can improve their open source project’s README file. For example, he recommends not adding too many steps in the installation section so contributors/users won’t get confused when testing the project, which is something that the template’s Installation section considers. |
+| [readme.so](https://readme.so/) & [ReadMe](https://readme.com/) | These two websites provide a generator for creating README files. They could be helpful in starting the README and then checking it against the contents of the README template.  |
+| [Diátaxis](https://diataxis.fr/) | The official website of Diátaxis, a framework that's often used to structure & organize different technical documentation whether its README files or tutorials. |
+
+Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/readme/template_readme.md b/meta/reference/good-docs-project-template-1.5.0/readme/template_readme.md
new file mode 100644
index 00000000..6d952bed
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/readme/template_readme.md
@@ -0,0 +1,151 @@
+# README template
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_readme.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.
+
+## {Project} logo and badges
+
+{This section is optional. Embed an image of the project logo and include links to relevant badges in the README.}
+
+## {Project Name}
+
+{Include the project URL and project owner name underneath the project name if applicable.}
+
+## Table of contents
+
+{This section is optional.}
+
+1. Heading 1
+
+2. Heading 2
+
+3. Heading 3...
+
+## Project description
+
+{The README template guide includes information on how to write a project description and a project description. Here are some examples of effective phrases for describing a project.}
+
+With _{Project Name}_ you can _{verb}_ _{noun}_...
+
+_{Project Name}_ helps you _{verb}_ _{noun}_...
+
+Unlike _{alternative}_, _{Project Name}_ _{verb}_ _{noun}_...
+
+{Include screenshots and/or demo videos if applicable}
+
+## Who this project is for
+
+This project is intended for {target user} who wants to {user objective}.
+
+## Project dependencies
+
+Before using {Project Name}, ensure you have:
+
+* Prerequisite 1
+* Prerequisite 2
+* Prerequisite 3...
+
+## Instructions for using {Project Name}
+
+Get started with {Project Name} by {write the first step a user needs to start using the project. Use a verb to start.}.
+
+### Install {Project Name}
+
+1. {Write the step here.}
+
+    {Explanatory text here}
+
+    {Optional: Include a code sample or screenshot that helps your users complete this step}
+
+2. {Write the step here.}
+
+    a. {Substep 1}
+
+    b. {Substep 2}
+
+### Configure {Project Name}
+
+1. {Write the step here.}
+2. {Write the step here.}
+
+### Run {Project Name}
+
+1. {Write the step here.}
+2. {Write the step here.}
+
+### Troubleshoot {Project Name}
+
+1. {Write the step here.}
+2. {Write the step here.}
+
+
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+

+    Issue
+   
+    Solution
+   

+    {Describe the issue here}
+   
+    {Write solution here}
+   

+    {Describe the issue here}
+   
+    {Write solution here}
+   

+    {Describe the issue here}
+   
+    {Write solution here}
+   

+
+Other troubleshooting supports:
+
+* {Link to FAQs}
+* {Link to runbooks}
+* {Link to other relevant support information}
+
+## Contributing guidelines
+
+{Include a link to your contributing guide here. If you do not have a contributing guide, incorporate the information in the README.}
+
+## Additional documentation
+
+{Include links and brief descriptions to additional documentation. Examples provided in README template guide.}
+
+For more information:
+
+* Reference link 1
+* Reference link 2
+* Reference link 3...
+
+## How to get help
+
+{Include links and brief descriptions for support resources. Examples provided in README template guide.}
+
+* Reference link 1
+* Reference link 2
+* Reference link 3...
+
+## Terms of use
+
+{Project Name} is licensed under {link to license file}.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Readme%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/reference/guide_reference.md b/meta/reference/good-docs-project-template-1.5.0/reference/guide_reference.md
new file mode 100644
index 00000000..45d272f5
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/reference/guide_reference.md
@@ -0,0 +1,71 @@
+# Reference 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 
+
+A reference article provides users with descriptions of specific components or characteristics of your application. It aims to present concise, structured information that a user can quickly scan. It is important to limit procedural or instructional content.
+
+Reference articles are often confused with API references. Though these documents help the users get acquainted with the application, they differ significantly in the type of target audience and content. The following table describes the differences: 
+
+|  | Reference  | API Reference  |
+| :---- | :---- | :---- |
+| Target Audience  | Users who are unfamiliar with the problem space and product, and users seeking clarification on CLI commands and arguments. | Domain experts who know the problem space and wish to interact with the product using the product's API. |
+| Content | Brief descriptions of referenced content, CLI commands and arguments. | Detailed information about available endpoints and the available parameters of an API. |
+
+## Why do I need a reference article?
+
+A reference article is important because it provides a structured and concise source of information that mirrors your application’s structure. Users can quickly and easily access it to find specific information about a product.
+
+There are several common scenarios where reference topics are appropriate: 
+
+* For programming languages, a reference article should cover specific functions, methods, classes, and libraries, explaining syntax, parameters, return values, and providing examples.
+
+
+* For technical specifications of hardware or software products, reference documents often provide detailed information on specifications, configurations, and compatibility. These references help users understand the technical capabilities of a product.
+
+* For software applications, configuration settings refer to individual settings or options. Providing these settings in a reference document can significantly improve a user's ability to understand the purpose and possible values of each setting. 
+
+It is important to note that reference articles are often integrated with other content types, such as task topics, to create comprehensive documentation. For example, a task topic may provide step by step instructions for using a feature, with reference links to detailed parameters or endpoints at the bottom of the task for users who need more information. 
+
+## Best practices for writing a reference article
+
+When writing a reference it is important to:
+
+* Ensure consistency in structure, terminology, and tone.  
+* Avoid high-level usage instructions or descriptions for the application.  
+* Provide concepts with essential vocabulary and context for users to learn and understand their tasks.  
+* Ensure that reference information is task-oriented and avoids unnecessary details.  
+* Always consider the user’s needs when crafting reference information.  
+* Ensure that the information supports users in making decisions or completing tasks related to the application’s functionality.  
+* Remove irrelevant information from documentation, as it can frustrate and confuse users.
+
+## About the “Reference description” section
+
+Use this section to provide the following:
+
+* Ensure that the section concisely summarizes the reference article's content and purpose.  
+* Keep the descriptions brief yet informative, offering users a clear understanding of the reference material.  
+* Avoid unnecessary details that could confuse or overwhelm readers. Instead, focus on highlighting key themes or functionalities covered in the article.  
+* Strive to strike a balance between brevity and completeness, ensuring that the summary effectively communicates the essence of the reference material.
+
+## About the “Table name or other structured entry” section
+
+Use this section to provide the following:
+
+* Include tables, lists, object schemas (attributes, objects), or other structured formats in this section.  
+* Use these formats to present information in an organized and easily understandable manner.  
+* Ensure that the structured entries provide comprehensive details on the topic at hand.  
+* Use active voice to make the descriptions clear and concise, enhancing readability.  
+* Aim for clarity and completeness in the presentation of information, while avoiding unnecessary complexity.  
+* Use tables and bulleted lists to increase readability and comprehension for users.
+
+## About the “Commands” section
+
+Use this optional section to provide the following:
+
+* Use this section to include code or code blocks, along with brief descriptions.  
+* If necessary, specify optional or required configurations for the commands.  
+* Provide examples demonstrating how the command operates with different configurations.
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Reference%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/reference/process_reference.md b/meta/reference/good-docs-project-template-1.5.0/reference/process_reference.md
new file mode 100644
index 00000000..7e512ddb
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/reference/process_reference.md
@@ -0,0 +1,36 @@
+# Reference 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+## How to research reference material
+
+* Identify the reference document’s purpose, whether it’s a command reference, component reference, or another type. Structure and adjust the level of detail to match its purpose.  
+* Analyze the application or component to determine the most critical and frequently accessed information.  
+* Collaborate with engineering teams to understand technical requirements, planned features, and product roadmaps to ensure documentation evolves alongside development.  
+* Participate in sprint planning, roadmap discussions, or technical reviews to align reference documentation with product milestones.  
+* Interview stakeholders or gather feedback to identify common user challenges or misunderstandings.  
+* Review existing documentation and competitor references to identify gaps, reuse relevant content, and ensure alignment with your documentation standards.  
+* Match the level of detail to the documentation’s maturity. Focus on key use cases and provide quick updates. As the documentation matures, include detailed compatibility, edge cases and changelogs.
+
+## How to write reference material
+
+* Structure content to match how the product presents commands, components, or attributes, ensuring consistency with the product’s design and terminology.  
+* Format content for easy scanning by using tables for parameters, compatibility, and settings; lists for options or grouped values; and object schemas or syntax blocks with examples.  
+* Organize entries alphabetically when it helps users find information.  
+* Present key information clearly using tables that include the name, description (what and why), whether the item is required or optional, and an example.  
+* Use compatibility tables to display support across operating systems, browsers, hardware, or software versions.  
+* Write in active voice with concise, accurate sentences that start with essential information, followed by helpful context or examples.  
+* Avoid turning reference content into tutorials or explanations. Keep the focus factual and task-oriented.  
+* Link to additional resources or articles for users seeking more detailed information.  
+* Explain technical terms only when necessary and avoid unnecessary jargon that could confuse the intended audience.  
+* Emphasize user needs by highlighting relevant, straightforward information and focusing on key functionalities or attributes without including irrelevant details.  
+* Balance conciseness with enough detail to make the content genuinely helpful.
+
+
+## How to maintain reference material
+
+* Regularly update the reference article to reflect new features, updates, or user feedback.  
+* Monitor user interactions or support tickets to identify sections that need clarification or improvement.  
+* Ensure formatting and style stay consistent with documentation standards as they evolve.
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=\%20process) to give feedback on this template.
\ No newline at end of file
diff --git a/meta/reference/good-docs-project-template-1.5.0/reference/resources_reference.md b/meta/reference/good-docs-project-template-1.5.0/reference/resources_reference.md
new file mode 100644
index 00000000..bc3d0aa5
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/reference/resources_reference.md
@@ -0,0 +1,26 @@
+# Reference 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 guided the creation of this template. Want to explore more templates? Check them out in our [templates GitLab repository](https://gitlab.com/tgdp/templates).
+
+## Examples of Reference
+
+* [**Amazon AWS CLI Command Reference**](https://docs.aws.amazon.com/cli/latest) - The AWS CLI Command Reference explains commands for AWS services with clear syntax, options, and examples. Its logical organization and focus on practical use cases inspired our template's structured "Commands" section, ensuring users can find and apply information.  
+* [**Google Cloud CLI Reference**](https://cloud.google.com/sdk/docs#reference) - The Google Cloud CLI Reference balances short overviews with detailed examples and step-by-step instructions for each command. We used its practical examples and structured approach as a model to ensure our template supports users with actionable and clear information.  
+* [**Microsoft Azure Reference Index A to Z**](https://learn.microsoft.com/en-us/cli/azure/reference-index) - The Azure Reference Index A to Z provides a complete alphabetical list of Azure commands, each with concise summaries and links to detailed documentation. Its straightforward structure influenced our focus on clarity and easy navigation, making our reference template user-friendly.  
+* [**Microsoft Windows Commands**](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands) - The Microsoft Windows Commands guide provides a complete alphabetical list of Windows command-line tools and includes syntax, examples, and detailed descriptions. Its emphasis on simplicity and usability inspired our approach to grouping related information and offering clear, real-world examples in the "Commands" section.  
+* [**Couchbase SQL++ for Query Reference**](https://docs.couchbase.com/server/current/n1ql/n1ql-language-reference/index.html) - The Couchbase SQL++ for Query Reference provides a comprehensive overview of Couchbase’s SQL-like query language. Its blend of syntax details, operator documentation, and practical examples guided our approach to documenting complex command behavior while maintaining clarity for both novice and experienced users.  
+* [**Microsoft Search Product and Services Lifecycle Information**](https://learn.microsoft.com/en-us/lifecycle/products) - This site uses clear tables, chronological ordering, and a focus on key support milestones to present product lifecycles effectively. The site supports the template guidance to highlight important facts, avoid unnecessary detail and link to external resources when needed.
+
+## 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 |
+| :---- | :---- |
+| [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome) | Emphasized the importance of using active voice, short sentences, and simple words to ensure content is accessible and easy to understand. These principles guided the crafting of concise descriptions and instructions, ensuring headings and table entries were clear and user-focused. |
+| [Write the Docs: Software documentation guide](https://www.writethedocs.org/guide/index.html) | Highlighted the value of focusing on the user's tasks by breaking down complex information into smaller, actionable steps. Stressed avoiding unnecessary jargon and including relevant examples. Inspired the structure of the template, such as the "Commands" section, where each command includes clear examples and simple explanations to help users complete specific tasks. |
+| [Markdown Guide: Cheat Sheet](https://www.markdownguide.org/cheat-sheet) | Demonstrated how to format content with headers, lists, tables, and code snippets to make documentation more scannable and visually organized. Provided formatting techniques for presenting tables and commands in the template, ensuring the layout is clean and easy for users to navigate. |
+
+   
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=\%20resources) to give feedback on this template.
+
diff --git a/meta/reference/good-docs-project-template-1.5.0/reference/template_reference.md b/meta/reference/good-docs-project-template-1.5.0/reference/template_reference.md
new file mode 100644
index 00000000..9efe9526
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/reference/template_reference.md
@@ -0,0 +1,33 @@
+# Reference template
+
+> If you need more information about how to fill in this template, read the accompanying [guide](link to the template guide).
+
+> 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.
+
+## {Reference description}
+
+{This section provides a structured list of settings, field descriptions, and other reference details. This document can serve as a standalone reference or complement other types of documentation, typically at the end of a procedural document, to provide additional context. Define the scope of this reference and how it relates to other documents if applicable.}
+
+## {Table name or other structured entry}
+
+{Choose this reference format if you want to organize the data for clarity and usability. Use tables for structured information, lists for quick references, or other structured formats that align with the reference material. Ensure consistency in formatting throughout the document.}
+
+{Table or other structured entry. Organize the tables or structured entries so that they appear in the same order as in the reference material.}
+
+| Field | Description | Example  |
+| :---- | :---- | :---- |
+|  |  |  |
+
+## (Optional) Commands
+
+{Choose this reference format if you want to present the command information clearly and consistently. Use tables for structured command details, lists for quick references, or code blocks for readability. Ensure formatting aligns with the reference material and maintains consistency throughout the document.}
+
+{Short description including code or code blocks.} 
+
+| Command | Description | Argument | Example |
+| :---- | :---- | :---- | :---- |
+| This is the name of the command | A brief description of what the command does. | This denotes whether an argument is optional or required. | If needed, add an example to show how the command uses different configurations. |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Reference%20template%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/release-notes/guide_release-notes.md b/meta/reference/good-docs-project-template-1.5.0/release-notes/guide_release-notes.md
new file mode 100644
index 00000000..b8652efc
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/release-notes/guide_release-notes.md
@@ -0,0 +1,303 @@
+# Release Notes 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).
+
+## Introduction
+
+Release notes communicate new features, improvements, bug fixes, and known issues to stakeholders such as customers, Technical Support, Sales, Marketing, and users.
+This template guide and template are intended for customer-facing release notes, however, you can adapt it for internal release notes as needed.
+
+Stakeholders with both technical and non-technical backgrounds must understand what's changed, and why those changes are important to the user.
+
+Many teams contribute to release notes, however, they must have a single owner.
+The owner can vary.
+In some organizations, the Product Manager writes the first draft and owns the release notes; in other organizations, the Marketing department or Technical Documentation team owns the release notes.
+
+Release notes are usually published at the same time as a product or feature release.
+
+## Why do I need release notes?
+
+Release notes are important for the following reasons:
+
+* They indicate transparency. Frequent release note updates show that you actively maintain the product and care about your stakeholders.
+* They reduce support tickets. They keep your stakeholders informed about current releases, especially new features and known issues.
+* They help your stakeholders assess impacts that might occur during upgrades.
+* They provide a plain-language record of your software's evolution. Stakeholders don't have to read development-heavy changelogs to find out what's changed and why it matters to them.
+
+The following table describes the differences between changelogs and release notes:
+
+| Release Notes                                                                                                                                                                              | Changelogs                                                                                                                                                                                                                 |
+|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Customer focused                                                                                                                                                                           | Developer focused                                                                                                                                                                                                          |
+| Use plain language.                                                                                                                                                                       | Use technical language.                                                                                                                                                                                                   |
+| Typically requires research to understand the features, functionality, and user experience.                                                                                               | Typically a light effort as it is closely related to developers' current work.                                                                                                                                            |
+| Describes the changes to features and functionality. 
  • Can include media to enhance descriptions.
  •  Often includes links to the user documentation for more information.
    •  | A reverse chronological list that describes code changes and their impact on the features. 
    • Can include links to merge requests, issue numbers, or commits.
    • Can list contributors to the release.
     |
+| Includes what changed and why.                                                                                                                                                            | Links to the developer who made the change and specific issues.                                                                                                                                                           |
+| Typically written by a Technical Writer or Product Manager.                                                                                                                               | Typically written by a Software Developer derived from commit messages to a version control system.                                                                                                                       |
+
+## About this template
+
+The template includes the following sections common to release notes:
+
+* [Title](#about-the-title-section): Describes common conventions for titles and numbering in release notes.
+* [Release Notes version](#release-notes-version-optional) (optional): Include a document version number.
+* [High-level summary](#optional-high-level-summary) (optional): One to two sentences that highlight the most important items in the release notes.
+* [New features](#about-the-new-features-section): Describes new features and functionality.
+* [Improvements](#about-the-improvements-section): Describes updates to existing features and functionality.
+* [Bug fixes](#about-the-bug-fixes-section): Describes bug defects and their resolution.
+* [Known issues](#about-the-known-issues-section): Describes defects to be fixed in the future.
+* [Deprecated features](#about-the-deprecated-features-section) (optional): Describes features that will be removed from the software.
+
+## Release notes best practices
+
+* Write the release notes in a positive and friendly tone.
+* Write in the second person. For example "Use your menu to access the window."
+* Be clear, concise, and consistent.
+* Use plain language.
+* Write in the present tense, except when you describe bug fixes; use the past tense for bug fixes.
+
+## About the "Title" section
+
+The title of your release notes should correspond to a product release number.
+This helps stakeholders identify which release the notes are describing.
+Many teams use [semantic versioning](https://semver.org/) to number their releases.
+This is usually shown as three numbers, separated by periods.
+For example, 1.3.2.
+
+If your organization publishes release notes off a release cycle, include the date in the title or subtitle.
+If you incorporate a date into your title, use the following format: YYYY-MM-DD.
+
+## Release Notes version (optional)
+
+If you must edit release notes after publication, some teams update the document version number.
+This template includes an optional space for a release notes version number.
+
+## High-level summary (optional)
+
+A high-level summary can help stakeholders quickly understand the most important items in your release notes, especially if your notes are long.
+Keep the summary short.
+If your product team communicates frequently with stakeholders outside the release notes publication cycle, the summary might be redundant.
+
+## About the "New features" section
+
+List the most important features first.
+What is important depends on your organization and stakeholder priorities.
+Consider the features from the stakeholder's point of view, and list new features that have the most impact on their experience first.
+
+When you write about new product features:
+
+1. Use an engaging, concise title to summarize the feature.
+2. Describe how the feature benefits the stakeholder. You might ask yourself, "Why is this valuable? How does it benefit the business?"
+3. Include screenshots or short videos if they help the stakeholder understand the feature.
+4. Link to the feature's full documentation in the description. The description in this section  includes only a brief description. Link to the full documentation to provide a complete description, which becomes the source of truth.
+
+The following is an example of a new feature:
+
+* **Find Your Recent Transactions with Personal Log**
+
+    Use Personal Log to quickly access your most recent transactions.
+When speaking with a customer, you can select the last five transactions that you accessed from a menu.
+You can also perform a more extensive search to find specific transactions you accessed in your queues.
+See [Personal Log](http://example.com) for more information.
+
+The following formulas might be helpful when writing new features:
+
+**Formula 1:**
+
+* [ ] You can now {describe what you can do with the feature}.
+* [ ] This means you can {benefit}.
+* [ ] See {link to topic name} for more details.
+
+    **If we were to apply this formula, using the previous example, it reads as follows:**
+
+    You can now quickly access your most recent transactions.
+    This means you can select the last five transactions that you accessed from a menu when speaking with a customer. You can also perform a more extensive search to find specific transactions you accessed in your queues.
+    See [Personal Log](http://example.com)  for more details.
+
+**Formula 2:**
+
+* [ ] {The application} now provides {feature}...
+* [ ] …{benefit}.
+* [ ] See {link} for more details.
+
+    **If we were to apply this formula, using the previous example, it reads as follows:**
+
+    Software X now provides a Personal Log, so you can quickly access your most recent transactions.
+    See [Personal Log](http://example.com) for more details.
+
+## About the "New features requiring configuration updates" section
+
+List the most important features requiring configuration updates first. What is important depends on your organization and stakeholder priorities. Consider the features and changing configurations from the stakeholder's point of view, and list new features that have the most impact on their experience first.
+
+When you write about new product features requiring configuration updates:
+
+1. Use an engaging, concise title to summarize the feature.
+2. Describe how the feature benefits the stakeholder. You might ask yourself, "Why is this valuable? How does it benefit the business?"
+3. Describe the nature of the configuration update
+4. Include screenshots or short videos if they help the stakeholder understand the feature and configuration updates.
+5. Link to the feature's full documentation in the description and link to any relevant configuration documentation. The description in this section includes only a brief description. Link to the full documentation to provide a complete description, which becomes the source of truth.
+
+The following is an example of a new feature:
+
+* **Find your recent transactions with Personal Log**
+  Use Personal Log to quickly access your most recent transactions. When speaking with a customer, you can select the last five transactions you accessed from a menu. You can also perform a more extensive search to find specific transactions you accessed in your queues.
+  Before using this feature, you need to configure Personal Log settings in the Admin Panel, including granting user permissions and defining search parameters.
+  See [Personal Log](http://example.com) documentation for more information.
+
+The following formulas might be helpful when writing new features:
+
+**Formula 1:**
+
+* [ ] You can now {describe what you can do with the feature}.
+* [ ] This means you can {benefit}.
+* [ ] In order to use this new feature, you must  {describe the configuration updates}.
+* [ ] See {link to topic name} for more details.
+
+  **If we were to apply this formula, using the previous example, it reads as follows:**
+
+  You can now quickly access your most recent transactions. This means you can select the last five transactions that you accessed from a menu when speaking with a customer. You can also perform a more extensive search to find specific transactions you accessed in your queues.
+  To enable this feature, you need to configure Personal Log Settings in the Admin Panel. This configuration involves:
+* Granting user permissions for Personal Log access.
+* Adjusting settings to define the transaction history retention period and search parameters.
+
+See [Personal Log](http://example.com) documentation for more details on configuration steps and feature benefits.
+
+**Formula 2:**
+
+* [ ] {The application} now provides {feature}.
+* [ ] …{benefit}.
+* [ ] To enable this feature, you need to {briefly describe the required configuration update}.
+* [ ] See {link} for more details.
+
+  **If we were to apply this formula, using the previous example, it reads as follows:**
+
+  Software X now provides Shift Priority Rules, so you can ensure critical shifts are filled first.
+  To enable this feature, you need to configure Shift Priority settings in the Admin Panel, defining priority levels for specific roles or shifts. See [Shift Priority Rules](http://example.com) for more details.
+
+## About the "Improvements" section
+
+List the most important improvements first.
+What is important depends on your organization and stakeholder priorities.
+Consider the features from a stakeholder's point of view and list the improvements that have the most impact on the stakeholder's experience first.
+
+**_NOTE:_** Some organizations refer to this section as Enhancements.
+
+When you write about improvements:
+
+1. Use an engaging, concise title to summarize the feature.
+2. Describe how the feature benefits the stakeholder. You might ask yourself, "Why is this valuable? How does it benefit the business?"
+3. Include screenshots or short videos if they might help your audience.
+4. Link to the user documentation for the full description.
+
+The following is an example of an improvement:
+
+* **Recommendations widget now offers an export function.**
+
+    In addition to viewing the Accept, Challenge, and Deny recommendations in a pie chart, you can now export the data.
+Risk Analysts can manipulate this data to analyze the recommendations further.
+See the [Recommendations Widget](http://example.com).
+
+The following formula might be helpful when writing about improvements:
+
+**Formula 1:**
+
+* [ ] {Describe what was added, updated, or removed}.
+* [ ] {Describe the benefit}.
+* [ ] See {link to user documentation}.
+
+    **If we were to apply this formula, using the previous example, it reads as follows:**
+
+    In addition to viewing the Accept, Challenge, and Deny recommendations in a pie chart, you can now export the data.
+    Risk Analysts can manipulate this data to analyze the recommendations further.
+    See the [Recommendations Widget](http://example.com).
+
+## About the "Bug fixes" section
+
+Bug fixes describe what was fixed and why it was useful to the stakeholder.
+For example, if new fields are added to a database, you must find out how this helps stakeholders and communicate that information to them.
+
+When you write about bug fixes:
+
+1. Do not start each sentence with "Fixed the bug…".
+2. Do not describe how the bug was fixed.
+3. Link to relevant documentation.
+4. Consider what the software did previously and what it does now.
+5. Optional: Include the issue number and link to it.
+**_NOTE:_** This depends on your organization. Some organizations do this for internal release notes only while others do this for external distributions. This can be useful if your stakeholder contacts your support team.
+
+The following is an example of a bug fix:
+
+* [JIRA-12345] Transactions in the Chargebacks queue are now sorted from newest to oldest. See [Chargebacks queue](http://example.com) for more information.
+
+The following formulas might be helpful when writing about bug fixes:
+
+**Formula 1:**
+
+* [ ] [{Bug fix number}] If {the user or application performs an action}...
+* [ ] {describe how the software is fixed}.
+
+    **If we were to apply this formula, using the previous example, it reads as follows:**
+
+    [JIRA-12345] If you open the Chargebacks queue, transactions are now sorted from newest to oldest.
+    See [Chargebacks queue](http://example.com) for more information.
+
+**Formula 2:**
+
+* [ ] [{Bug fix number}] The {application or feature} now…
+* [ ] {describe how the software is fixed}.
+
+    **If we were to apply this formula, using the previous example, it reads as follows:**
+
+    [JIRA-12345] The Chargebacks queue now sorts transactions from newest to oldest.
+    See [Chargebacks queue](http://example.com) for more information.
+
+## About the "Known issues" section
+
+A known issue is a technical issue that will not be resolved as part of the release. You must communicate these issues if they might impact your stakeholder's experience.
+
+When you write about a known issue:
+
+1. Describe the scenario or problem.
+2. Provide an example, if needed.
+3. Describe a workaround, if possible.
+4. Optional: Include a way for your stakeholders to contact you. Some organizations want the feedback, others don't want to give stakeholders more ways to contact them.
+5. Optional: Include the issue number and its link so the stakeholder can track the progress of the issue.
+**_NOTE:_** This depends on your business. Some businesses do this for internal release notes only while others do this for external distributions. This can be useful if your stakeholders contact your support team.
+
+**The following is an example of a known issue:**
+
+* [Jira-00001] If you set the `refreshToken` to `true` and are migrating from version 5.x to 6.x, scheduled jobs will no longer work.
+
+    JWT tokens generated prior to MySoftware 6.x is not compatible with the offline tokens used in MySoftware 6.x.
+To remedy this, each user must log out of MySoftware, then log back in.
+
+## About the "Deprecated features" section
+
+A deprecated feature is intended to be phased out of the software application.
+Including deprecated features in release notes is optional.
+Many organizations communicate deprecated features through other methods, such as application notifications, email, or other alerts.
+
+If you include deprecated features in your release notes, include the following information:
+
+1. The name of the feature and a link to the existing user documentation.
+2. Any action a stakeholder must take to preserve their data.
+3. Information about the feature that replaces the deprecated feature.
+4. The date when a deprecated feature is removed.
+5. Optional: Include the issue number and its link.
+**_NOTE:_** This depends on your business. Some businesses do this for internal release notes only while others do this for external distributions. This can be useful if your stakeholders contact your support team.
+
+**The following is an example of a deprecated feature:**
+
+* **[JIRA-56789] Recommendations widget**
+
+    The Advisory widget will replace the Recommendations widget in a future release.
+The system will automatically migrate your data from the Recommendations widget to the Advisory widget.
+See the [Recommendations Widget (deprecated)](http://example.com).
+
+## Additional Resources
+
+See "[How to write meaningful release notes](https://drive.google.com/file/d/1q5GVhFEcUFzYxSkeOvzAyN9Gh0xPbAI-/view)" for additional ideas.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Release%20notes%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/release-notes/process_release-notes.md b/meta/reference/good-docs-project-template-1.5.0/release-notes/process_release-notes.md
new file mode 100644
index 00000000..19c5693e
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/release-notes/process_release-notes.md
@@ -0,0 +1,167 @@
+# Release notes 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.
+
+Release notes provide a clear, structured overview of updates, fixes, and changes in a software release, helping users and stakeholders quickly understand what's new, improved, or fixed. This document serves as an essential touchpoint between development teams and users, making it easier to identify enhancements, spot new feature requirements, and track bug resolutions. Release notes are especially valuable for product updates that may impact user workflows, require configuration changes, or introduce new functionality. Use this template to ensure your release notes are clear, comprehensive, and actionable for a wide range of users.
+
+Release notes are essential whenever you deliver updates that impact users, regardless of your release cadence. In Agile Software Development, frequent release notes keep users informed about continuous improvements and help teams stay aligned on incremental updates. For products with a regular release cadence-whether monthly, quarterly, or annually-release notes provide transparency into major changes and enhancements users can expect at predictable intervals. Release notes are also crucial for hotfixes or security patches, where immediate communication helps users understand critical fixes and any actions they might need to take.
+
+## How to research release notes
+
+Researching release notes is key to providing accurate and relevant information about product updates, requiring close collaboration with product managers, development teams, and customer support to ensure comprehensive coverage of new features and changes.
+
+### Collaborate with Product Managers
+
+Product managers are a key role for all software teams. The overall goal of product management is to ensure that software products deliver value to customers and that your products are competitive in the marketplace. Product managers are responsible for determining what goes into a release based on customer or user demand. As such, they usually have the best sense of what is going into each release and what the high priority items are, especially from a customer point of view.
+
+#### Engage with product managers regularly
+
+* Collaborate with product managers to stay updated on the product roadmap, release plans, and upcoming changes. This ensures you are well-informed about future features and developments.
+
+* Schedule regular syncs or attend product review meetings to gain insights into how specific features align with business goals or address user pain points.
+
+* Participate in product brainstorming or ideation sessions to understand the strategic direction of the product.
+
+#### Join product updates and demonstration sessions
+
+* Attend sprint reviews or product demonstrations led by the product management team to observe new functionalities, modifications, or product iterations.
+
+* Use these sessions to ask questions and clarify feature details, ensuring a solid understanding of how the new product functionalities solve user problems or provide value.
+
+#### Leverage product manager expertise for deeper insights
+
+* Work closely with product managers to get in-depth knowledge about the rationale behind key features or changes. This enables you to effectively communicate the benefits and impact to users.
+
+* Gather detailed insights on which aspects of the product might require more user training or enablement support, based on user experience data and feedback gathered by product managers.
+
+#### Identify key focus areas for communication
+
+* Collaborate with product managers to understand user feedback, beta test results, and any other data points they track to prioritize communication efforts. This helps you highlight the most impactful features or updates in your training or enablement materials.
+
+#### Create a feedback loop
+
+* Establish a two-way feedback system with product managers, where insights from your enablement efforts or user interactions can be relayed back to help shape future product enhancements. This ensures that product development remains aligned with user needs and training outcomes.
+
+### Engage with development teams
+
+Development teams are essential partners in the release notes process, as they are directly responsible for building, testing, and troubleshooting the product. Their in-depth knowledge of new features, technical improvements, bug fixes, and known issues makes them invaluable sources of detailed information for release notes. Developers often have a clearer understanding of the technical aspects of updates, including any dependencies or configurations that users may need to know. Engaging with development teams ensures that release notes are both accurate and comprehensive, providing users with critical insights into the products latest changes and improvements.
+
+#### Maintain regular communication
+
+* Hold regular meetings with development teams to stay updated on releases, bug fixes, and feature changes.
+
+* Join sprint planning sessions for early insights and to prepare release notes in advance.
+
+#### Attend sprint reviews and demos
+
+* Participate in reviews or demos to see new features in action and clarify technical details.
+
+* Capture known issues or limitations to address them in release notes.
+  
+#### Leverage developer insights
+
+* Understand the rationale behind changes to explain both the "what" and "why" in release notes.
+
+* Prioritize complex features for detailed explanations and create a feedback loop to improve future releases.
+
+#### Track progress and adjust for changes
+
+* Monitor bug fixes and enhancements, and stay informed of any last-minute changes to update release notes promptly.
+
+### Collaborate with customer support teams
+
+Customer support teams play a crucial role in the release notes process by acting as the primary bridge between the product and its users. They have deep insights into common pain points, frequently reported issues, and areas where users may need additional guidance. Support teams can provide valuable context about the types of updates or fixes that will have the most impact from a user perspective, helping to highlight key details that users care about. Collaborating with customer support ensures release notes are user-focused and address the real-world concerns that matter most to your audience.
+
+#### Regular syncs for customer insights
+
+* Meet with support teams to gather feedback on key customer issues, ensuring the most impactful fixes are highlighted in the release notes.
+
+* Coordinate with support or customer service teams to identify common pain points or frequently asked questions. This insight can guide you on what should be highlighted in the release notes, especially regarding bug fixes or improvements.
+
+### Review product roadmaps
+
+Check the product backlog or roadmap regularly for future developments that require documentation in future release notes. Understanding the long-term goals helps provide context for the current release.
+
+### Interview key stakeholders
+
+Conduct interviews or surveys with key stakeholders, such as product managers, engineers, customer support managers, and even users, to gain insights into the impact of changes and ensure that the release notes capture the full value of the update.
+
+### Test new features
+
+If possible, use a sandbox or pre-release environment to engage with the new features or updates firsthand. This will allow you to understand how the changes function in practice, making your descriptions more accurate and useful.
+
+## How to write release notes
+
+Writing effective release notes involves prioritizing clarity and user-focused language, organizing content by importance, and maintaining a consistent format to ensure users can quickly understand the value of new features, improvements, and bug fixes.
+
+### Prioritize clarity and conciseness
+
+Use simple, direct language to explain changes. Avoid jargon and technical terms unless necessary, and provide explanations if you must use them. Focus on what the user needs to know to understand the update.
+
+### Organize content by importance
+
+Start with the most impactful changes, such as new features or critical fixes, then move on to minor improvements or tweaks. This structure helps users quickly identify what's important to them.
+
+### Use a consistent format
+
+Maintain a consistent format across all release notes. Common sections include:
+
+* **Version number** and **release date**
+
+* **New features**: Description of new functionalities and their benefits.
+
+* **New features requiring configuration updates**: Inform users about new features or enhancements that need additional configuration or changes in settings to function correctly.
+
+* **Improvements/Enhancements**: Details on performance improvements, UI/UX changes, etc.
+
+* **Bug fixes**: Use consistent phrasing, like "Resolved an issue..." for each entry, and briefly explain how each fix benefits the user experience.
+
+* **Known issues**: Any unresolved problems that may impact the user.
+
+### Focus on the value to users
+
+Describe changes in terms of how they benefit the user. Rather than simply stating a feature has been added, explain how it improves their workflow, saves time, or adds functionality.
+
+### Make it scannable
+
+Use bullet points, headers, and short paragraphs to make the release notes easy to scan. Users often want to quickly identify what's relevant to them, so avoid lengthy blocks of text.
+
+### Use visuals when needed
+
+If the changes are complex or visual (UI updates, for example), include screenshots or GIFs to illustrate the changes. This is especially helpful for features that require visual guidance to understand.
+
+### Include links to more information
+
+If a new feature or update requires a more detailed explanation or documentation, link to help articles, user manuals, or video tutorials.
+
+## How to maintain release notes
+
+Maintaining release notes requires a structured approach to ensure they remain accessible, consistent, and up-to-date. By creating a centralized repository, monitoring feedback, and establishing a regular review process, teams can ensure that release notes continue to serve as accurate, valuable resources over time.
+
+### Create a centralized repository
+
+Maintain an easily accessible, centralized location where all past release notes are archived. This allows users and internal teams to easily reference previous versions if needed.
+
+### Keep consistency across multiple channels
+
+Ensure that release notes are consistent across all platforms--whether the product's website, customer portal, or internal knowledge base. This prevents users from encountering outdated or conflicting information.
+
+### Monitor feedback and questions
+
+Regularly gather feedback from users and support teams on the clarity and usefulness of your release notes. If certain sections cause confusion or lead to frequent support requests, iterate and adjust your format or content to address these concerns.
+
+### Establish a review process
+
+Set up a regular review cycle with stakeholders, such as product managers, developers, and support to ensure that the release notes accurately reflect the updates and align with future product goals.
+
+### Document lessons learned
+
+After each release, document what went well in writing and maintaining the release notes and what can be improved. Use this information to refine the process for future releases.
+
+### Track and version control
+
+Use version control to manage changes in your release notes over time. This helps in maintaining a history of edits and ensures that you can roll back or review previous versions if needed.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Release%20notes%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/release-notes/resources_release-notes.md b/meta/reference/good-docs-project-template-1.5.0/release-notes/resources_release-notes.md
new file mode 100644
index 00000000..f2cfb603
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/release-notes/resources_release-notes.md
@@ -0,0 +1,44 @@
+# Release notes 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.
+
+Take a look at the following accompanying resources:
+
+* For step-by-step guidance on creating release notes, explore our [Release notes process](process_release-notes.md).
+
+* To fill out your release notes information into a structured template, explore the [Release notes template](template_release-notes.md).
+
+* To see examples and suggestions about how to fill in the Release notes template, explore the [Release notes template guide](guide_release-notes.md).
+
+## Examples of release notes
+
+The following high-quality examples of release notes inspired this template and can help you see examples of effective release notes in action:
+
+* [Deputy: What's New](https://whatsnew.deputy.com/): Efficiently highlights recent features and improvements with clear categories and visuals, making updates easy to understand at a glance.
+* [Jira Software release notes](https://confluence.atlassian.com/jirasoftware/jira-software-release-notes-776821069.html): Provides an organized overview of new features, fixes, and updates across Jira versions, helping users track platform changes, stability improvements, and compatibility adjustments.
+* [Notion: What's New](https://www.notion.so/releases): Provides an organized, straightforward layout, making it easy for users to quickly view recent updates and feature improvements.
+* [Spotify for Backstage release notes](https://backstage.spotify.com/release-notes/): Has a simple, straightforward developer-focused design focused purely on functionality, allowing users to quickly absorb updates and improvements without unnecessary embellishments.
+
+## Resources
+
+* [Boost your software launch: top release notes checklist](https://www.manifest.ly/use-cases/software-development/release-notes-checklist): A checklist to ensure thorough, impactful release notes.
+* [How to write excellent release notes](https://www.aha.io/roadmapping/guide/launch/how-to-write-excellent-release-notes): Key tips for crafting clear, user-friendly release notes.
+* [How to write release notes](https://ffeathers.wordpress.com/2017/08/19/how-to-write-release-notes/): A guide on structuring effective and engaging release notes.
+* [The art of writing great release notes](https://uxdesign.cc/the-art-of-writing-great-release-notes-6607e22efae1): A guide for making release notes clear, user-focused, and concise, with a balance of technical accuracy and relatable language to keep users engaged and informed.
+* [What are release notes and why do you need them?](https://www.featurebase.app/blog/release-notes) Explanation of the purpose and value of prioritizing well-crafted release notes.
+
+## 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 | Description |
+| :---- | :---- |
+| Frill: [How to Write Release Notes: 23 Tips, Tools, and Examples](https://frill.co/blog/posts/how-to-write-release-notes) | Provides actionable tips and examples for writing clear, user-focused release notes, with guidance on structure, tone, and distribution strategies. |
+| Frill: [15 Release Notes Best Practices to Drive Usage \[+ Examples\]](https://frill.co/blog/posts/release-notes-best-practices) | Outlines 15 best practices for writing clear, user-focused release notes that drive feature adoption, emphasizing actionable language, visuals, and user feedback. |
+| Product Plan: [How to Write Release Notes Your Users Will Actually Read](https://www.productplan.com/learn/release-notes-best-practices/) | Highlights best practices for crafting release notes that are user-friendly and engaging, focusing on clarity, concise language, and brand alignment |
+| Slite: [The art of writing great release notes](https://slite.com/learn/release-notes) | Provides best practices for creating concise, user-friendly release notes that engage readers, avoid jargon, and enhance brand experience |
+| User Guiding: [13 Examples of Release Notes Users Enjoy Reading](https://userguiding.com/blog/release-note-examples) | Presents 13 release note examples that prioritize clarity and user engagement, using visuals and creative formatting to improve readability and appeal. |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Release%20notes%20resources) to give feedback.
diff --git a/meta/reference/good-docs-project-template-1.5.0/release-notes/template_release-notes.md b/meta/reference/good-docs-project-template-1.5.0/release-notes/template_release-notes.md
new file mode 100644
index 00000000..fc1d77cd
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/release-notes/template_release-notes.md
@@ -0,0 +1,90 @@
+# Release notes - {Product name} {Release number - 0.0.0}
+
+> 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.
+
+{If you need more information about how to fill in this template, read the accompanying [Release notes process](process_release-notes.md) document}
+
+{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.}
+
+{Optional: Release notes version - 0}
+
+{Release date - YYYY-MM-DD}
+
+{Optional: High-level summary}
+
+## New features
+
+* **{Feature name}**
+
+   {Feature description}
+
+**Example:**
+
+* **Feature name**: We've introduced a new {feature} that allows users to {benefit or function}. This will help you {specific use case}.
+* **Feature name**: With this release, you can now {describe new functionality}, giving you greater control over {specific area}.
+
+## New features requiring configuration updates
+
+* **{Feature name}**
+
+   {Feature description}
+
+**Example:**
+
+* **Feature name**: We've introduced a new {feature} that requires activating a configuration update. This feature allows users to {benefit or function}, improving {specific use case}.
+* **Feature name**: With this release, you can now {describe new functionality}, but it requires updating your configuration settings. This gives you greater control over {specific area}.
+
+## Improvements
+
+* **{Improvement title}**
+
+   {Improvement description}
+
+**Example:**
+
+* **Enhanced functionality**: We've improved the speed of {specific feature}, reducing the time it takes to complete {task} by {X%}.
+* **Improved usability**: The {feature} has been redesigned for easier navigation, allowing you to {do something specific} with fewer clicks.
+
+## API/Web service updates
+
+* **{API/Web service update}**
+
+   {Update description}
+
+## Bug fixes
+
+* **{Bug fix title}**
+
+   {Bug fix description}
+
+**Example:**
+
+* **Fixed issue where {problem}**: Resolved an issue where {specific behavior} caused {impact}. Users will now experience {improved behavior}.
+* **Addressed crash during {specific task}**: A crash that occurred when {scenario} has been fixed, ensuring smoother operation.
+
+### Known issues
+
+* **{Known issue title}**
+
+   {Known issue description}
+
+**Example:**
+
+* **Issue name**: We are aware of an issue with {feature}, which may cause {specific issue}. Our team is actively working on a resolution, and we expect to include a fix in the next release.
+
+## Optional: Deprecation notice
+
+* **{Deprecated feature name}**
+
+   {Deprecated feature description}
+
+### Examples
+
+* **Feature name:** The {feature name} functionality has been deprecated as of this release. This feature will no longer be supported after {specific date}, as we have introduced {alternative feature or explanation of why it's no longer needed}. We recommend transitioning to {alternative solution}.
+* **Outdated functionality:** Support for {specific feature or integration} is deprecated in this release due to {reason, such as redundancy or incompatibility with new systems}. For continued use, please explore {alternative solution or updated approach}.
+* **Retired tool:** The {tool name} is being deprecated with this update. This tool will be phased out by {date}. Please migrate to {replacement tool or workflow}, which offers improved {specific benefit or functionality}.
+* **API change:** The {API endpoint name} is deprecated as of this release. This endpoint will no longer accept requests after {deprecation date}. Users should update their applications to use {new API endpoint or method}, which supports {enhanced functionality or feature}.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Release%20notes%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/style-guide/guide_style-guide.md b/meta/reference/good-docs-project-template-1.5.0/style-guide/guide_style-guide.md
new file mode 100644
index 00000000..793ebfb6
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/style-guide/guide_style-guide.md
@@ -0,0 +1,188 @@
+# The style 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).
+
+## When do I need a 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.
+
+A style guide can provide early guidance to new contributors as they make
+decisions related to your project's documentation. Contributors often have to
+make subjective decisions about the documentation, such as:
+
+* Which style guide your project will defer to as its default style guide
+* How to refer to terms that are unique or specific to that project
+* How to format certain types of content
+* What tone, attitude, or level of formality you recommend using in the project
+  (usually conveyed through word choice)
+* Any specific rules you want to highlight for documentation contributors, such
+  as language usage disputes that seem to arise periodically within the
+  community
+
+A style guide provides your project's answers to these questions and ensures
+that all of the contributors are working from the same common understanding.
+
+## How to make a style guide scale with your project
+
+A project's style guide usually starts out as a stub at the beginning of a
+project. For example, it might simply indicate which style guide is your
+project's default guide, such as the Google developer documentation style guide
+or the Microsoft Style Guide. It might link to specific elements from the default
+guide that are most relevant to your project or point out any exceptions to the
+default guide.
+
+As your project grows and matures, your style guide can grow along with it. For
+example, debates can (and will) arise about how to refer to a specific term in
+the documentation, such as whether to capitalize or hyphenate a term that is
+unique to the project. Once resolved, you can capture decisions in the style
+guide. Then, if that debate arises again, you can simply refer contributors to
+your style guide rather than rehashing the same debate every time a new
+contributor joins the project.
+
+However, keep in mind that some teams consistently struggle to maintain a style
+guide over time. The guiding principle here is that a small amount of work up
+front can save a lot more work later. It's much easier to set your standards in
+a style guide early in your project's life cycle than it is to retroactively
+clean up your documentation later when the project is more mature. With small
+but regular updates, your style guide can evolve alongside your project. It will
+help your contributors get up to speed quickly and start writing high quality
+documentation.
+
+To help your project scale, consider setting a recurring meeting or agenda item
+to review the style guide and address style guide issues on a periodic basis
+(such as once a month). Perhaps you could make someone on the team the project
+owner for the style guide to ensure someone has the responsibility to update the
+guide after style guide reviews.
+
+## Content of your style guide
+
+### About the "Introduction" section
+
+In this section, briefly introduce the purpose of the style guide and how
+you intend to use this style guide in your project. Feel free to adapt this
+content. If desired, you can briefly elaborate on the goals or mission of your
+project's documentation.
+
+### About the "Intended audience and scope" section
+
+Use this section to indicate who should use this style guide. Describe your
+audience for the style guide, which includes all the people who write your
+documentation. You will know them best. They typically will include software
+engineers, product mangers, and tech writers. You can also indicate the
+scope of the style guide if it should include more than just your project's
+documentation.
+
+### About the "Our preferred style guide" section
+
+Maintenance of a style guide is a lot of work. Try to do as little of it as
+possible by deferring to a more comprehensive default guide, such as the Google
+developer documentation style guide or the Microsoft Style Guide. In this
+section, you should indicate which guide is your default guide and reference the
+source document and its version. Document any exceptions where your style guide
+differs from your default guide.
+
+Also, if your project already has existing brand guidelines, you can link to
+them or include them here.
+
+## About the "Glossary of preferred terms" section
+
+Every project has its own unique terms and buzzwords and this glossary can help
+you record your project's preferred terms. This word list provides a list of
+specific terms that are either common word choice problems or which are unique
+to your project. As a word of caution, try to minimize jargon and buzzwords.
+Also, avoid creating too many project-specific terms. Where possible, use the
+terms that are standard for your industry to avoid confusion. Ideally, you can
+inherit or defer to term definitions from a more authoritative glossary source.
+
+This section includes a table to highlight terms that are unique to your project,
+or which conflict with your default style guide. For example, the Google
+developer documentation guide uses "open source" but our project prefers
+"open-source" when used as an adjective, as in "open-source software."
+
+## About the "Topic types and templates" section
+
+The Good Docs project provides templates for various types of topics that you
+can adopt in your project. Depending on the type of project you're creating,
+some of the Good Docs templates will be more relevant than others. In this
+section, you can link to the templates you have adopted for your project. You
+can also explain when contributors should use these templates.
+
+## About the "General writing tips" section
+
+This section is optional. You can link to your favorite general writing tips or
+add some of your own general guidelines.
+
+## About the "Accessible writing" section
+
+In this section, you can link to your preferred style guides about accessible
+writing or add some of your own general guidelines.
+
+## About the "Inclusive and bias-free writing" section
+
+In this section, you can link to your favorite resources about inclusive and
+bias-free writing or add some of your own general guidelines.
+
+## About the "Using linters" section
+
+This section is optional. [Linters](https://www.writethedocs.org/guide/tools/testing/#style-guide_checking-and-linting)
+are tools that analyze text content to flag common mistakes such as stylistic
+errors and suspicious constructs. An example of a linter would be a tool like
+Grammarly that processes your text and provides suggestions as you write to
+improve the spelling and grammatical structure of the text.
+
+Linters can be used during the editorial process within a text editor and as a
+post-processing test of the content when the document is pushed into a revision
+management system as part of an automated continuous integration (CI) cycle.
+
+If you want to take your style guide to the next level, you could adopt a linter
+to enforce your style guide and empower your content creators to make better
+documentation with less cognitive overhead.
+
+For resources and examples of linters, see:
+
+* [The `linter-google-styleguide` package for the Atom text editor](https://atom.io/packages/linter-google-styleguide)
+* A tool like [Vale](https://www.writethedocs.org/guide/tools/testing/#vale),
+  which can automate [several popular styles](https://github.com/errata-ai/styles)
+* The [Alex](https://alexjs.com/) linter can check for insensitive and
+  inconsiderate writing.
+
+## About the "How the style guide is updated" section
+
+Indicate here how frequently your style guide is reviewed, who owns the style
+guide, and how contributors can provide feedback on your style guide. For
+example, you could provide the contact information for the group or individual
+who owns the style guide. You could also indicate when the style guide is
+reviewed in project meetings.
+
+If this section is small enough, you can combine it with the following sections.
+
+## About the "Revision history" section
+
+This section is optional. You can use this section to provide a changelog or
+decision log of changes to your project's style guide. You can also link out to
+other project documents that contain your decision log. You could also use this
+section to provide guidelines about how to request changes to the style guide
+and outline how often decisions can be revisited (such as after a year).
+
+To choose the edition number for the style guide, consider using the
+Major.Minor.Patch numbering system outlined in
+[Semantic Versioning 2.0.0](https://semver.org/). When these
+guidelines are applied to documents, you typically use 0.1 through 0.9 for
+drafts. After the first release of the document, switch to 1.0. For major
+revisions, increase the version by a full numeral such as 2.0. For minor
+revisions, add a decimal, such as 1.1.
+
+## About the "Decision log" section
+
+This section is optional. Various project managers, sponsors, and teams make a
+lot of decisions while working on a project long-term. A decision log can track
+the decisions you've agreed upon. A decision log lists the key decisions made on
+the project. If your project has a separate decision log, you can link to it or
+provide one here.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Style%20guide%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/style-guide/template_style-guide.md b/meta/reference/good-docs-project-template-1.5.0/style-guide/template_style-guide.md
new file mode 100644
index 00000000..95b9bc26
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/style-guide/template_style-guide.md
@@ -0,0 +1,148 @@
+
+# {Your Project Name} style guide
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_style-guide.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.
+
+{Version number and last updated date}
+
+## Introduction
+
+{Before using this template, please read the accompanying About the Style Guide
+Template documentation.}
+
+Welcome to our project! This style guide is intended for use by project
+contributors, not necessarily end-users. It provides general guidance to anyone
+who contributes to the project's documentation.
+
+## Intended audience and scope
+
+This style guide is intended for use by any contributors that are writing
+documentation for {Your Project Name}, including software engineers. This guide
+can help project contributors to communicate clearly and consistently in {you
+define the scope: the project's end-user documentation, API documentation,
+forum posts, and so forth.}
+
+## Our preferred style guide
+
+We have adopted the
+{[your preferred style guide, such as the Google developer documentation style guide](https://developers.google.com/style)}
+for {Your Project} documentation. For a quick summary, see the
+[Google style guide highlights](https://developers.google.com/style/highlights).
+The rest of this document describes our project-specific customizations to
+{Google's or your preferred} guide.
+
+Our project uses {your choice: standard American spelling or standard British
+spelling, etc.} and our preferred dictionary is the
+{[American Heritage Dictionary](https://ahdictionary.com/) or your preferred
+dictionary}.
+
+When writing documentation for our project, align with the default guide's
+voice and tone.
+
+## Glossary of preferred terms
+
+{Calling out how to write your project name first is optional. You can choose to include your project name in the word list instead.}
+
+This {Your Project Name} is represented as {example}. It is {always/never}
+capitalized.
+
+The table provides guidelines about the terms you should and should not use for
+consistency, listed in alphabetical order:
+
+Preferred Term  | Avoid These Terms  |  Explanation
+--------------- | -----------------  |  -----------
+for example     | e.g.              |  Avoid non-English words
+people with disabilities  | 
    • the disabled
    • disabled people
    • people with handicaps
    • the handicapped
      |  Use inclusive and bias-free language. See [Accessible Writing](#accessible-writing)
+that is         |  i.e.             |  Avoid non-English words
+
+## Topic types and templates
+
+This project recommends using the following templates from the
+[Good Docs project](https://github.com/thegooddocsproject/templates):
+
+* API Overview
+* API Quickstart
+* API Reference
+* Discussion Article
+* How To Guide
+* Logging Article
+* Reference Article
+* Tutorial
+
+## General writing tips
+
+{This section is optional.}
+
+For some general tips about improving writing see:
+
+* [Write the Docs - Style Guides](https://www.writethedocs.org/guide/writing/style-guides/#writing-style)
+* [18F Content Guide](https://content-guide.18f.gov/)
+
+## Accessible writing
+
+Documentation should be written in a way that supports people with disabilities
+and users with various input methods and devices. Improving accessibility also
+helps make documentation clearer and more useful for everyone.
+
+For resources on making your writing more accessible, see:
+
+* [Writing accessible documentation - Google developer documentation style guide](https://developers.google.com/style/accessibility)
+* [Accessibility guidelines and requirements - Microsoft Writing Style Guide](https://docs.microsoft.com/en-us/style-guide/accessibility/accessibility-guidelines-requirements)
+* [Writing for Accessibility - Mailchimp Content Style Guide](https://styleguide.mailchimp.com/writing-for-accessibility/)
+
+## Inclusive and bias-free writing
+
+When contributing to this project, you should strive to write documentation with
+inclusivity and diversity in mind. Inclusive language recognizes diversity and
+strives to communicate respectfully to all people. This kind of language is
+sensitive to differences and seeks to promote equal opportunities.
+
+For resources on making your writing more inclusive, see:
+
+* [Inclusive documentation - Google developer documentation style guide](https://developers.google.com/style/inclusive-documentation)
+* [The Conscious Style Guide - a collection of resources](https://consciousstyleguide.com/)
+* [Bias-free communication - Microsoft Writing Style Guide](https://docs.microsoft.com/en-us/style-guide/bias-free-communication)
+* [Guidelines for Inclusive Language - Linguistic Society of America](https://www.linguisticsociety.org/resource/guidelines-inclusive-language)
+
+## Using linters
+
+{This section is optional.}
+
+This project uses the {your preferred linter.}
+
+{Provide instructions or policies related to the linter here.}
+
+## How the style guide is updated
+
+{Indicate here how frequently your style guide is reviewed, who owns the style
+guide, and how contributors can provide feedback on your style guide.}
+
+## Revision history
+
+{This section is optional or can be combined with the next section if needed.}
+
+The following table describes the history of all decisions and revisions made to
+this style guide over time. This guide uses the Major.Minor.Patch
+[semantic versioning](https://semver.org/) convention.
+
+Edition  |  Date          |  Lead Author(s)    |  Link to Repository Commit/Tag
+-------  |  ----          |  --------------    |  -----------------------------
+{0.1}    |  {YYYY-MM-DD}  |  {Your name here}  |  First draft of Style Guide
+
+## Decision log
+
+{This section is optional or can be combined with the previous section if
+needed.}
+
+The following table describes the history of all decisions made to this style
+guide over time:
+
+Ref  |  Date         |  Description                               |  Agreed to by
+---  |  ----         |  -----------                               |  ------------
+1    | {YYYY-MM-DD}  |  {Explain the decision that was made here} |  {Name or role}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Style%20guide%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/template_deliverables.md b/meta/reference/good-docs-project-template-1.5.0/template_deliverables.md
new file mode 100644
index 00000000..50acfa69
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/template_deliverables.md
@@ -0,0 +1,167 @@
+# Template deliverables
+
+This document explains the different file deliverables that template authors are required to write as part of each template project. First, read our [Template Contributing Guide](CONTRIBUTING.md) to understand the larger context for these deliverables.
+
+## Table of contents
+
+[TOC]
+
+## Overview of each file
+
+Currently, for a template project to be considered complete, each template project should have these documentation deliverables:
+
+
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+
    DeliverableExample filename and purposeUse case
    Template filetemplate_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 guideguide_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!"
    Resourcesresources_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."
    Processprocess_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."
    Exampleexample_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."
    
+
+Each template deliverable is explained in the following sections.
+
+## Template file
+
+Example filename: template_content-type.md
+
+The template file is the basic template for the type of document you are creating.
+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.
+The template user will copy this template and begin filling it in or editing it as their starting point in the writing process.
+
+### Content and formatting guidelines
+
+Each template should have this content:
+
+* **The template title** - The type of document this template is for. For example, "Tutorial template" or "README template."" This title should be formatted with the heading 1 weight.
+* **Introductory comment** - Include an embedded writing tip at the start that tells users they should first read the accompanying template guide before they fill in the template. Put introductory comments in {curly brackets}.
+* **The template sections** - Each section of the template should begin with a heading with the heading 2 weight. The recommended content and some embedded writing tips fall under the headings.
+* **Embedded writing tips** - You can provide some lightweight writing tips that provide some tips or hints about what kind of content the template user might choose to put in a section of the document. Put embedded writing tips in {curly brackets}.
+
+> :triangular_flag_on_post: **NOTE: The basic content of the template depends on the type of document you are creating a template for. Different types of documents can have widely varying content needs. While similar document types are likely to require similar structures, other document types may be structured quite differently.**
+
+### Frequently asked questions
+
+**Q: Is it better to include all the possible sections that someone could possibly include in the template file or should it just have the most common sections?**
+
+A: While this is mostly a judgment call on your part as the template author, it might be better to err on the side of being comprehensive.
+Don't forget that in your template guide you can indicate whether it is common or recommended to include this section or not.
+
+**Q: Can I use heading 3 weights for sub-sections?**
+
+A: Yes, but try not to go much deeper than level 3.
+
+## Template guide
+
+Example filename: 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.
+
+This guide explains the key decisions that the template user needs to make during the writing process.
+
+This guide might also optionally include a checklist of the required components for this type of document.
+
+### Content and formatting guidelines
+
+The template guide should follow the same basic structure:
+
+* **Template guide title** - The type of document this template is for and the words "guide." For example, "Tutorial guide" or "README guide." This title should be formatted with the heading 1 weight.
+* **Introductory comment** - Include an embedded writing tip at the start that tells users they should first read this guide before they fill in the template. This comment could also mention how to get the template file. Put introductory comments in {curly brackets}.
+* **Why do I need this type of document?** - Provide some of the information about the purpose of this type of document and how it helps your documentation project. The header for this section should be formatted with the heading 2 weight.
+* **Content of this template** - This header marks the beginning of the part of the guide that explains how to fill in each section of the guide. It should be formatted with the heading 2 weight.
+* **About the {insert section name here} section** - Next, include each section as they appear in the template with the heading 3 weight. For example, if your template includes a "Before you start" section, this heading should say "About the before your start section." And then it should provide guidance about what kind of content goes in that section and why that section might be included in the final document. If the section is optional, indicate why some documents could benefit from that section or why it might be left out. If the template user needs to make a decision about the content in that section, provide guidance about what should go into that section.
+
+### Frequently asked questions
+
+Q: No questions yet.
+
+## Resources
+
+Example filename: 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.
+
+The resources file has a number of advantages:
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
    For the projectIt gives The Good Docs Project a way to ethically cite our sources and give credit where credit is due.
    For the template contributorIt 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 documentIt 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 maintainersThis 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).
    
+
+### Content and formatting guidelines
+
+Each resource file should have the following sections:
+
+* **Template title resources** - The type of document this template is for + "resources". For example, "Tutorial resources" or "README resources." This title should be formatted with the heading 1 weight.
+* **Sources consulted** - Include a bulleted list or table of the sources you consulted while researching this template. Include a link and/or full citation so that others can find it. Explain how that source influenced the design decisions in your template.
+* **Examples** - Include a bulleted list or table of the examples that served as inspiration for your template. Include a link and/or full citation so that others can find it.
+
+### Frequently asked questions
+
+Q: No questions yet.
+
+## Process
+
+Example filename: 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.
+
+### Content and formatting guidelines
+
+Each resource file should have the following sections:
+
+* **Template title process** - The type of document this template is for + "process". For example, "Tutorial process" or "README process." This title should be formatted with the heading 1 weight.
+* **Researching "content type"** - Explain best practices for researching this content type.
+* **Writing "content type"** - Explain recommendations for writing this content type.
+* **Maintaining "content type** - Explain best practices for maintaining this content type over time, such as evaluating its effectiveness and keeping it up to date. It can also include knowing when to archive that content type if appropriate.
+
+### Frequently asked questions
+
+Q: No questions yet.
+
+## Template example (optional)
+
+Example filename: example_content.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.
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.csv b/meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.csv
new file mode 100644
index 00000000..66fc5d93
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.csv
@@ -0,0 +1,15 @@
+Term,Definition,Alternative terms,Rejected terms,Related terms,Part of speech,Source,Notes for translation and localization,Do not translate,Updated on,Description of update
+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.",ACL,,,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.",,
+"allowlist, allow list",,,"* whitelist
+* white list",denylist,Noun,,,,,
+application programming interface,A set of definitions and protocols for building and integrating application software.,API,,,Noun,,,"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.",,
+autoscaling,Adding or removing computing resources to account for processing load.,,,,Noun,,,,,
+binary large objects,,BLOBs,blobs,,Noun,,," SharePoint Storage Manager manages content database growth in SharePoint by storing Binary Large Objects (BLOBs) in a BLOB storage location, leaving only the corresponding metadata in the content database. ",,
+"denylist, deny list",,,"* blacklist, blocklist
+* black list, block list""",allowlist,Noun,,,,,
+box,A text box in a UI.,,"* field
+* spin box",,Noun,,,"In the User Name box, type the Active Directory user account.",,
+command line interface,"A form of interface between the operating system and the user in which the user types commands, using a special command language.",,"* command-line interface
+* Command Line Interface",,Noun,Microsoft Language Portal,,The script can later be executed from the [command line interface].,,
+air-gapped,a physically isolated computer from unsecured networks,,,,Noun,,,,,
+application programming interface,"An API specifies how software components can be interacted with programmatically. Veritone's primary application programming interface (API) is a GraphQL interface. It can be accessed just like other HTTP APIs (e.g., REST) with POST requests.","API, after first ref in each doc",,,Noun,,"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.",,,
\ No newline at end of file
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.htm b/meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.htm
new file mode 100644
index 00000000..6643ec23
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/example_terminology-system.htm
@@ -0,0 +1,104 @@
+
+
+
+
+
    Terminology system for MyProject
    
+
+
    This is example for a terminology system.
    
+
+
+	
+		
+			
+			
+			
+			
+			
+			
+			
+		
+	
+	
+		
+			
+			
+			
+			
+			
+			
+			
+		
+		
+			
+			
+			
+			
+			
+			
+			
+		
+        
+			
+			
+			
+			
+			
+			
+			
+		
+        
+			
+			
+			
+			
+			
+			
+			
+		
+        
+			
+			
+			
+			
+			
+			
+			
+		
+	
+
    TermDefinitionUsagePart of speechSourceNotes for translation and localizationUpdates
    access control listAn 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.
+			
      
+				
    • Alternative terms: ACL
      • 
+
+			
    
+			    		NounWikipedia.orgWhen 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 lista list with allowed values
+			
      
+				
    • Rejected terms: whitelist, white list
      • 
+
    • Related terms: denylist, deny list
      • 
+			
    
+			    		NounWikipedia.orgN/A
+			N/A
+			
    application programming interfaceA set of definitions and protocols for building and integrating application software.
+			
      
+					
    • Alternative terms: API
      • 
+			
    
+			    		NounWikipedia.orgRepresentational 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 lista list of not approved values
+			
      
+					
    • Rejected terms:blacklist, blocklist, black list, block list
      • 
+                    
    • Related terms: allowlist
      • 
+			
    
+			    		NounN/AN/A
+			N/A
+			
    text boxA text box in a UI
+			
      
+                    
    • Related terms: field
      • 
+			
    
+			    		NounN/AIn 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)
+			
    
+
+
+
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/guide_terminology-system.md b/meta/reference/good-docs-project-template-1.5.0/terminology-system/guide_terminology-system.md
new file mode 100644
index 00000000..a2003c61
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/guide_terminology-system.md
@@ -0,0 +1,181 @@
+# Terminology system 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
+
+A terminology system is the collection of terms that defines a common language for a project:
+
+* Terms that can be used and terms that cannot be used
+* The definition of the term
+* Alternative terms
+* Abbreviations and acronyms
+* The origin or source of information
+* Tips for translation and localization
+* Classification
+* Taxonomy designed to be shared among users
+
+A well-defined terminology system reduces ambiguity and increases clarity, which is a crucial factor in communicating the project to the audience.
+
+## Terminology system vs. glossary
+
+The scope of a terminology system is broader than that of a glossary, which contains a simple list of terms, abbreviations, and definitions.
+If you want to use the glossary template, [see the glossary template](https://gitlab.com/tgdp/templates/-/tree/main/glossary).
+
+To help you decide if your project should have a glossary or a terminology system, consider how much information you need to attach to each term.
+
+Use a glossary when you need a simple way of defining terms, acronyms, and abbreviations for your project.
+Use a terminology system if you have a more complex use case that requires more information than what a glossary has, which is typically the following:
+
+* Term
+* Definition
+* Abbreviations
+* Acronyms
+
+The table below identifies the differences between the two.
+
+
+  
+   
+   
+  
+  
+   
+   
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
    GlossaryTerminology 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:
+    
      
+      
    • Terms that can be used
      • 
+      
    • The definition of the term
      • 
+      
    • Terms that cannot be used
      • 
+      
    • Alternative terms
      • 
+      
    • Abbreviations and acronyms
      • 
+      
    • Provenance
      • 
+      
    • Tips for translation and localization
      • 
+      
    • Classification
      • 
+      
    • Taxonomy designed to be shared among users.
      • 
+    
    
+   
    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:
+    
      
+      
    • Notes for translation or localization of the term
      • 
+      
    • Alternate terms
      • 
+      
    • Related terms that cannot or should not be used
      • 
+      
    • Source information for the term
      • 
+    
    
+    
    A list of terms created by one entity, intended for use by a specific audience.
+    Examples:
+    
      
+    
    • An internal company glossary used to onboard a new hire.
      • 
+    
    • A public glossary for users of a specific software defining terms used in the software's documentation.
      • 
+    
    
+        		A list of terms shared between multiple entities or organizations, requiring information relevant to each.
+      Examples:
+      
      
+        
    • Terms shared between multiple countries, requiring translation information for each term
      • 
+        
    • Terms shared by multiple agencies working in related fields
      • 
+        
    • Terms used mostly internally by a content team rather than something that is shared with users
      • 
+      
    
+    
    
+
+## When do I need a terminology system?
+
+Create a terminology system for a project whenever you want to cover the following use cases:
+
+* To define terms in a project.
+Terms for which people need an introduction either because they are new or because the definition needs to be specific.
+* To redefine or disambiguate (clarify) a term in a project.
+The term is not new, but the project uses the term with a specific connotation, or the same term is used slightly differently across different groups or industries.
+Take the word 'client', for example.
+The IT department might be referring to the client/server architecture, but the marketing department is referring to a customer.
+* To provide alternative terms like abbreviations and acronyms.
+* To provide a list of rejected terms.
+If the rejected term had been used in the past, but the terminology evolved and the rejected term cannot appear in the documentation anymore, or if the rejected term is now considered non-inclusive.
+* To provide context for translation and localization.
+* To provide information about the source of the term or its definitions, for provenance.
+* To establish the part of speech in which the term can be used, to allow or disallow the use of a product name as a verb.
+For example, 'Slack' can be used as a noun, but can't be used as a verb, so 'I'll Slack you.' is not allowed.
+* To capture possible modifications of the term, the list of metadata fields captured, and/or governance.
+These use cases for a terminology system help your project to maintain the glossary over time, as well as retaining the changes to the terminology system or workflows over time.
+* To program a linter or quality checker.
+* To share glossaries across multiple projects.
+
+## Content of the terminology system template
+
+A table is the best structure to capture a terminology system, where each column contains the following content.
+For a populated example of a terminology system, see [example_terminology.csv](/terminology-system/example_terminology-system.csv).
+
+### About the "Term" column
+
+The term that users see in the documentation.
+In most cases, use the preferred term name.
+
+### About the "Definition" column
+
+The definition of the term as it is used by the documentation of the project.
+
+### About the "Usage" column
+
+A bullet list that specifies how to use the term considering the following:
+
+* Alternatives
+* Prohibitions
+* Relationship to other terms that might add knowledge value
+
+#### About the "Alternative terms" item
+
+Acronyms or abbreviations that can be used in place of the preferred term.
+List any acceptable acronyms or abbreviations that can be used in place of the preferred term, for example, if a team uses 'CompAid' or 'C-AIDED' in place of the term computer-aided for the documentation.
+To list acceptable terms, use an inline list.
+
+#### About the "Rejected terms" item
+
+Terms that the documentation should never use for this definition.
+To list rejected terms, use an inline list.
+
+#### About the "Related terms" item
+
+Terms that are conceptually related to the definition, and that are also in the terminology system.
+To list related terms, use an inline list.
+
+### About the "Part of speech" column
+
+The part of speech for this term entry.
+You can include more than just the simple list of what part of speech it is, for example, you can include an explanation that the term should only be used as a noun and never a verb.
+
+### About the "Source" column
+
+The source of the definition of this term.
+The field might be helpful in audits or for versioning.
+
+### About the "Notes for translation and localization" column
+
+The information that might need to be considered if translating or localizing the term is not straightforward.
+Alternatively, include an example sentence that might help translators.
+If translating is not recommended, use a bold note labeled "Do not translate".
+
+### About the "Updates" column
+
+A bulleted list with an information pair date and reason.
+
+#### About the "Date" item
+
+If the term, definition, or other column information changes, then this column can track the change.
+Use a date format.
+
+### About the "Reason" item
+
+Describe the reason for the update.
+
+Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates).
+Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Terminology%20system%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/process_terminology-system.md b/meta/reference/good-docs-project-template-1.5.0/terminology-system/process_terminology-system.md
new file mode 100644
index 00000000..285a27ca
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/process_terminology-system.md
@@ -0,0 +1,34 @@
+# Terminology system 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+This document explains best practices for researching, writing, and maintaining a terminology system.
+
+## Researching a terminology system
+
+To create a terminology system, the following tasks are typically perfomed.
+
+* Gathering of terms that you want to define
+* Redefinition of terms in case terms needs tuning for a particular use case
+* Disambiguation of terms
+* Rejection of terms that you do not want people to use
+* Gathering of alternative terms, including acronyms and abbreviations
+* Collection of for translation and localization aids
+* Establishment of the part of speech that term can be used
+* Collection of updates that the term has had, if that is important for your case
+Terms might be spread out in different documents and might be conflicting. It might take some time to get people to agree on a term, plan for that time.
+
+## Writing a terminology system
+
+Identify who the stakeholeders are: who needs to agree upon the terms and who needs buy-in and alignment about the terms? Who signs off on them and gives final approval?
+If your project has many working groups, make sure that terms and the definitions are discussed and agreed across all stakeholders. For example, an image might be referred to as 'visual aid' in the public website, yet, because of legacy reasons, an image is referred to as a .jpg file in the storage group.
+Terms might be spread out in different documents and might be conflicting. It might take some time to get people to agree on a term, plan for that time.
+
+## Maintaining a terminology system
+
+A terminology system will evolve over time. New terms are created, some terms get obsolete, products change names, just as it happens with the language we speak.
+To maintain a terminology system currently, plan for periodical reviews and timely updates. When new terms are introduced, updated, or archived, make sure to announce the changes internally and externally.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Terminology%20system%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/resources_terminology-system.md b/meta/reference/good-docs-project-template-1.5.0/terminology-system/resources_terminology-system.md
new file mode 100644
index 00000000..c088d7fb
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/resources_terminology-system.md
@@ -0,0 +1,33 @@
+# Terminology system 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+## Examples of terminology systems
+
+* Go to the Microsoft Learn site and select 'Microsoft terminology search'. [Microsoft Terminology Search](https://learn.microsoft.com/en-us/globalization/reference/microsoft-terminology#microsoft-terminology-1)
+
+* For an example of terminology system that aims to clarify and standardize the essential concepts and terminology used within the field of terminology science, go to [The Termterm project](https://termterm.kaleidoscope.online/dashboard).
+
+* For an example of a terminology system with bullet list entries, go to [ISO website](https://www.iso.org/obp/ui/en/#iso:std:iso:704:ed-4:v1:en).
+
+## Sources consulted
+
+* For information about 'term, part of speech, terminology', see [Terminology management](https://writer.com/guides/terminology-management/).
+
+* For columns related to localization and translation, see [Terminology management what you should know](https://www.atanet.org/growing-your-career/terminology-management-what-you-should-know/).
+
+* For information about how to create a terminology system, see [How to create a Glossary or Terminology Database](https://quicksilvertranslate.com/5546/terminology-database/).
+
+* For information about how terminology systems could evolve, go to the Good Docs Project website and on the top menu select Glossaries.
+
+* For an explanation about the differences and similarities of the terms 'term' and 'word', and 'glossary' and 'term base', see [What you need to know to get started with terminology management](https://www.rws.com/blog/what-you-need-to-know-to-get-started-with-terminology-management/).
+
+* For a technique to check if a glossary is well-defined, go to the W3C website and search for 'providing a glossary'.
+
+* For for entries in a termbase table, see [terminology management getting started](https://wordbee.com/blog/localization-industry/terminology-management-getting-started/).
+
+* For an article about the importance of having a terminology system, see [What is terminology](https://www.termnet.org/downloads/english/about_us/what_is_terminology_2006_05.pdf).
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Terminology%20system%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.csv b/meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.csv
new file mode 100644
index 00000000..f940606b
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.csv
@@ -0,0 +1 @@
+Term,Definition,Alternative terms,Rejected terms,Related terms,Part of speech,Source,Notes for translation and localization, Do not translate,Updated on,Reason of updated
diff --git a/meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.htm b/meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.htm
new file mode 100644
index 00000000..31087619
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/terminology-system/template_terminology-system.htm
@@ -0,0 +1,43 @@
+
+
+
+
+
    Terminology system
    
+
+
+	
+		
+			
+			
+			
+			
+			
+			
+			
+		
+	
+	
+		
+			
+			
+			
+			
+			
+			
+			
+		
+	
+
    TermDefinitionUsagePart of speechSourceNotes for translation and localizationUpdates
      
+			
      
+				
    • Alternative terms
      • 
+				
    • Rejected terms
      • 
+				
    • Related terms
      • 
+			
    
+			    		   
+			
      
+				
    • Date
      • 
+				
    • Reason
      • 
+			
    
+			
    
+
+
\ No newline at end of file
diff --git a/meta/reference/good-docs-project-template-1.5.0/troubleshooting/guide_troubleshooting.md b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/guide_troubleshooting.md
new file mode 100644
index 00000000..5362f0ed
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/guide_troubleshooting.md
@@ -0,0 +1,62 @@
+# Troubleshooting 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).
+
+## Overview
+
+## When should I include a troubleshooting guide?
+
+Before you and your team decide to create a troubleshooting guide, consider asking yourselves the following questions:
+
+* Is our product intuitive and error-free?
+* Do we have the capacity to complete troubleshooting use cases?
+* Do we have the bandwidth to maintain the troubleshooting guide and ensure its information remains relevant as the product evolves?
+
+If you and your team answered yes to any of these questions, then go right ahead and create a troubleshooting guide.
+
+## Who typically writes a troubleshooting guide?
+
+* Technical writers
+* Subject matter experts (SME), a group of people who are highly knowledgeable in a specific aspect of the software or product
+* Developers
+* Customer support workers
+
+## Where is a troubleshooting guide stored?
+
+This document is typically in a knowledge management system for employees and customers for organizational purposes.
+
+## Before you start
+
+Before you start creating your troubleshooting guide, ensure that you have:
+
+* Tested your solution on all platforms to see if it works
+* Addressed the scenarios the user might be in before they read the guide.
+* Images of code and or error messages. **Note:** Images can be difficult to maintain and can't be copied and pasted to a document, so it's best to take screenshots of relevant parts of the product and avoid using them if the text sufficiently describes the steps.
+
+* Links to other resources that can help solve the problem
+* Symptoms of the problem
+* Solution of the problem
+
+## About the Introduction section
+
+This section should help users understand within a few seconds whether they are reading the right document. Here, you want to describe the problem that users are having. A good example would be, "This article will help you resolve the slow response that often occurs when you turn on your Mac computer".
+
+It's best to place this section at the beginning of your guide so users can get an idea of what they are going to read.
+
+## About the symptoms section
+
+This section should describe the signs that end users should look out for in the problem you are describing. Describe the problem in bullet points to make it easier for users to understand what they should look out for if they experience the problem. More often than not, people are looking for solutions to a specific problem, so we recommend that you put this section after the introduction, describe each symptom as a question via bullet points, and link them to the corresponding issue.
+
+## About the solutions section
+
+For this section, it is best to write the solution(s) in numbered steps. The user will be looking at the instructions while trying to solve the issue, so using this approach would help the person know which number to go back to and avoid missing a step. Additionally, write terms that describe parts of the software in bold to help users understand which part they should use in the step.
+
+## Best practices
+
+* **KISS( Keep It Short & Simple):** Use short and simple explanations. They will make it easier for users to understand how to solve the problems.
+* **Use images:** They provide a visual representation of the instructions needed to achieve the task. **Note:** Images can be difficult to maintain, so it's best to only screenshot the relevant parts of the product. Also, avoid using images if the text sufficiently describes the steps.
+* **Use meaningful headings:** Your users will read your guide from top to bottom or sometimes skip to certain sections (depending on the guide's topic), so the headings will let them know exactly what the section is discussing.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Troubleshooting%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/troubleshooting/process_troubleshooting.md b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/process_troubleshooting.md
new file mode 100644
index 00000000..7f48f79f
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/process_troubleshooting.md
@@ -0,0 +1,35 @@
+# Troubleshooting 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+Thank you for downloading this template from The Good Docs Project! Before you create your troubleshooting guide, 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 Troubleshooting
+
+Your organization's support team play a major role in this step of creating your product's troubleshooting guide. They have the closest relationships with your product's users, so it's important to collaborate with them in creating the content for your guide. Consider using the following strategies to facilitate this process:
+
+* Analyze support tickets and ask one or more of the members of the support team which issues need to be addressed the most. This could be done using a survey, a discussion thread, or through another method your support team prefers.
+* Analyze comments in product's discussion forums and request the support team's advice on which feature needs the most support. This could be done using a survey, a discussion thread, etc.
+* Analyze customer reviews of products and work with the support team to pick the ones that require more attention.
+
+## How to write troubleshooting guides
+
+While making your guide's content easy to read is necessary, you don't want to come off as patronizing to your users. For example, calling the guide "easy to use" or "simple" can make them feel like children, causing them to lose interest in reading. Here are other methods to use when writing your troubleshooting guide:
+
+* Use descriptive headings when describing the symptoms and causes of your issue. Also, place them in chronological order and hyperlink them to make it easier for users to navigate through the guide.
+* Place a brief explanation underneath the cause's heading to help users understand why the symptoms are occurring.
+* Use active voice when describing issues and steps.
+
+## How to maintain troubleshooting guides
+
+Just like in the creation process, your organization's support team's insight is needed to maintain the guide. When comes time to work with this team albeit a discussion thread or a daily meeting, it's highly recommended to use the information mentioned in the [research section](#how-to-research-troubleshooting) of this template and use the following questions to guide the conversation:
+
+* Which steps in the guide need more clarity and/or revision?
+* What information is irrelevant to the current version of the guide?
+* How can we make this guide more interactive?
+It's also helpful to conduct a document review meeting with the support team after a week or two after a release of the document. This would ensure that the document meets the demands of customers, especially the support inquiries has changed.
+Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/) to give feedback on this template.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Troubleshooting%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/troubleshooting/resources_troubleshooting.md b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/resources_troubleshooting.md
new file mode 100644
index 00000000..aa3d4325
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/resources_troubleshooting.md
@@ -0,0 +1,44 @@
+# Troubleshooting 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 GitLab repository](https://gitlab.com/tgdp/templates).
+
+## Examples of Troubleshooting
+
+* **[Troubleshooting guide for iPhone](https://support.apple.com/en-us/HT201569)** - This source describes how to troubleshoot an iPhone that does not charge. The guide provides additional links to other sources Apple users can refer to for additional troubleshooting help, so this method is included in the template.
+* **[Diagnosing the Problem](https://files.support.epson.com/htmldocs/pho22_/pho22_rf/trble_1.htm)** - This is a troubleshooting guide that describes how users can diagnose problems with their Epson printers. This method includes screenshots of how to solve the problem, which can be effective in exemplifying the steps to users, so this method included in the template.
+* **[Getting Started with Nintendo Switch](https://en-americas-support.nintendo.com/app/answers/detail/p/989/c/904/a_id/43021)** - This guide helps users get started with the Nintendo Switch. Its use of interactive questions is helpful, so a similar approach was included in the template.
+
+## 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
+   
    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.
+   
    
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Troubleshooting%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/troubleshooting/template_troubleshooting.md b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/template_troubleshooting.md
new file mode 100644
index 00000000..9e003ce7
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/troubleshooting/template_troubleshooting.md
@@ -0,0 +1,42 @@
+# Troubleshooting {product name, feature, or task}
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_troubleshooting.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.
+
+{Briefly describe the scope of the troubleshooting guide in 1-2 sentences. For example, explain if the troubleshooting guide covers the full scope of the product or a specific task or feature.}
+
+## Symptom 1
+
+{Describe the symptom here. For example, give the text of the error message or describe the performance issue the user might experience.}
+
+### Cause 1 of symptom 1
+
+{If there is only one cause, explain the cause here. If there are multiple causes, list one cause at a time.}
+
+### Solution or workaround to cause 1 of symptom 1
+
+{If there is only one cause, explain the cause here.}
+
+### Cause 2 of symptom 1
+
+{If there is only one cause, explain it here. If there are multiple causes, list one cause at a time.}
+
+{Explain what a successful result to the issue look like.}
+
+{Solution or workaround to cause 2 of symptom 1}
+{If there is only one cause, explain the cause here.}
+
+{Explain the result of the issue when solved.}
+
+### For more information
+
+{Add links to other sources could also aid the user in solving the issue they have with your product, task, or feature}
+
+* [Link](https://example.com/article1.html)
+* [Link](https://example.com/article2.html)
+* [Link](https://example.com/article3.html)
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Troubleshooting%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/tutorial/guide_tutorial.md b/meta/reference/good-docs-project-template-1.5.0/tutorial/guide_tutorial.md
new file mode 100644
index 00000000..d24142cb
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/tutorial/guide_tutorial.md
@@ -0,0 +1,172 @@
+# The tutorial template
+
+> 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).
+
+The tutorial template includes:
+
+* Placeholder text that you can replace with your own text. This text is indicated in {curly braces}.
+* Writing instructions, also in {curly braces}.
+
+## Why do I need tutorials?
+
+Tutorials are integral to helping your users become acquainted with your product. They are learning-oriented and are usually focused on teaching users a specific skill, like debugging a JavaScript application.
+
+Tutorials are often confused with how-to guides because they do help users achieve a specific goal. However, how-to guides assume that your users have some experience with your product or are familiar with certain concepts. They also are usually focused on helping users complete a specific task, like how to add an email account to Microsoft Outlook.
+
+In comparison, tutorials give your users hands-on experience with your product so that they can understand key concepts about your product in a more practical context. Hands-on learning often helps learners gain a deeper understanding of the product by helping them see how they can use a tool to accomplish a task they care about.
+The table below identifies the differences between the two.
+
+| Tutorials                                                                                                                                       | How-to                                                                                                   |
+| ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| Learning oriented                                                                                                                               | Task oriented                                                                                            |
+| Helps beginners or expert users learn a new feature, in a practical way.                                                                       | Helps an expert user accomplish a task or troubleshoot an issue.                                        |
+| Follows a carefully managed path, from the start to the end.                                                                                   | Aims for a successful result, and guides the user along the safest, surest way to the goal.             |
+| Eliminates any unexpected scenarios and provides users with a successful finish.                                                               | Alerts the user to the possibility of unexpected scenarios and provides guidance on how to deal with it. |
+| Assumes that users do not have any practical knowledge and must explicitly state any tools, file configurations, conceptual details, and so on. | Assumes that users have the practical knowledge of tools, file configurations, applications, and so on. |
+
+## Helpful tips when writing your tutorial
+
+* Keep your tutorial focused. If needed, include links to other pieces of documentation that explain concepts or terms in more depth. Ideally, your tutorial should take 15 to 60 minutes to complete.
+* Lengthy tutorials can overwhelm users. Consider condensing or removing steps or reevaluating the scope of the tutorial.
+* If users will copy and paste code samples, make sure they include the following:
+  * Any required `import` or `using` statements
+  * Code comments that explain what the code does
+
+## About the tutorial template
+
+This tutorial can be used in one of two ways:
+
+* For providing a walkthrough of a particular feature.
+* Walking users through completing a small project.
+
+Ideally, your users have already completed a quickstart or "getting started" tutorial and have a general understanding of your product before they begin your tutorial.
+
+### About the "Overview" section
+
+The overview section is important, as it can motivate your users to begin their learning journey with your product and help set them up for success. There are three topics you should cover in this section: learning objectives, intended audience, and any prerequisite background knowledge.
+
+#### Learning objectives
+
+One of the first things users want to know when they begin a tutorial is, "What will I be able to do? What knowledge will I gain by completing this tutorial?" Well-written learning objectives can help to answer these questions. **Learning objectives** describe the specific skills or knowledge users will be able to demonstrate after completing your tutorial.
+
+Before you start writing your tutorial, develop some learning objectives. After you identify *what* skills and knowledge you want users to gain from your tutorial, you can start planning out the content itself, using the learning objectives to help you decide what topics are in scope, and which ones are out of scope.
+
+Learning objectives usually start off with, "By the end of this tutorial, you will be able to..." and are followed by a phrase that starts with a verb like *design*, *assess*, or *develop*. If your tutorial includes more than one learning objective, consider presenting them as a bulleted list.
+
+Here are some examples:
+
+* By the end of this tutorial, you'll be able to define components in React.
+* By the end of this tutorial, you'll be able to perform common tasks in Google Drive, such as viewing, editing, and saving documents.
+* By the end of this tutorial, you'll be able to create a private channel in Slack.
+
+If you need help with creating learning objectives, consider using Arizona State University's [Learning Objectives Builder tool](https://teachonline.asu.edu/objectives-builder/).
+
+#### Intended audience and background knowledge
+
+Before you begin writing your tutorial, you need to think about who you're writing for. The audience will influence the content you include in the tutorial.
+
+It's important to mention the intended audience and any prerequisite knowledge in the overview section. This information helps users determine if the content is appropriate for them.
+
+Here are some questions to think about as you plan your tutorial:
+
+* Is the tutorial intended for users looking to become more familiar with your product? Or is it for users who are already familiar with your product and are looking to build upon the skills they already have?
+* Is the tutorial intended for users with a certain level of technical knowledge? What technical knowledge should they know?
+* Is it for a certain demographic, like senior-level database administrators who routinely complete certain tasks?
+
+### About the "Background" section
+
+The purpose of the background section is to summarize any necessary context for your users before they start your tutorial.
+
+If you're writing a tutorial that's focused on learning how a particular feature works, you might describe that feature here. For example, a tutorial around using Microsoft Visio's templates to build flowcharts might start with an explanation of how flowcharts are used or what flowchart shapes represent.
+
+If you're writing a tutorial where you provide users with a starter project, you could describe the project hierarchy here. For example, a tutorial around building a website with HTML, CSS, and JavaScript might explain how the folders are organized, what code is provided for the user, or what they need to add.
+
+### About the "Before you begin" section
+
+This section helps readers avoid getting halfway through a tutorial and then discovering they don't have something needed to complete. You can use list prerequisites for completing the tutorial, such as operating systems, languages, package managers, or software.
+
+### About the "Steps" section
+
+The steps section is where you describe what the user needs to do to complete the tutorial. The template organizes steps in the following way:
+
+```text
+1. {Write the command here. Start with a verb.}
+
+   {Optional: Explanatory text}
+
+   {Optional: Code sample or screenshot that helps your users complete this step}
+
+   {Optional: Result}
+
+```
+
+The first element is the step itself, like "Enter a name for your new repository." When writing steps, keep these tips in mind:
+
+* Start with an imperative verb. For example, "connect", "set up", or "arrange." Don't use the *-ing* form of the verb because it is harder to translate.
+* Express steps as a complete thought. Instead of saying, "Set up access", you might say, "Set up access to a Cloud Storage bucket."
+
+Next, you may choose to add some additional information about the step. Continuing with the example, you might provide some best practices for creating memorable repository names.
+
+Optionally, you can add a code sample or screenshot after the explanatory text, depending on the type of tutorial you're writing. Screenshots are a great way to show specific parts of the screen you are referring to in a step.
+
+If you're including code samples in your repository, make sure to add comments to your code to help learners understand what each part of the code does. Additionally, make sure your code samples work, as learners will copy and paste your code to use in their own projects.
+
+The last, and optional, element in a step, is the result. Continuing with the example, you might describe what happens after a user clicks the "Create repository" button.
+
+Here is an example step:
+
+```text
+1. Enter a name for your new repository. 
+
+   Good repository names are short and self-explanatory. Avoid repository names with three or more words.
+  
+   After you click "Create repository", GitHub creates your repository and the main page for the repository is displayed.
+```
+
+If needed, you can add substeps below a primary step. Make sure to indent the substep one tab space over if you're using Markdown:
+
+```text
+1. Create a new pull request.
+
+   a. Navigate to the main page of your repository.
+
+   b. Under your repository name, click **Pull requests**.
+
+      By default, all open pull requests are displayed.
+
+   c. ....
+```
+
+If you're including code samples in your steps, make sure they are also indented correctly:
+
+1. Set your Git username for your repository.
+  
+   You can change the name that is associated with your Git commits using the `git config` command.
+
+   ```bash
+   git config user.name "Dakota Everson"
+   ```
+
+#### Tips for writing steps
+
+Here are some more tips to follow when writing procedural steps:
+
+* Remember to orient your users when guiding them through each step. If they need to open a particular file or dialog to complete the task, provide that information first.
+* Avoid writing procedures that are more than seven primary steps long.
+* Aim for no more than four substeps in any primary step.
+
+### About the "Summary" section
+
+In the summary section, you can list the knowledge and skills your users have gained by completing your tutorial. Try to avoid repeating the learning objectives you listed in the overview section word for word.
+
+For example, if one of your learning objectives is "define components in React", you might specify *what* your users learned about defining components in React. Did they learn how to build different types of components? Or did they learn about all required functions needed to build a component? Think about some of the most important skills they gained and list them here.
+
+Listing the actual skills and knowledge your users gained can also help to motivate your users to continue using your product, or try other tutorials.
+
+### About the "Next Steps" section
+
+Use this section to include links to other tutorials, such as tutorials that allow users to learn about related features. You can also include links to relevant resources, like articles, blogs, or videos.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Tutorial%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/tutorial/template_tutorial.md b/meta/reference/good-docs-project-template-1.5.0/tutorial/template_tutorial.md
new file mode 100644
index 00000000..6c28281b
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/tutorial/template_tutorial.md
@@ -0,0 +1,85 @@
+# Title
+
+> If you need more information about how to fill in this template, read the accompanying [guide](./guide_tutorial.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
+
+In this tutorial, you'll learn how to {insert brief description of the main tutorial task}. This tutorial is intended for {audience}. It assumes you have basic knowledge of:
+
+* Concept 1
+* Concept 2
+* Concept 3...
+
+By the end of this tutorial, you'll be able to:
+
+* Learning objective 1
+* Learning objective 2
+* Learning objective 3...
+
+## Background
+
+{This section is optional. Feel free to use some of the text below to help you get started.}
+
+* {product} is a {product type} that you can use to {common use case}...
+* {product} provides many of the same features as {competitors}, but with {feature}, you can...
+* Using {feature} enables you to {pain point}...
+
+## Before you start
+
+{Use this section to tell users about any prerequisites needed before they start the tutorial, such as:
+
+* Expected prior knowledge.
+* Software or hardware to obtain.
+* Environments to set up and configure.
+* Access codes to obtain.
+}
+
+Before you start the tutorial, you should:
+
+* Prerequisite 1
+* Prerequisite 2
+* Prerequisite 3...
+
+## {Task name}
+
+To get started, {the first thing your user should do}.
+
+1. {Write the step here. Use a verb to start.}
+
+    {Explanatory text}
+
+    {Optional: Code sample or screenshot that helps your users complete this step}
+
+    {Optional: Result}
+
+2. {Write the step here. Use a verb to start.}
+  
+   a. {Substep 1}
+
+   b. {Substep 1}
+
+## Summary
+
+{Use this section to summarize what the user learned in the tutorial.}
+
+In this tutorial, you learned how to:
+
+* Summary point 1
+* Summary point 2
+* Summary point 3..
+
+## Next steps
+
+{Use this section to share links to related tutorials, videos, or other documentation}.
+
+Consider completing some other common tasks using {feature}:
+
+* Task 1
+* Task 2
+* Task 3...
+
+---
+
+> Explore other templates from [The Good Docs Project](https://thegooddocsproject.dev/). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=Tutorial%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/user-personas/UserPersonaAvatar.png b/meta/reference/good-docs-project-template-1.5.0/user-personas/UserPersonaAvatar.png
new file mode 100644
index 0000000000000000000000000000000000000000..eead6453c280d44a6ebbd87154ed008704956878
GIT binary patch
literal 18738
zcmb@sV|XP|(>A(eV`6*9Hg+@<+qP}nwrx*r+sVY%gp-NQnIvE4dEfJV=lnl=U)@z*
zUF)t|YxUJ#Rcl2m$cZDt_Ic#PLVup|kx6Jj38cBOtS|u35RdTJ
z5bE=q#8^T}769;~1ONg;0D#v|QNV8iz?B&QI5hwOcryS1Y=@jqMbPJs5K|3FGg(={
zKO9&96c`!+;*$gW`~$%70RPZFIe-)x{(pHTFzWx+0S5rWEdh}KtE2Tv|FQS~PXDD4
z1z`Udu>kzP+Gzz4|K;=lwX+N8y80w=4icKq0D#QVzXQy5<~sEgO4CwB!$m_@hS%8M
zmeJ6}-pG{E!`9(nD*(uY_mj0XbulFIu(h#s=Jntw`;P|iC;v~(L`L!-6&GuMG7VV;
zl5h4-rX-w<%#6%r0`MdxBp@dfGhQVTvHxxUdBsm=;o{=J%f#gF?#}4W#%S+k&cwpQ
z!^6bP%EZdb@TtMz>}ls>=)qv;O#VM0{|}Ccsk5<@rGty5y&cIvTtg#!R~LRVvVVsD
z`}-e1T`bN1uO&O@|LxXi2buoeVPauqX8JGoXH(EWDX+YfrRk^TfA|6{p#Nz8e`Nn_
z2gLNx`2Wk9|LN&}q@P_CfCn-Cci05rarO3K001F?q=>MJ2iS!#On{EM>!YXX>*KQ8
zgW30X>9w^15->&_R^NaJ1!sixAX_hG1Lz
z^)%B7TD7aLjo!uMo+tmGzISTcW^U&0=5Fd{b?kihJ6%_4&b{839mjdzb>lJ_h5d+7
zX4K5z0&(G|6%4|_*)ab96g?jl1w4+aZqHkvMOZ8>fOp!gsGh4Ic^-cm?l0zO92N6{
zVcK2J+*LGy)+h*RGR!4)wasc?=Gl0SO%u;)@ZrOUw5-llz%!n(?;Lw8hDuvpD3V^R
zL+miM7F(Q=z&96B)P^tR!&@qOfO}XfOjqLXrRjM5WO9qBk_mB9KKk>*K@CtPs)z;Qr<{+`Bx7|^M
zx05`&VX2xgo4q>NT|2P9!RFUlevu{yn`0T3RmT)tjuCEul$5>@ExY{u)z8Oe_q5=q
zwUXg9hNr#w-VR6$w<6Ni!~4k)SKMcHXXYF0BL)&0;oJgko?H4Sn`v`pbiTpg6xTvZ
z~@hQlPAq18dO?w%_hm~B=5Y|3VuG+pDTTv(+
z1s@zmWZH5KyDmEb+ILro;Hbw;Cj5l26}<3QhF3o-3sS?rS6xl!)8@dOdJvbbPlF)R
z*t`~JbVIRhPV5;J37>NBJGc3ZsNpc5G;N1nu(1jg+S}!_mX|_eJl|cfPm%9Km%HDo
zt7!v27mlI6h!Kqxa1+64N?ehpl;PyPJYC+nWRD-ct{XCH{2#aJ!|c_#Zkb+#8B_Yr!I+lI1w
ze_9`p8GC#0%t`(K`it!20gg}=C`tCZGsvc8Xkr$3*
zZ3Ub?O@$8MV2D$kQM!rvm-k~#=>bVL_sT$+rCl#NnlkN9R}7vjPIm?$g-g9_UY=YG
zO9^v5Axol)2R?j3zd--*PexOeV;G3Q88zSYY6z?@K254dMdz+qZ+Dkff|&4~jpK|D
zsv7Hbs39^K(s(uZHoms=k08~>yZEf5J~i=K$PS_CeihZsDjadxFk=eh#!WhV=S$st
z_tBL}%?(h#1R3<(Pq#e!Mb@ACs8Ju!+jMk%u#K+Br(Itj_@_E2DvMYxIm?8ET7+?b
z=ApZ$r$x!Sl(_af=hX8jdfk9QwSQ>P@}
z+QQ1hwh6SIN%o$7D}4Lj*s(GgW4mFfdk1E+VC^2_`Ul3<@6V>cudo63R1-8>wH(bK
z^Kc^0i@?xzw72I6BMltLQU-1fd>Py48CVj2;~^R^bXDjO@3MyS(5HS?`ap
zh;$6N#mEIg)ETTaq7sMj%;p9{R$Api+mJ(;V;^}x&EEdZ?1l>psp?E4XtE0RI*96Z
z!CHiM{nyRZck@g%%(q|q(V?2F5AFVgt8PNuz>whCt9LGbkt?rkykNWP3Pvf4kmfitu~S;yt3HM
zfzRMa6<`};8rA;x@WX;niFZ@_*MML1VSVM=8EGm%1MKYIcoEkNF>M2oTR0Tmyq8u4
zev7d4&(qCqq~0je>Q&m&4)qBQS8O4v7d%9)0@#blO_bTfUTHxG6&A+!g
zc`F15hZ8zsF%^kkFAJg=M6^
zKhdAsdG$U#K={evY9(ih;|-gG_?Oy;^tXZ8l9!9zxYti{b!aykt`m;x!_b7nHAm=E
zrF<{mw}zP*$8y4jW*3=-->8TR$`1$-cMrt~pa7mulvaMy)yuBG^w6p5-|5?x`qE(1
z1xPgQ7bow0|CSFMF=_hm#OlX-HJh(ZZUA*5|j^|O7YU(
zRkj@ztdY5u%wm1qj^3P>=#%IA8671C`nwUWY{Y0q|N74Sa`uhP-f=d3u0UXvXr;*s
zCZL21OX)EYOg$nPFBEuqF;BAJ$b-L(fNJ4rumhI@)BOgm;0*|Gyzjk
ztq!L02K}6r+OY)Jgq)^F3bu4|LFGrfT|qwL+AD+?7>H~swviZCQo5jcqcG3?a|+li
z2<+c?3C*hNueeHGEO_65Xi{;v-yfP{$1#@aupLv9Gk8_vkRzhkindKxRi}$^<@b6XH`9ujs
zv{BZbcU;rR6PNaa;8ko!e$?n(vZhcBLX{$I^t!;XhwPbsfu)OKmdV0*W~mp-*No0I
zVmT1sQPxU$h;e#%jg5nvz(PVZg{-9ZLPj&?4;XQVw>t1Cotz+#s3Tu*?=v^I@DDno
zc_xWRAt}q>kMIuKg?7uO*0)Y;)dJUp4`7al-fudE#a_~
z>#=49u9g6%AeMDEi_*^{U)m@jUULv#z)_i}WWV5nSi)8V(nLDHE_(Bg7@*2UfuVt+%0Rb4Bd^)Tm8+0wyvXal9A(D
zLh}kzaAOP*>sscn`zv>R2cJp{Si8(Z9*Bf#9R0Q|r7R)|
zU=7ht#54WYw$0!4$bbiPsDr12i)Q*0%A-3lrO
z!kS!Aj7=Fz?fjZ{-J-aHV+Km&>I|&mEqSTjxv@&zU2FXfTL^03o>cKX4UAQZ_1F-7
zE_ZN${(SGg_Nw)H&BxaBDLE9YmCaLO$65UDSrusYX9E8=qMK|MkVvu)Wd>d-KV
zKyShTkRUPihCLL)UJD1f^2{rN@BIN%(UM59WXq?})o*;k(Fm){E0#f|KNt_ZSvv{`
zCfTX7QyT;s9a1#OYuf(Dk0^d6f^=5?=0hFfp`f>^xZY87qj%y_VFY-Ggc|OCD9p8&
z7aQtx4a?m|Qwy4{pVLba2;5W`Jv2NEnJGhra6HS&Npj~kbJ@+i<0X;+p^Dh&lGbS|
zx@>YMISA0yi{E9*-3|~Gk@{A{;`y$jvQcblDXPZ;h_(#<+o=*Nlc`LYu&yfn!2f-k
ziPs0+1~5zKT#NV{M62QPr5SC12&iqH7zCZQ;g|s~zwu5Ssxso(Ty&at+M)qkP!AOmI|%?-eGQ4M}+jggWHN6rVqy
zNk5_#z#X^y<>9U4_b8KXv$M${-nq!ywm`L7SDhr<6vW!aOKrMVAG~Xr1^G=LL=Gc2
zW-7^F@)gUW!?_=U2mAo71g!f{x;p#hhVxc)2FjvwN76V|*bnhIA*8*Y%B56t6w65`i^dJ&uy4dgIL$kWozRL$EBDa~S
z_1%ou)_myFPmj1C2>}|SC~Q%G=ANUbYOfK8q05DTDfW5(5^D4DU1Z^jv$Jq3)fe!(
zq3>`pEIsw|F>oTPok$gd#<5aXiRIc|rkkxvqnoW%6B$pPKBBgO-{o1)O`$@$AOFV3
zd)V;S)7Ztqc;&xrquEoTL@!ahx3*8{UOUh;nfm&Cm1xdFuhuZ~40C1l?Gs5BSNaavC-f8!-YzJb%iU3t=aErickmQ=G!lCe5e2r`!te1^Og&S@
z5WxacH@e|=%A)K;U{d$w!G%Y%ISO0t+=^8{E+&(8?wwCskpQFV}UPdj4
zAqx{(6vEGnidG>*820G`fBk0
zxI3b9woekTuWx}%ip8(Mq9Xy~?|((voQdR`74)6iczqR!Up4+=tfRYEqrIG?|0)=_
z;s+irnGHG08Bk>b&(|d=Rr%B`2wc7LC(QE1sG2V
zED>vi36ghLXxO4BpE@0rc>E=3siulsecTXa@g0!XSB2broi)vK&2?M2b2XI&^)$iX
z!j#Not|t5aiRxAy4mt+y0=_1)TU0Cm+Jk?^WsKgCglIX=^XD3t{+hWZajf!DAP%AR
z=*vF3N;w$q<&eW$uk`$bZUhv1T|fM>);yincr2J!bT<5iJYf`ZY51|laQCcUsIYEV
zI`D1k97IliXV&`-0t)%c`)KxIt3kQwS(E;xQg^fw;<+-_~sXEJDD2p3bUHxkwh
z>itRSDYcU{Hi;1Aofyj!^Ah?ad;9WIV&h4&Tn52_2CL`7sop6DI3d=yi}#i8Pj>uP
zI3L22m+*Fw-O=|n6@Yda_|T#L|=mc>Q$pt4j34(Y<9ijE)ROok;J
zN|sPYc@~%uu0~oR*!))Gosoiry@P%YB&TER;8t=Gru6Wn!gGE1&F{VlVmPBeeZuy#
z*Dxsr_d>f2p3}{sym;U?3z+qG7}BU&yOxiu_Wo8yO&|K5ETU+NTHGyK58Afww=2P7
zS4N1a0&|VlW#uNP9DIYkFmT=#s4&V_zrYl!MPI9~p|^Dy1Th*u=R~fOH`I
zr+2?bK$%=q{f#j+72rn1%7oGoUrhm+t!9mXgt8HYiisyv8;Td;7_qdi659@0JZ1Be
zpNwgqGKA*U+T;|EL`J(~y_GHJY7#W(UFcemakPFGt$n#iDIX5ZP%i^Kdr4HllL0g{
zNt;&&bN+sY?ZCXPRfc?z-GZeMLkmb_|67}I5DfW|evelit4$*v9(mW@LIzr7ai_>+
zlD!=-ElSTEF!rb{tGL@=I@@P27U7UpV{82Zlis480P!Qo0GEQxEk78Bp-l+QyN*7V
zFa>7vmqcz-=txy4tri~WF*hQ!tx&4XqkC5Sh7<)pO=GDhV(aQWV)m@*KD#~_btof%
zhvF(nkS7A!Nv^(cwm_wU0=+gcL>SwwU{44IKQ_dNa2}Xde<&{BG8tsm$DZ*5bXWpLyCY8*MXAh*Q&1O>TrKC-5bC_DyX23%3ONOMu7ZXPuRXP&MC}N#vl~7q5p#AsmYK*Oi3@%u#ubM&67|^tB
z?=&_P;zzoriYwF`lHgONN`-3#^86FVBi5T9R384v_*pF)g>E%LfRD@{R`1Grys97N
zYpV8~(^48_`L?VFG>!vT0UoG-GKKglFkRryqG~SYOjvq`L~fH)UlD9YQXQf_hoD*-
zFFbStX&?+P?Bypr9)vqQ7#9ZZOUE#E$`Z+|niD7&&4{L>J<-PLA*PgYS)64y52dhE
zg@zVNGm&3S
zUn6PkAgqGK=>}nE4ZZsJ*ik}#Q_Ba)y*pFBPnTX(
zdn}5&DnSWWv(U_wV=Q|gf@N9y|8>1PN}p{t6e9uq$)s!7T`jy~kd$R=)U60{AoO#|
z=h{0wZsbe`GR-r&>nug02~UgqniqnK`IadD@~NJgePixtF?ck*Hi8?&3t3ohc=D^3
zO&D}h!a*{6MMc?Q2Hg;t#5w$dna1GSY52ROo;$OWWdFC)nQk-DSe=e$Dc8{RxV2;q
zd=)(&jP`;tj(x~rZG9e?g{a9+O25u|p{Pcg(A}s;l`&XmyA>mQDrInjVMubLm+blj
z)>Z@>iZ68v2XD}I6VAGet7s6!i_P0alwwj&DggvPPu+qE)2`$T#}$w0tAyFr_n_Sz
z2)3&`>R@H;6Xc9`&5qVH
z_8e0>BC%HOGEn?Guwwugh;jtty^4VufyAWVnFA-67Pj
z#s60dM;Hj^$%MR#WvRAb;31EQiZDGjB-ZOA4yiUJ)>cSib7zI)Aw45bP)uQ3a9n%+
z)p1(2o_Xv>H?S7P3rc8Y;rEg%vlOk$*rfW6&(pfDV&Z*oxZd52LjSBNI&2**)x5I#jejkv{;S?KFy#*|Kjz|Au
z%dU;9C7v$tv(~~W7>DkK&XczcH*w8hg!zSdgR3A`<`=~If?lZw6w@8aB9Qsz@%P<|
zC!YSJuhgCV2g%Kdk>)Pd)rDV{TLc~Fp)M341TXm|5Qk;=Z7h1f>y)eVQY;Qng;9n~
z9K%agFrOlvnlHML%(qN)&iyuf`KgesA{t+hT@xQN)^7^1tvAY%HBv&;D`4h!!ZgoqJ_UzI8MSUGt!
zs;yu1jOKaFaL*waGN^mr^ni;uROze>R-J`6BSZ4UiW-pOrT~pfNGC-7*#C%)BrJTT
z)y7$ZRILYAEYr$F{GAz+@Q(q*_6%%sZrX$-d9CfQRVxD1@TfcNFZyoF5w;v3Y9_gu
zls}m*?+;;=#NmWpl@wvwyw-5_Q%HyuDL_J+Q2k{68e=>pJqmg@vV>@O>C4LVa_R8T
zMRH`$?6%^Xq6ZL6f2qNZegTLs=g?9Hx;r9q!^x30Evm0t&PUaBA-0%|K7lIZ0dkme^F(8>
z8ml6*vuDQz!#M2i@*=a+3;gSMY)GNL;~6*-T>tV_D@HoiFVwp2$Dvf2#}jN02JA9o
z&|8I92LagnvbOe`0p=_#ulVOqzt#yEO$Imw8PQ
z)+>D2tpP#zv!WmlOQH%y?ZR5#yxaiyrlZz=_>+X!Ph&EEZPENUF*pXFHb`?ORET1>
zWH(?pLLG~01kO%NhZGgkA9Nj-hg#)*>uvJFN2)oYeSpR{HLqA1*)-7~29m3(PwbVff;nm!K0QT^)R#_xT5Zv&x^Q1n%L64T
zv370}HoDs*+Vgq{_>4A6w!%t1c84Wp^Fk}>?k=@{?#WF9SIpY^xa%9fP2fThpWw4f
zAp!9lnkB2r3Ln_B3zBrxr3u6)PQR`UC%u4WOhUIjtPHOrT-a;t9Bsq4p$0xoyDf0<
zA0dJv(ii;57q`)AQwc8mUiJi9$%$O^=h!U*YNsDBIv*FFI%nYM6Qi0gFrt$fz$e#E
zZ_)L9pN>}}7+wLZx`&H|NtZaD5+qqkiY|N&5uNQ12O&8_&2YH5VwZ?AquQ>c+&RsG
z7)FQ6tINcyu$fe)pKDaWY15w=$;^H}?5H16?6S@ck#xwMs&gQr>AsnrXua#HR6slg
z=85>$^r^KIpmuluD)O2RJJ=0qPj;33e8&w#HVpV^H)`N&g>7a0JeMlZE9qE*EqrW6
z!!CAove-a>l^s+Xxhxe{;ogESzD_SD=LbI`X#svjBSR%tRIc(0$0VR{*}w?9z1+BcnYQ3OPbIz;UphJdE|Zv6M`@yc?;z-3KLfV`q;?>qsHw~!
z@RgSDJuI}n&h9w|*}*Bnf0I(pyh+t^GE-ri&R~W&aWMll8V(>
zCO9&`d=5yG`f7M@@Q1}Bp!AQ7dQNQe!9{l)z)ni8xL322=_7&St90Sv)x=7C4bFEj
z=0=y@sU6?T@DV$`!$(1C7*l<`^7NchKTW>{GJ8s(UqJWb@F?uSA`gtHrDpLfA?@5<
zWpR>^vML-gt6(b8F56@oVgb$<#2cnA#joC2lE2qJ0yHnE%NcJPP0{+UX(!m30sJtp;=uRT+A7bEn^_Js^F@IKWCuuqH58A6a`dhD!LkNLgjC?lfP-8kL4sCkH|HCT`6qG`U=(Xwo15B;dPa1cm2s5bxFbM
zEn!|P8OR$C#8!F19fVyX7w!y>zt{e(Xe@Arh+;=yB?p2zGZn*G@&;{)J<-3S?mg>LYN4?AmtN&k2y=Co=}p1sueS)n*pN8!
zwRzc07m%-)_mQ9ZP69OmCx&e49kkBRr-e|BK-0_vEKBbCM$zpMSwYUfV7{m&Y=f{E
zlf4Q-Oq0ki0#0+t((;rP9PivdMKpw{u#C*<9+J3iY>`
zuygyqW*yI{9erE+3+7r7k0~xLhr1O|x5ZmOkLqGBbVMoax+~EsWh?Y+lDW?1rHOg~
zJ(U9sFBP5KnnyR0ykH#>nIYfNvcuWj1?yB-wjrDu$YC%F8mJ^Ru#)~}govM0q#@;1
zn2>^M0u3m>ygBj#bF_h=)31j+ZoS$Du693sa~kV>8h^B%9Y96kA`}EcLkC1nBmf{H
zM}GdzC<}ZBlcY?#or)Dq&K7+3T=)OE32Z!5q-`%okK4slf}zN6Lbg!}ubHG#-cs#Q
zU@avA!yksd^30eJP}d&Nuf7`
zPBX`;ce8Pk&RLo~fgItd-7cHlkQFv)C7rt_(XxUbx+B$nS(6sAg!*9oxal!!wNDbg
zQ=c+5-8_U%OJVYTQS#i4)`#&)q!Q3+6{dmGjG)19`xE@D^s-6&&{yMgp{P{4{`+0k
zNF!*8CfX`H5K`kD<)iL?MvqK@zNCPJ(7&ITp1BAj_KZR-RJ9;{GciVR#Ia8j)N~tW
zMjf-eFf`rI9u79;y_PDIjhx=xB%T|!C*De8li9qU(-@4_Bop~;P)Ju2eM6gckPRWK
zzX~@umcraT$EB;n#P#tzK&MB-L>
z;<9zU*g1)3&cq%DXBJjX$C*fX-GRYDvO+~&B&)~isgRs}l+;XXMyJ71|MTpL1J*xi
zOISC0Tko#3MdQyMF|R-3$P;mAUpHX#(DE)8>u$K^UvaIVAmAxbj
z7>k7FkMw?%E%QIa`%b0ZO&4<9LQZRbjC1{&0R;+x@1-A?8&FP*eU}Lc)uOi#p2xyg
z%Mt+i-Xu)G{LK<=s%;Z7`RC>)($Qp`o{OpKv_EmS=@)wkw=5+C&Fz>awZ<+{mDu=Z
z2<~miaOrq2Nob2ysN^qS^$d=@4QVfvb0%Q{gIK}MD(#C8(!)F=0HMV25X=5DQujXB
z4i!*`j#agli3Eyj0rH3CZU%b49T#GPo7EBGHDP~LA?Bma%X2p@VlH2z7$6utL&(5l
znWSdn=z5(typ0aPz2ve>$=TWmO0R?cVP%sU$L6MoO9-GU{|3~6rmZqeSz5A$$~UM4
z(Bcu*X#Pm5?gS_2!~wFjjq|TyvqP8sT^0wj;LrFdm^I@-Bizdhry*YiJS)iW^D_j#
zkvPm~H}~q&>N%@maT;AQ21V_L?*J=}lXBcMt($W*e(lU^+0^jbf_LmH52bI3PSQ0@
z{%Bqd{W9(Xdu@(>`Ex)tzgbxpRZ9qt0yF22SDG$)FI8R;3&vci;nIH8k;K>g^owNn
zM;-ULm8f}S`5-;S`1ziOKT`o6UYNhmt?KXlY9VS>>z}`!YFY-w76eH*CW1(Ok^C7e
zd8V$3M&kg+EZ~+3B_)*q;uti!wimQXFnSMGauFA*;9L)!C2E8HqOYYKmx7bm6KVR0
zM2UO`?Rw$9p6b2wRjvNGT~G@m06}++4{q?g<$<2|RwQN7+$0&JzzX6&;tFRjoeja$
zlGUV8jy|#qONN7`BnLrC)F)y_`4nW>(tm@jm;LnK?064qUox?yDV}F2xbwbOrwV=3
zj(O%6w8mzGNXCbzuf}%9VMvjrsNd!{lj3o~d!9VhW3!$)bT{CTLEJCeLTSr{%feSd
z0x&`(FRc{amGC=ssa&p+yg%FBx2?GZ(*^GnIvDGb%-{Wlo?wT81p5u(fp}FSxJw!!
z-`qud)wWq15C*_!TtfGwEiC>ui>&kD;3OI*LzMf0p*ZZaHz$@Qm9d=?YV+Q&9))Ab
z1DZypUt~7e4&+=9!oeJfLZ&;tHxPz5(}`Y$K$>o!vt9`fJr|45a{(V@3t(^!m#4(S
zP$20zUym;7dWG2MYegVJWRfUwPp3FrmAdb?775nxihBV?0dJKVnxd8@svQF<^3olR_AB+e=(%{<@(Os_)SeLZs@Z_iL2YZP#-Uh(Aa=f
z8e2(3{$+%0o>`|3V0kLRBLazQGlV`EH)tZyhpBclml`Iw2lYceuJT#}J8a$mLI)_n
z#!=s$?nk%>JJPgwQm$M0J!T
zI{2z+*|H0!5ap*?2x)DwyD9gy_JC!i{ZW5*#(eGb6zr~Arc
zmk7SN$buKU3C3e4o`OHGGJ{^kjm%P5zZXa&?ivn(kS7XyiF65E`zel3x|6MBps3^2
zdkp{)Ea03TQ?p0&H6%dARZ;WH;fg`P=Cj$ksktpZ+f^C=J$p5DH6?Q*sOnegpzsc*
z#QF?ugP(M&5!2MV^OMEt8V=Zqpi&&N4@^=S{S$z>C~w=!*40fz1WNs_d`m>3ww%G7sw4lGN|}=
zW!cWZa`Bnts|&TrF}1wva$Ss2ePg&vyGvqdVGP|%swlvoaKSH1iBfnV6?h|gufqL8
zA6Auht!XcLKhqBCSMvte6zr5{@-US50WX1zRdu5a3QxY$CRGu4CX$cHsB%-edi2`9
zE$YKk1ZMCl6zn0GPR0a%6TDI)-#OSkTJqZl2^0pKdW&bJ$2fZ(s~j$+tPUX7jz&`?
z{*gn`{Q9WxENWR!aEcNOdnmsofeK`fyk{VWrqo@yt1;JFHr#kqrqw->@=qi*h<_=v
zmN(Ac!(0Nf#(IX|kY5gE?g?szzDhBDd?}vLHOcU?wEAk%k3>H9b7{`W-jjJGTG)S?
zo`1EXyVJ)60=<27mQ+3{F4viwu&f#1*W7^P>Bf`-xw2
z2*Op_unrAGdddRd4&3^Hw~f&rj?inTJ}1~gvuMO@@=P2%
zOY?UL@o$^qKyeKW!(CJ=vP&R_O}in?eTvOVF4e3d4}Yr=*j{-nSmM)Xxl2eUVT(x2
zDN%r_9zY)M`+K2OI@#}sr_2Qv-*P{A0Kv1#3mVOO%XjhKKHt`oKz90|z{5$^o~En3
zP@egE!C2)By2ILTdda?|1?EI6
zoCMGe
zC)@F(8}bjm~#U`ByZnru>*VvLt~ZD-k-lYiR?onIAr;xNjgjmA@z;Ubf_lYS31
z(tD8QApEShC#(c-cUZy`Q&8U2jQM(^NTj^~iXvK>Fs**;+I%jUoMGRUJv@;Uk$D_vKxHtKOROL*FE;N&gHIxWQaQO&>
zoe4+3?24c<{0&L~eq0&E{=FR08o_COZDK%G0XeoXRZgkr+oidAl&T544?BjhogyH|
zRWubN&*o%hCH`Ah`8S>L_~aO$mTr1Jmx^5^rv8c$a`9o_!l#%=%RU(>qbg*7x9Ls@
zk!!@;?R5X3=h-2g4w~}za`Rb4wK~OJ58(xUL6YR}{Kkp5lH}T=aEy3*DOEFJ9suKG
z6oB!-%!1}B4wVMlcMF$pKD5sfC`ZU8?fhoO;VEnywvrv$`7Q@hbKz5lSng2%vTjFU
z9bGiPXXhl%?Wd)nS+3_=!AAd6Pz5LrfhFhfAUvX?slLJz+u4pn}mZ7neSn4EpP-^=7xDjM+?I~Ga6%;I@EY*Wg3qp%1w
z>DSfG8pz3SNh_Al3H?U3-BVTO+&0eZG3jM4lYV74M!Ii7_RYHdRH`y`p44);LUB?7
z9+6Z+(ccQoGY*QUj|@5j%E+jhUJMEg-QxoBaS0rjgvZ^TMA4E0lamqrA_YA-;EPmiIV~hD~b%A)uB^@IW72zRKP-w
zd+kfgtU!ZMt2l&`?S|D^v9QYkLbY>uv9^)-lQFhMHDi!6f6};QxbPL$9?XB%8)asO
z1}!A>71hL|GkxFp%BySO`urkOspm`BVJ9HM>#s618Ztys2-6l}Rre-N73uLKszQnn#)9#7p}~
zA@eenXw_k_&u~w(t-2DJw%0PasnLUa7EtGJo~@!1QsO1t1c}YquXnrV5n#=k0cW8W
zWUyDjLY~o>|9(1!=pG*k&PJng+iXHrI)!+wE#OW_XQjMVkO6?O0A#eF5GEab+?5b`
zyw?vquqFti4St2mIZxP5X49XEpp`Bt2dxvPJqdDX_qLeUg5b7G$))6B380M490b_g
z0}DFWec&+n1k5322oN#u4bvgWAsqOeD#$5NF0B$~`Fn*fJqq;*ITZ%J7|1C!peD#^
zoLLxu(_te>5g@?xcz%I!`kOcgZ24ebBA!mK3hfr9zP_d)xXl6`lcPWk6(jX2Gfxjd
zA}X*StB=Kp`+GMVx(_ZL8-#LLsxxzko9FjHh%{^lTS~?3R1C+vPTjnPQv?o0yj9?~
zDVvZ44z)NBV-G4ilS?p=?S!}#j4niBPF|ooOa)thK2bEzQ%bCTtTe}51Due@wqx3%
z%F|f0Z-gYKu=}lgeKtI5G&PQW1gCdXD|rB{P#jj2O_o#$g(Vctog6TiJVT|v66;Jt$?>A@X=^>$+
zM&yo29%=i?8Y)j}jv9p6X2?B!%UEo7m+er32>@{mU!PUWN~#6}ON|$n*%Y(|HfI$){
zgy{JD+ln{Ypr~%~ZJ~<6L23^CoQUu>q(8j0#I|)C$;{1OF({sSkL~@Xon#S?f?E3L
z3SBO41<^q_$(PJqSDRiKGA;4Hmg7sGJgc;_K5SJ0~=awZEbqf#k%i
z^6Hch^+t+J4(NCb;Cb1@lhOIjkJKND3>2z7u45^R8^ERL1`}--
zzYqrT#n+vMjc+cx&6(DCk#2%Q8}ITAyQ
zct)pDEcvR;9K)aBK;l*3rtYQ3O+%=wu^N7%Vv#(EzO3|iq#=Yl_=^BS4bxfw!G!Bk
zWfzxgi>Z*Avr+?B0v3;`@=Rs0s7H8*;(hyRqI#^CEYS8N^kDrd8Z&wj0X|BgHQ9yx
zY|?nlgID8m$ok=C?@-wf;DzAq>89TG`%kMeeu;njwX%Lnev2;cvL7=Z0~7MeFk^f-
zBdkhHXy^LxvSfbljhU91$KXkrNZAdAEEawR>G|5G%_PRTBzBT~D
zNc1sbr=|N*Y@-WtiXjkeb#)1Auqh7itXf}q+2pOT1K2cfr3S0?c@?b7c#dLtFYk35
zlB~$*2BboinuRomrRI>ayTC-TE=G;9TePAjD@TH4T))?or3<&Yr#J5O-NjCIA(9G<
zs0A&)qr(9K?w1$JehNbC{@d}?`^=&O^I
z*HCT~L$y+Hd|`EkfU0QayZc*_Uyq?#g7e^d!N(O_YhMf3k>okL^ghVtP5p>baMBNS
z94<*XSQRj<3dUR>CCBpICJMA2yL$H~@;ic6zC?#mBvf=emmIe20y;wsfN`}dA!b_*
zs&KhE2KcBQvfjcwzY3&X@=&FN?+00-3AZ!6$!Igjn{hJ)c!^!9@g9T2RTgr8B+b>P
z6Q2>MF>OwnLSYHT_+Ih1okL=tWuA+!PAbw_{OTXxk5`dKjUE5t&t0Lx%2XfXa`0$8
z;s2(TL!_+?97deG+%nMM9HIH-NNWTQ_g+k5g<#
zs|8Y-D}KLLZ!BPCiLv|{j>(C$9D__t`HeL&fkdhTFHBfeXCJWyVlTOeP%4XtW{@%X
zC599g06C~T$xWOLcRnXW(uDZgfBHPCXjU905df68(_yHP1h^gYdHFL0ZqwGJ>&#V
z%zKb;f=ZXXaV57FuM-hIWCkq`z;Yy*8hyK_b|=(Mm=GVWKMa?oSGW{^A(|oVqH_+w
zK~Qe>0;!c$y(m{ew;3Ae_ic1vQ}5q7%Y+et
z218y<>7Tnv2^!M@K$gK%dI>f}y9___@v{ORJ~#e&(-Ec?@hG`7O-21d=u*Bmd5`H@
z63vGN3t=^ezUI>VY3}!!c#m#EX+MYqIarN6rM8p)z+H&)>5vsTjEREj`I1Vfx!V+vex8d~NjXzD7`
zcUYP#aY!CpOOr=Oz&RubV~$Lh(rbxa^dvzS3La*hp0NIW6nU6lLIfy&nJt<*jAE&M
zCqDlxY*jV-_;>7Z!&?j{KIG)D>U8}FRjjr*KmGXTgnA8bdxMTN=MYoOjdJYFW^vY~2
zj&SdBU0KDfLdnv`eu;(?L*=D>$N{-5l1CB^0oo-hYK{-#-yH;;I~rxm3%wmD%eyWr
z*ww^MHJx)o^G9QiE;y7dHA$o-;s$(R!aX51MQ}oy5ICjG;cZCTJwO5(I4~8A5mN(r
z@sy(oPpB0CAezcuZlzNXMW|^^GIDTQX!48G$z}o`PboQ9SHqDnt(hU7L)f*b#5OLx
z&>T|sCc0yAv}O}l&h;W2*)a0b4sbISVqVpC@Vl7%7Q%q;oqVq+t$?TnD-e8FIz``~
zMPd)<>eXiFtsX6De;@1DXx}e)_Va*-O42rkuaS}y=!6Siu)n|&*HvZ5vV?n|OYkBg
z%M^$k_WA2Y+@}c0DTzH?I|xoI6J*E88i~<+k5URvlpb?^B)y*CzDY5i22!B)Nix2h
zVt#4tRFrnGpfDup4|kG?>P1eX6VRz>Ej`Gn@OHzSj>z~
zMpkrm`Ak^pao8KoR+-4JJy90m2?rDKea5OVN(
zb(SkUh4-(7if=E?g{gOI+0XNg|6FMBK
z+qY8}b5~vk!J!Ty!q&j0!o%;0IC{o?y3K=%L1uwcfKBd^9VsIt{uOcQR-N8vVJnBC
z9^x^8bI}HIe_1=o7Q<8>@N_!(ior8yOJ!;phvwY)4*a1uIp;IbzUVDS(UYf{7`_Wc
zVBHh4)K3voP>k8>WOZpDkmEKVx8T>cJO_x=D5ltm$x%#UwEE;_OkNO8O-`1S
z)oRk7VjJLvjGYCxtGs$|7@(gGQzMp_EDRO)1so*mt-B{c|J#Ddx9+Tk#H?ZAFPfWD
zj7Tqy8%M~=Oy4@^OGh&T3xvc-HaEbWh<=otYS{2@cAC~mR6oS^6esFrp?Yt#=r>ZV
zFmDLR@1}TGFlBvNJ!#h;TOU{xaA8$&4Z|^MGU8}FV(H{81;a5fqC2#p3n2v^Zy-t`
zDQpf_Bn|ocaSxWnp3As#T`_u|VSeuii8h|TWI)p^^H@|UThWrBmHPNjJofc|J
zCiyzW!@P&4zgRO0Eq|UNUl%F*5!OwcrpHnLTl6#Qq-?KeDZN>j4$>dMdDZ`#+9I$t
zQu^4RLv?_c5+VaY^>iby~uUQCydiHDPZ#mrDP&@8jI
zWWl=2hV3)192lu3*IH~cP(~5}udrh6>(=?CZ`ap+K6RM7ubDWd#0@o;;5apzD%K!E3Nk!3gd
zJmvC2o}Jz)c;c_r>(KJk+?C(w=O*6Iku82b%r1&jFg5Au9=joEQ;N5N*x0&w9N+lt
z!YCSOb%BK=82MfZZv2X6QnDe{24_`yw0*D)@6)B;|O^4_=}mjqZW
z$;S2TEpFA!5#xJqXn0Lni#}rn2`<>?XTl^?z)6wzo{%@>QK<@2GGMX58`o=A
z%cf1{6`B@*`&ErsM)baC%+OSKi=`svv`rV1s>)B=lLzDlc|zWlvcx3?77O08c5Q}J
z1lKfb(RbX~bVbC7{_oW5T%{!Gv`QN~6+i`=llJ6+JGs2pos=wLQA-XimYp6DY$a>q
z9QeJzXncjw>G_SntOip)n3S7rTSN(oIoS`Uc>n+gr%6OXRBe)WX_^jz#sTU56=_b|
zlLzF*WR!DKfW?YXa(PFo+<$ZP^;Q1fZwD)?d^RR^F|aDBSe^_*PM17LOVTt@R_!Y{
zd%q1u{f#UeX-^(ZRyijPSgerJxg59*Abe+C!}}nj|2iCj|AA)GJ*(iQMSOoI45t8T
zNLrGnxtnwMIq8d{o31(vEL_T1t`r>t{~d*9mdmHGVRqY=)rP$
z31eBtOxHM+N2C8H%|JVNNBBrf()6CUHT)xKOj@^apR-90lMXD_kHcNrs9CGNv&Hwd
zH`V_3{PQc9g|z5n@LxyQsA5c-$ev_+mm)j2>#L~s1-01kmo2SaPMVUoq_LuPDRLbp
z&7ycWjFLy*$6Ie*oxbHem|I*8Utp0d-}Ub&KI;VipHAC`>7-)VRt3H`t~*rTH2!EG
zxKb*k`$9fHR#=zo-JiYZ=H@#{57PARTMJ*cTnZXaiNqRM5fUJ))NA+M&~$rKt#d`#
zNWKs#$6|DP)4?TeVEmbDMS%=ygORl_prv-#RybGQ^R^}hD$;VQLB$eIIj~p=SFv=2
z;`^&_Xn6bwH#e<}XuW^$$I56kSZ-qa&GQ;&^grT&h4b*THb4`7m@102H@>DW`&M`^T1RI5#==R>7_TOMT
zhHoh58F0BsIP-f@9cbU9-;Ejc1p*;m&-Cml3t6AK`z_7CU_45xEw`+~1~Zdm^c+;S
zQGQH2V6nW}k&M#4Hg4P~-(KJFbKL&2-*W&2wRtUSjw07(C
ztnsu2mPaa2UvTHQw9I$bH+~lc|K58yo_a@5%KE4sDPKV=bDDcPVDBcd1`=!xUV2_e
zlkiOoa02rSTrbLy{lY;^5WPek96NE_fdL>Q9h82C@C#i2sM;ZE5xJ4
zMwQC+{WGnB<&n*u--4lU6BbarVxKMdySM!K)SF{*>;2+0uhIkMJ`1ae(M?j(C*R<{
ziH{Nqig8|Ylm5-Z1OWLLV~*@RmX=qoa9yHz9Z%c4dK|j}&Zf2zF#LfqPA}~iQ(~JU
zLH%p@u511!3;R8MZb7$q_pPfklQq}Jd?yk>@v|(Ti?{{)*WFZBv*E9P-Em%LN8%k;
z#(7Jh7Mj1LA|QW%9X5WoQ`je0v!V%GzwH;@dPfpNbTHU+81>$tjBgSe%iSG6PPe>%
z3GBew+U!>cu_6*jKKQ62W#R{dKJ6!!<@yh^x}_?X0u=P9>7UYR(#iCZHMFdzi@x+n#Pd)`QN-ca_y{&@I0>6iKD-H@4uarj-+j2Njr@D)XW?m
z6HAnBrJ(^*rnZFS(Z!(yhXmER@dQ>opRll|5N9FJHj_s~LF3_|Pygv_*46ztR>`xA(-Q_+>{}jepL47)eMu}~zZ^)o1WWpsp*xzZ
znL%C0ZZ5Xk$B~qc7_KQv3YD9P6DK}fWpKGQZ=cbvtsw7nQ>)MjJv(G|(06~q=3i-D5a*ryhIw1^JS
zX%6KY0=F2_u}dx`6{Jrb-^Y^~ZC}7I35@P`+q!-Tp8fkEr1mX6um0#?Eyb2KgMy>2
r`p#B!QS~ZYolrWYT!W&X#XtT(@NZ6a7)Ox700000NkvXXu0mjfe~f3G

literal 0
HcmV?d00001

diff --git a/meta/reference/good-docs-project-template-1.5.0/user-personas/guide_user-personas.md b/meta/reference/good-docs-project-template-1.5.0/user-personas/guide_user-personas.md
new file mode 100644
index 00000000..26be12a0
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/user-personas/guide_user-personas.md
@@ -0,0 +1,228 @@
+# User personas 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](https://gitlab.com/tgdp/templates) GitLab repository.
+
+## Introduction
+
+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.
+
+You can use this template guide to get started with user personas for your project or product development. The goal of this guide is to help you create user personas that effectively capture your users' needs.
+
+Take a look at the following accompanying resources:
+
+* For step-by-step guidance on creating user personas, explore our [User personas process](process_user-personas.md).
+
+* To fill out your relevant user characteristics into a structured template, explore the [User persona template](template_user-personas.md).
+
+* To read more from the sources that inspired and shaped our documents on user personas, explore our [User personas resources](resources_user-personas.md).
+
+## User personas in context
+
+User personas are the initial step in a series of UX tools and practices. Once you have user personas within your toolset, you can proceed to plan user stories or apply other user-centered design methods.
+
+The following indicates how user personas fit within the context of other UX methods.
+
+|          | User persona  | User story | User flow | User journey |
+| -------- | ------------- | ---------- | --------- | ------------ |
+| Focus    | Who are your users? | What features do users need and why? | How will users complete this task? | Where can you ease users' overall experience? |
+| Content  | Detailed description or outline |  Concise statement | Visual representation of steps | Comprehensive map or log |
+
+## What is a user persona?
+
+A user persona is a model that represents a defined type of product users. User personas contain the key attributes and needs of actual users, which may include ways of thinking, behavior, motivations, goals, challenges, or roles, among other attributes.
+
+The better you understand your users, the more accurately you can address their goals and resolve their challenges. In a team context, a user persona serves as a reference point that enables designers, developers, and writers to easily recall a trove of relevant attributes about their users during discussions.
+
+## User personas compared to customer personas
+
+User personas are often confused with customer personas from marketing. While they are both profiles created to represent target groups, they answer different questions and serve distinct purposes.
+
+To compare how a user persona is different than a customer persona, see the following:
+
+| Type        | Driving Question | Used by | Output | Goals |
+| ----------- | ----------- |----------- |----------- |----------- |
+| User Persona| How do users interact with our product?|Developers, UX designers, tech writers, or product managers.|Product design decisions, feature deployment decisions, documentation decisions, user onboarding, internal style guides, or community updates. | 
    • To see users as people.
    • To minimize friction through a user's journey.
    • To identify user-centered features and updates.
    • To inform style and voice for documentation.
      • |
+| Customer Persona| What would motivate customers to buy more of our product?| Marketing teams, advertising agencies, content strategists, or public relations consultants.|Marketing campaigns, landing pages, social media, blog posts, white papers, internal style guides, or internal and public communications.|
      • To encourage more customers to buy products or services.
      • To answer buyers' pain points.
      • To build trust and brand loyalty.
      • To achieve revenue goals.
        • |
+
+## Why do I need user personas?
+
+The primary purpose of user personas is to guide teams and stakeholders toward decisions that are closely aligned to user needs. User personas should be specific to your product and aid any project discussions that involve your user groups. They improve conversations about users by establishing shared understanding throughout the product development cycle.
+
+User personas are a reference point. You can think of them like packed boxes during a move. Each box is labeled by room and type for quick identification ("kitchen - appliances," "bedroom - linens"). From the label (the persona's name), you immediately call to mind the detailed items (attributes) contained within. Similarly, once you've established criteria and attributes for user groups, you can efficiently refer to them by user persona: "Operations Ollie needs x, y, z." Rather than wasting time defining or repeating clarifications on who your users types are.
+
+User personas are especially useful early in your project since they support a foundational understanding of users. But they can continue to inform every stage of a project and at varying scopes, since they can become a decision catalyst when uncertainties arise. They can also be instrumental for reigning in a variety of specific design challenges. For example, when writing end-user guides, they bring into focus a mental model to whom your writing is addressed, which is helpful for any audience-based writing task.
+
+Using product documentation as an example, the following table reveals the benefits of planning a product release with user personas and the detriments of planning without them.
+
+
+  
+    
+      
+      
+    
+  
+  
+    
+      
+      
+    
+  
+
        BenefitsDetriments
        
+        
        Documentation planned with effective user personas are more likely to have readers who:
        
+        
          
+          
        • Experience satisfaction because their needs are met.
          • 
+          
        • Feel enabled by the intentionality of design choices.
          • 
+          
        • Navigate intuitively between related subjects.
          • 
+          
        • Find an appropriate balance of information and guidance.
          • 
+          
        • Relate to a voice and tone that shows an understanding of the reader.
          • 
+          
        • Trust the product or service.
          • 
+        
        
+              		
+      
        Documentation planned without effective user personas are more likely to have readers who:
        
+        
          
+          
        • Experience frustration because of failure to meet their needs.
          • 
+          
        • Feel uncertain about whether they are reading information intended for them.
          • 
+          
        • Struggle to find needed information.
          • 
+          
        • Waste time wading through excessive, irrelevant information.
          • 
+          
        • Sense a disconnection or feel alienated from the voice and tone established.
          • 
+          
        • Distrust or have doubts about the product or service.
          • 
+        
        
+      
        
+
+## Example of a user persona
+
+The following is an example of a user persona for a product _x_ created with our template:
+
+![User persona avatar](UserPersonaAvatar.png)
+
+## DevOps Dan
+
+### Role: Senior DevOps developer
+
+**Goals:**
+
+* Deliver effective consulting solutions to stakeholders and clients, ensuring their automation needs are met.
+* Develop and implement a comprehensive test automation strategy for efficient and reliable testing.
+* Train new team members and mentor junior developers, fostering skill growth and collaboration.
+
+**Pain points:**
+
+* Challenges in navigating a complex underlying API structure, hindering the discovery of information programmatically.
+* Encountering inefficiencies when trainees follow poorly suggested methods in the documentation, impacting system performance.
+* Frustration with valuable code examples being lost in community forums, making retrieval challenging.
+
+## Contents of the _User persona template_
+
+This section details each component of the User Persona template. The number of user personas you create depends on your project's scope. Only keep dimensions and attributes relevant to your project. The template is meant to be customized and adapted to your own specific needs.
+
+When deciding how to represent diverse identities within user persona elements, start by assessing the relevance of demographic factors to your target audience. If the scope of your audience is broad, there may not be a specific demographic factor necessary to target. However, certain contexts and product concepts might require more attention to demographic representation. For example, if your product caters to a particular region or language, consider localized user personas. Or, if your targeted users are university students for instance, reflecting an age range of 18-25 may be a relevant representational factor for creating user personas specific to your context.
+
+Want to see best practices and further considerations about demographics when it comes to attributes for your user personas? Refer to the [Process guide](process_user-personas.md).
+
+### About the "Visual representation" section
+
+An avatar or profile image for each user persona is highly recommended and offers a functional advantage. Visual representations, like avatars, help your team perceive users as vivid, real individuals-not a vague concept or homogenized group.
+
+Having a visual reference for each user type simplifies differentiation, reduces ambiguity, and enriches your ability to cater to their perspectives.
+
+For guidance on reflecting diversity when selecting visual representation, see the introduction to [Contents of the User persona template](#contents-of-the-user-persona-template).
+
+A few options for visual representation include:
+
+* **Digital avatars**: stylized in 2D or 3D
+* **AI generated humans**: hyperrealistic images
+* **Icons, logos, or symbols**: abstract concepts, simple stamp designs
+* **Graphic elements**: color palettes, shapes, themes
+
+If uncertain which type or style of visual representation to choose, consider:
+
+* **What degree of separation does your team have from users?**
+
+  * _We interact and work closely with users:_ You have more latitude to choose an abstract or minimalistic visual approach without compromising the effectiveness of the user persona.
+
+  * _Our users are distant from our work:_ A more realistic image or digital rendering of a person helps humanize and deepen the connection to users.
+
+* **How many user personas do you anticipate?**
+
+  * _We have a few:_ You have more latitude to choose an abstract or minimalistic visual approach. For example, contrast distinctions through primary colors, icons, or shapes.
+
+  * _We have many:_ There will be a higher need for memorability and this is an opportunity to reflect a diverse population. You can use realistic digital renderings and introduce more visual components. For example, combine visual elements such as pairing a color palette with a realistic profile image to make each persona stand out notably within a set.
+
+* **Which option aligns better with my organization's brand or the product's aesthetic (especially if publishing or sharing user personas)?**
+
+  * _We use a clean, simple visual concept:_ Consider a more abstract or minimalistic approach to reflect branding consistency.
+
+  * _We use a photorealistic visual style:_ Consider more realistic images or digital renderings of individuals to reflect branding consistency.
+
+---
+
+### About the "Name or type" section
+
+Choosing names for your user personas is a worthwhile step in humanizing and streamlining communication around your user groups. Memorable names facilitate easy recall during discussions, while adding a personal touch to each user type's identity.
+
+For guidance on reflecting diversity within naming practices, see the introduction to [Contents of the User persona template](#contents-of-the-user-persona-template).
+
+The following are a few best practices for creating memorable user personas names:
+
+* **Pair a key attribute or descriptor with a name.**
+
+  * Combine a relevant attribute or adjective with a name. For example: Java Jesse, Newbie Niko
+
+* **Keep it short.**
+
+  * Choose short names or nicknames for simplicity. For example, "Developer Dan" is easier to remember and say than "Developer Daniel."
+
+* **Balance your use of gendered names.**
+
+  * Be mindful about balancing your selection of each gender traditionally associated with the names under consideration. When possible, consider erring towards gender-neutral options (for example: Alex or Jordan). Avoid excessive selection of one gender over another when naming (unless a specific gender is your target user base).
+
+---
+
+### About the "Dimension" section
+
+A dimension is a foundation for classifying divisions among user groups. It serves both as a fundamental boundary between groups and as a primary level through which to filter down to more specific attributes.
+
+From the list of attributes in the template (for example, _goals_, _needs_), choose the most significant attribute to elevate as a dimension relevant to your specific product or project's objective.
+
+For example, if your project is to make improvements to an existing feature that was poorly received by users, you might prioritize the attribute _pain points_ as your user persona dimension. Your next step is to identify which pain point distinguishes one user from another.
+
+Example user persona where the dimesion is _pain points:_
+> Frustrated Fiona
+>
+> **Pain point:** Resistant to changes in UI
+>
+> Confused Carl
+>
+> **Pain point:** Struggles to understand the release notes
+
+Typically, the dimension will remain the same across all or most of your user personas, unless you are conducting extensive user research for a large scale project with complex user personas.
+
+---
+
+### About the "Attributes" section
+
+An attribute is a secondary, shared characteristic among user groups. These are more granular than dimensions and are dependent upon them.
+
+For example, if you choose "experience level" as a dimension, an inexperienced user's attributes are all dependent on the context of being a new user: my goal (as a new user), my pain point (as a new user). Within each user persona, you can simply include a brief description or bulleted list of how the user persona fits the attribute, but you may also optionally consider a rank or scale to indicate the degree to which the attribute applies to the user persona if this serves your project's purpose. For example, Developer Dan is a level 2 when it comes to experience with your product, while Lead Lisa is a level 3).
+
+Select only the relevant attributes needed for your project. Some potential attributes included in the template are the following:
+
+* Goals
+
+* Needs
+
+* Pain points
+
+* Role
+
+* Experience level
+
+* Technical expertise
+
+* Use case
+
+* Thinking pattern
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our[feedback form](https://thegooddocsproject.dev/feedback/?template=User%20personas%20guide) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/user-personas/process_user-personas.md b/meta/reference/good-docs-project-template-1.5.0/user-personas/process_user-personas.md
new file mode 100644
index 00000000..dd2aef6f
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/user-personas/process_user-personas.md
@@ -0,0 +1,200 @@
+# User personas 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.
+
+Take a look at the following accompanying resources:
+
+* To fill out your relevant user characteristics into a structured template, explore the [User persona template](template_user-personas.md).
+
+* To see examples and explanations about how to fill in the User personas template, explore the [User persona template guide](guide_user-personas.md).
+
+* To read more from the sources that inspired and shaped our documents on user personas, explore our [User personas resources](resources_user-personas.md).
+
+## Introduction
+
+User personas are easier to create and offer more impact if you use a systematic process with checklists. This guide provides steps to build effective user personas.
+
+Follow the steps in this guide based on your project needs, existing knowledge of users, and business constraints. Each step adds more value and accuracy in detecting user needs, which will help shape insight-rich user personas. However, you might find some steps to be too resource-intensive, in which case, you can expedite or skip these steps if you confidently possess an understanding of your users.
+
+Despite your time or business limitations, any effort within each step is preferable to taking no action. The real value of user personas is in the process of creating them rather than the finished result. Any steps you take towards reflecting on your users' needs will put you ahead of where you previously were in your understanding.
+
+## Determine project goals
+
+Begin with a moment to brainstorm and write out your project's goals. Identify your goals first, so you can develop user personas that serve the specific context of your project.
+
+Your project goals influence which dimensions and attributes will be most important to select for your user personas.
+
+The following are some general examples of possible project goals:
+
+* **Product Development:** Guide the development of a product or features that align with the expectations and preferences of your intended users.
+
+* **Feature Prioritization:** Prioritize product features based on their impact and relevance to different user segments.
+
+* **Effective Communication:** Improve communication strategies by tailoring messages, content, and design to resonate with specific user segments.
+
+* **Innovation and Ideation:** Inspire innovation by identifying new opportunities and solutions based on user needs and pain points.
+
+* **Usability Testing:** Facilitate more effective usability testing sessions by tailoring scenarios and tasks to match the characteristics of different user personas.
+
+* **Training and learning development:** Personalize training experiences by aligning learning content with diverse backgrounds and learning preferences to optimize engagement and skill acquisition.
+
+Once you have established clear project goals for your desired outcome, you can plan how your user personas will best contribute to your ongoing project. Adapt the scale and timeframe of your user research and persona creation process to suit your own personal requirements.
+
+## Project sequence
+
+To get the most use out of your user personas, integrate them at the start of your project planning. Predict your user types during the initial stage of requirements analysis, and confirm your user personas through user research before implementing major design changes or reaching key project milestones.
+
+The following table is an example project sequence of where user personas fit within the information development cycle.
+
+| Project stage      | Description |
+| ----------- | ----------- |
+| Determine project goals| Identify key goals your project intends to accomplish.|
+| Survey existing user research | Look into which current user feedback data is available to you.|
+| Draft proto-personas | Brainstorm and outline a draft of your expected user personas. |
+| Validate user personas | Conduct user research by interviewing users or collecting their responses on surveys or questionnaires. |
+| Analyze results | Review user feedback data for patterns or key insights.|
+| Revise user personas | Add, eliminate, or modify user persona attributes and complete details for each attribute. |
+| Get feedback | Seek confirmation or feedback from your user community or internal stakeholders to ensure that your user personas are accurate. |
+| Maintain user personas | Update your user personas as needed, or measure impact.|
+
+## Survey existing user research
+
+Before conducting your own research, check first for any user research data that is available. If you work with anyone in user experience, product management, customer success, customer support, or usability, then they will likely be one of your best assets when developing user personas. Engage with these specialists or teams to gain access to user insights and feedback (such as survey results, interviews, or usability data). They may have already created user personas or valuable resources that can aid your project. If you open a line of communication with your resident user expert, you can leverage existing research.
+
+If you don't have access to up-to-date user research, try to find a cross-team member or internal stakeholder who can connect you directly with users so you can schedule interviews or send out questionnaires.
+
+If none of the above are options, you can reach out on relevant community forums, communication channels, or discussion boards to find active users who may be interested in sharing their feedback.
+
+## Draft proto-personas
+
+Out of all attributes you could use as criteria for defining your user groups, identify the most critical attribute(s) relevant to your project goals. This attribute can serve as more a significant measuring stick, or dimension, that you expect will classify all your user groups (for example, if my goal is to improve the onboarding process for users, I might choose "use case" as a dimension upon which to base my user personas).
+
+If it seems unclear which core attribute to choose for a dimension, you can always analyze the results of your user research to see which patterns emerge before committing to a dimension. It is also possible that you may decide to forgo using a dimension for your user personas, or find that there is more than a single dimension at play. User personas can be adapted to serve multiple purposes and applications, so their design is not one-size-fits-all. See more on selecting [dimensions](guide_user-personas.md#about-the-dimensions-section)
+
+Next, select relevant attributes for each user persona. You may brainstorm more attributes during the drafting phase, but will likely need to narrow these down as you finalize the user personas for use. See more on selecting [attributes](guide_user-personas.md#about-the-attributes-section).
+
+## Plan your user research method
+
+It's best to validate your user personas with real feedback data from users, even if you only have partial or minimal data. Comprehensive and quality user research offers the broadest and most thorough insights, but can be resource-intensive to achieve. Your own expertise and knowledge of users can count as data points, and may help you develop reasonably adequate user personas for your project needs. However, any amount of authentic user feedback (for example, an interview with a real user or a simple survey) is a better basis for a user persona when the alternative is to utilize no data from users. By the same token, an untested user persona, or "proto-persona," is preferable to zero user analysis.
+
+Here are a few questions to help you target productive results when planning your user research:
+
+### What is the scope of my project goals?
+
+**Long-term strategies, large-scale projects, or wide, cross-functional implications:**
+
+* Scale your user research to the large scope of your project. For projects involving long-term, overarching business decisions (for example, a branding strategy), broad-scoped, more generalized personas may be well-suited. Ensure your user research aligns with the extensive and diverse implications of the project.
+
+**Specific and precise product decisions:**
+
+* Scale your user research to the narrow scope of your project. Narrow-scoped personas are often more effective for specific product challenges and precise design decisions (for example, determining which examples or reference materials to include in user documentation). Tailor your user research to address the specific details and requirements of these focused decisions.
+
+### What research method should I use?
+
+**Comprehensive approach:**
+
+* The ideal way to conduct user research is to use varied approaches when collecting information and to get responses from a variety of users. If you are able to conduct extensive user research, try to gain both quantitative data (the higher the volume, the more accurate) and qualitative data (open-ended responses from users). Use a variety of techniques, such as questionnaires, interviews, usability testing, surveys, and field studies. Recruit participants with different backgrounds, experiences, and perspectives.
+
+**Balanced approach:**
+
+* This approach is for those who want to improve their knowledge of users and are able to conduct some user research. It may be tempting to prioritize a high volume of quantitative data over fewer pieces of qualitative user feedback, but it is worth choosing methods that remove degrees of separation between you, as the knowledge expert or creator, and your users. If you are able to, it is best to speak directly with a variety of users, preferably at least one from each dimension you've identified to get a balanced set of responses. The quality of open-ended feedback is often richer than quantitative methods, and you could gain an authentic understanding of users that far exceeds your expectations. In most cases, the true value of user personas is not in the end-profiles you create, but in the process of engaging with and gaining a deeper understanding of users. Interviews are an excellent way to gain this level of productive understanding.
+
+**Working knowledge reliant approach:**
+
+* This approach suits those who are not in a position to conduct user research or do not require further user research. If you are in this group, you may have a high-degree of working knowledge about your users because you have interacted with them directly. If this is the case, your knowledge could very well be sufficient for creating workable user personas that suit your needs. If this is not the case, and you are seeking more insight about your users, your best option would be to reach out to a cross-functional team or internal stakeholders who are either knowledgeable about your users or able to share user feedback data with you. See more on this from [Survey existing user research](#survey-exisiting-user-research).
+
+### How many users should I aim to receive feedback from?
+
+* Rather than quantity, the diversity of user type is more important to pursue in your research. You want to ensure that each meaningful category of users is discovered for your project. Rather than talking to five of the same kind of user, talking to two very different user types would be more productive for discerning and molding your user personas. Still, a user's experience can vary significantly from one another, even if both seem to fall within the same user group. For this reason, getting feedback from more, rather than fewer, users is preferable. Once you begin to see recurring patterns and repeated similarities in how your user types are responding, that means your user personas are shifting into clearer focus with distinct identities and opinions shared by multiple users within a given group.
+
+### What kinds of questions should I ask?
+
+* When you design interview questions or questionnaire items, compose open-ended questions that avoid leading questions where a desired answer is suggested. Frame questions neutrally to encourage honest and unbiased responses. Use prompts like "Tell me more about..." or "Can you describe how you...?
+
+* Key topics may include questions about users' needs, wants, preferred features, and any pain points they encounter with the product or documentation. You may also want to understand each user's experience level, domain knowledge, or technical expertise if that is an attribute you intend to include.
+
+## Validate user personas
+
+Conduct your user research according to your timeline. If you are interviewing users, start by briefly explaining the purpose of your research and how their participation will help improve your project or product. You may ask them permission to record the interview, or have a team member take notes during their responses. It's important to listen actively and allow space for the interviewee to share anything about their experience with your product. Some of the most valuable and candid responses can come from topical moments that may deviate from your interview script.
+
+If you are sending out a questionnaire, you may need to send it out more than once, each time with friendly reminders that note when the option to provide feedback closes. On one hand, you do not want to bombard your users with annoying emails or notifications. On the other hand, some users will appreciate the follow-up and happily share their perspective as long as they are given a margin of time and reminders to respond.
+
+Don't forget to thank your participants. If you've secured any tokens of appreciation (such as company swag, gift cards, or thank you messages) for their efforts, ensure that those are sent out. If you hold an open hour or post to a community board, you could inform interested participants to look for updates about your project there.
+
+## Analyze results
+
+Review your notes and research results to identify common themes, patterns, and unexpected responses. Confirm or adapt your expectations about who your users are and what they need.
+
+This is another point in the research process where confirmation bias can lessen the quality of your insights, so it's important to pay close attention to any evidence that challenges your assumptions. Another way to reduce the influence of bias is to involve multiple team members or stakeholders in the analysis and interpretation of the data you've acquired. Discuss findings with peers and colleagues who have different perspectives to challenge a single viewpoint.
+
+## Revise user personas
+
+Make adjustments to your proto-personas based on new insights from findings. You may notice new dimensions or an entire user type that was previously undetected. Add, eliminate, or rearrange user personas and their core attributes as needed.
+
+Fill in specific details and descriptions for each user persona's attributes. While our template provides a basic structure you can follow, this is also a good time to consider any unique elements you want to add as a means for distinguishing each user persona. For example, an additional element could be a quote or phrase from the perspective of the user persona that summarizes their character and helps immediately bring them to mind.
+
+## Get feedback
+
+Share a report or presentation of key findings from your user research with your user community, and invite any final feedback they would like to share. You can choose to share your user personas, data highlights, or both, depending on interest.
+
+If users can identify a user persona they feel reflects themselves, you've met your goal to create relevant personas. If real users do not recognize any personas that they can "fit" into, more revisions are possibly needed.
+
+Sharing key findings is a good way to establish trust and credibility with your users. It may boost community engagement, especially when users who took time to share their thoughts can see that their input has been acknowledged.
+
+Alternatively, if publishing your user personas is not within the scope of your project, you could seek any additional feedback from internal stakeholders as a check to ensure that your user personas are aligned with your business needs.
+
+## Maintain user personas
+
+If you are interested to see how your user personas have benefited your project, there are a few ways you can monitor the impact of your user personas. You could track user satisfaction, retention, or conversion. Another way would be to measure increases in community engagement. If none of these are realistic options, spend a bit of time reflecting on what went well during your user research and persona creation process, and any improvement you'd like to make if you were to create new user personas for another challenge.
+
+Once you've created and tested your user personas through research, they may only require small revisions to their attributes (such as a new use case or pain point) for upcoming projects, releases, and deployments. If user satisfaction significantly drops, or a major initiative or new launch is under planning, it may be time to revisit and re-test your user personas. Depending on your project needs, new user personas will need to be created and added to your set or outdated ones decommissioned.
+
+## Best practices for creating user personas
+
+As you follow the steps for creating user personas, consider these guidelines:
+
+* Maximize impact by creating fewer, distinct user personas with fundamentally different approaches to your product, rather than a multitude with subtle variations.
+
+* Ensure that your user personas are purpose-driven and specific to the context of your project needs or product design.
+
+* Focus on the most relevant attributes for your business case rather than an abundance of biographical details.
+
+* Base each user persona on current data from real users, not on imagined backstories.
+
+* Collect diverse user data or research from various user types to avoid confirmation bias.
+
+* Commit to maintaining an open mind; anticipate some findings will challenge your predictions.
+
+* Keep user personas up-to-date, revising them when new information arises or new projects are initiated.
+
+## Common mistakes to avoid
+
+### Form over function
+
+Personas originated in marketing and typically include demographic details like gender, ethnicity, age, or income to inform marketing messages. However, for teams that aim to understand product users, these details may or may not be relevant.
+
+It's common to see example of customer personas in the form of profiles with full biographical and demographic details. These biographical profiles are the result of a different purpose and context, and are not necessarily an effective formula for building user-centric personas. Relying on quantitative attributes for user personas can lead to a shallow model for assessing user needs. See a [comparison of customer personas and user personas](guide_user-personas.md#user-personas-compared-to-customer-personas).
+
+Unless demographic or biographical factors significantly impact your product's use (such as in the case of localization), basing a user persona on this type of information can create unnecessary divisions, while potentially overlooking the common needs that unite users. Similarly, composing elaborate backstories about users' lifestyles, histories, or personalities may improve a team's ability to empathize with users, but is not likely to address their needs.
+
+**Solution:** Prioritize deeper, qualitative user attributes that are more likely to directly influence user behavior (motivations, goals, attitude). An effective strategy is to balance and match quantitative with qualitative: for example, business role with use case, or experience level with pain points.
+
+### Top-down mandate
+
+Turning personas into an assignment for others to complete or insisting upon their use will result in frustration and skepticism. In siloed environments especially, not everyone will understand how to use personas in a successful way. Some may see personas as just busywork, or homework to complete, rather than a strategy that pays off in a better product.
+
+**Solution:**
+
+Share and showcase your practical use for user personas with your colleagues. Talk about them with the understanding that they are representations of real users, and suggest that they are a way to bring users' perspectives into your work. Offer the framework as a tool that support their work without imposing their use. When the opportunity arises, encourage a culture of appreciation and enthusiasm for the value user personas provide.
+
+### One-and-done
+
+A user persona is only as effective as its practical application. Simply creating user personas, only to discard them during project decisions, renders them insignificant and ornamental. Similarly, neglecting to update user personas can result in noticeably flawed and outdated products.
+
+**Solution:** Refer to user personas when making decisions at each stage of development, whenever needed. By regularly referencing and updating user personas, teams can ensure that they remain relevant and reflective of user needs and expectations.
+
+Continue to listen to users by collecting user research and update your user personas when time allows. That way, any changes you make to your product or service will be true to what users want.
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=User%20personas%20process) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/user-personas/resources_user-personas.md b/meta/reference/good-docs-project-template-1.5.0/user-personas/resources_user-personas.md
new file mode 100644
index 00000000..9cdd1408
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/user-personas/resources_user-personas.md
@@ -0,0 +1,48 @@
+# User personas 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.
+
+Take a look at the following accompanying resources:
+
+* For step-by-step guidance on creating user personas, explore our [User personas process](process_user-personas.md).
+
+* To fill out your user characteristics into a structured template, explore the [User persona template](template_user-personas.md).
+
+* To see examples and explanations about how to fill in the User personas template, explore the [User persona template guide](guide_user-personas.md).
+
+## Examples of user personas
+
+The following high-quality examples of user personas inspired this template and can help you see examples of effective user personas in action:
+
+* **[User Persona Examples, Tips and Tools](https://www.konrad.com/research/user-persona):** Includes an example structure for user personas.
+* **[User Persona: Everything You Need to Know](https://www.wowmakers.com/blog/user-persona/)**: Includes multiple examples of user personas.
+
+## Resources
+
+* [UX Research Cheat Sheet](https://www.nngroup.com/articles/ux-research-cheat-sheet/): Steps and best practices for conducting user research.
+* [A Guide to Using User-Experience Research Methods](https://www.nngroup.com/articles/guide_ux-research-methods/): Methods and terminology for user research.
+* [A Closer Look At Personas: What They Are And How They Work (Part 1)](https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/) : Overview of personas with definition, purpose, and effectiveness.
+* [A Closer Look At Personas: A Guide To Developing The Right Ones (Part 2)](https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-2/): Examples of interview questions for user research.
+* [Empathy Mapping: The First Step in Design Thinking](https://www.nngroup.com/articles/empathy-mapping/): An exercise for fostering empathy for users before, during, or after user personas are created.
+* [Avataaars Generator](https://getavataaars.com/): A basic generator for digital avatars to visually represent your user personas.
+
+## 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        | Description  |
+|---------------|--------------|
+| Microsoft: [Personas: Practice and Theory](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/03/pruitt-grudinold.pdf) | Definition: personas are first and foremost a tool for communication among teams. |
+| Nielsen Norman Group: [Personas Make Users Memorable for Product Team Members](https://www.nngroup.com/articles/persona/) | The benefits of using personas.|
+| UX Matters: [Using Personas During Design and Documentation](https://www.uxmatters.com/mt/archives/2010/10/using-personas-during-design-and-documentation.php) | Example sequence for using user personas during a documentation project. |
+| Heavybit: [Using User Research as a Pre-Product-Market Fit Tactic](https://www.heavybit.com/library/article/user-research-product-market-fit-tactic/) | The dos and don'ts of navigating user research. |
+| UX Planet: [Understanding Your Users: A Comprehensive Guide to Creating Effective User Personas](https://uxplanet.org/understanding-your-users-a-comprehensive-guide_to-creating-effective-user-personas-b3f347113749) | Mixing qualitative and quantitative data from user research is a good way to gain a more complete understanding of user perspectives. |
+| CXL: [How to Build Robust User Personas in Under a Month](https://cxl.com/blog/user-personas/) | How to use surveys and quantitative data for creating user personas. |
+| Nick Stiles: [Why User Personas Aren't User-Friendly & How to Fix Them](https://medium.com/design-ibm/why-user-personas-arent-user-friendly-how-to-fix-them-33d27d392d60#:~:text=Without%20them%2C%20%E2%80%9Cthe%20user%E2%80%9D,needs%2C%20goals%2C%20and%20motivations) | Prioritize form over function when creating personas. |
+| Nielsen Norman Group: [Why personas fail](https://www.nngroup.com/articles/why-personas-fail/)| Adapt your personas to the scope of your project. |
+| Christin Roman: [The Problems with Personas](https://medium.com/typecode/the-problem-with-personas-b6734a08d37a) | Common mistakes when working with personas. |
+| Matt Eland: [Personas in Writing](https://dev.to/integerman/personas-in-writing-1mk8) | An example use of personas for writing purposes. |
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=User%20personas%20resources) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/user-personas/template_user-personas.md b/meta/reference/good-docs-project-template-1.5.0/user-personas/template_user-personas.md
new file mode 100644
index 00000000..8df01601
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/user-personas/template_user-personas.md
@@ -0,0 +1,187 @@
+# User personas template
+
+This template includes writing instructions and boilerplate text that you can customize, use as-is, or replace with your own text. This text is indicated in {curly brackets}. Make sure you replace the placeholders with your own text.
+
+Take a look at the following accompanying resources:
+
+* For step-by-step guidance on creating user personas, explore our [User personas process](process_user-personas.md).
+
+* To see examples and explanations about how to fill in this template, explore the [User persona template guide](guide_user-personas.md).
+
+* To read more from the sources that inspired and shaped our documents on user personas, explore our [User personas resources](resources_user-personas.md).
+
+## {Optional: Visual representation of first user persona}
+
+## {Name or type of first user persona}
+
+{Use the [Process guide](process_user-personas.md)to help inform your selection process for the dimension and attributes. Choose the most important item from the following options for the dimension and remove it from the list. Keep the most relevant items as user persona attributes and eliminate unnecessary items for your project.}
+
+### {Dimension: description}
+
+**Goals:**
+
+* {Describe the persona's primary motivation, objective, purpose, or values.}
+* {Describe the persona's secondary motivation, objective, purpose, or values.}
+* {Describe the persona's tertiary motivation, objective, purpose, or values.}
+
+**Needs:**
+
+* {Describe the persona's primary requirements or desired capability.}
+* {Describe the persona's secondary requirements or desired capability.}
+* {Describe the persona's tertiary requirements or desired capability.}
+
+**Pain points:**
+
+* {Describe the persona's primary difficulties, challenges, or problems.}
+* {Describe the persona's secondary difficulties, challenges, or problems.}
+* {Describe the persona's tertiary difficulties, challenges, or problems.}
+
+**Role:**
+
+* {Describe the persona's primary business title or responsibilities.}
+* {Describe the persona's secondary role or responsibilities.}
+* {Describe the persona's tertiary role or responsibilities.}
+
+**Experience level:**
+
+* {Describe the persona's primary knowledge background, education, or comfort with product.}
+* {Describe the persona's secondary knowledge background, education, or comfort with product.}
+* {Describe the persona's tertiary knowledge background, education, or comfort with product.}
+
+**Technical expertise:**
+
+* {Describe the persona's primary competencies, preferred operating systems, interfaces, or programming languages.}
+* {Describe the persona's secondary competencies, preferred operating systems, interfaces, or programming languages.}
+* {Describe the persona's tertiary competencies, preferred operating systems, interfaces, or programming languages.}
+
+**Use case:**
+
+* {Describe the persona's primary tasks to perform.}
+* {Describe the persona's secondary tasks to perform.}
+* {Describe the persona's tertiary tasks to perform.}
+
+**Thinking pattern:**
+
+* {Describe the persona's primary mindset, approach to tasks, or tolerance or aversion toward _x._}
+* {Describe the persona's secondary mindset, approach to tasks, or tolerance or aversion toward _x._}
+* {Describe the persona's tertiary mindset, approach to tasks, or tolerance or aversion toward _x._}
+
+---
+
+## {Optional: Visual representation of second user persona}
+
+## {Name or type of second user persona}
+
+{Use the [Process guide](guide_user-personas.md)to help inform your selection process for the dimension and attributes. Choose the most important item from the following options for the dimension and remove it from the list. Keep the most relevant items as user persona attributes and eliminate unnecessary items for your project.}
+
+### {Dimension: description}
+
+**Goals:**
+
+* {Describe the persona's primary motivation, objective, purpose, or values.}
+* {Describe the persona's secondary motivation, objective, purpose, or values.}
+* {Describe the persona's tertiary motivation, objective, purpose, or values.}
+
+**Needs:**
+
+* {Describe the persona's primary requirements or desired capability.}
+* {Describe the persona's secondary requirements or desired capability.}
+* {Describe the persona's tertiary requirements or desired capability.}
+
+**Pain points:**
+
+* {Describe the persona's primary difficulties, challenges, or problems.}
+* {Describe the persona's secondary difficulties, challenges, or problems.}
+* {Describe the persona's tertiary difficulties, challenges, or problems.}
+
+**Role:**
+
+* {Describe the persona's primary business title or responsibilities.}
+* {Describe the persona's secondary role or responsibilities.}
+* {Describe the persona's tertiary role or responsibilities.}
+
+**Experience level:**
+
+* {Describe the persona's primary knowledge background, education, or comfort with product.}
+* {Describe the persona's secondary knowledge background, education, or comfort with product.}
+* {Describe the persona's tertiary knowledge background, education, or comfort with product.}
+
+**Technical expertise:**
+
+* {Describe the persona's primary competencies, preferred operating systems, interfaces, or programming languages.}
+* {Describe the persona's secondary competencies, preferred operating systems, interfaces, or programming languages.}
+* {Describe the persona's tertiary competencies, preferred operating systems, interfaces, or programming languages.}
+
+**Use case:**
+
+* {Describe the persona's primary tasks to perform.}
+* {Describe the persona's secondary tasks to perform.}
+* {Describe the persona's tertiary tasks to perform.}
+
+**Thinking pattern:**
+
+* {Describe the persona's primary mindset, approach to tasks, or tolerance or aversion toward _x._}
+* {Describe the persona's secondary mindset, approach to tasks, or tolerance or aversion toward _x._}
+* {Describe the persona's tertiary mindset, approach to tasks, or tolerance or aversion toward _x._}
+
+---
+
+## {Optional: Visual representation of third user persona}
+
+## {Name or type of third user persona}
+
+{Use the [Process guide](guide_user-personas.md) to help inform your selection process for the dimension and attributes. Choose the most important item from the following options for the dimension and remove it from the list. Keep the most relevant items as user persona attributes and eliminate unnecessary items for your project.}
+
+### {Dimension: description}
+
+**Goals:**
+
+* {Describe the persona's primary motivation, objective, purpose, or values.}
+* {Describe the persona's secondary motivation, objective, purpose, or values.}
+* {Describe the persona's tertiary motivation, objective, purpose, or values.}
+
+**Needs:**
+
+* {Describe the persona's primary requirements or desired capability.}
+* {Describe the persona's secondary requirements or desired capability.}
+* {Describe the persona's tertiary requirements or desired capability.}
+
+**Pain points:**
+
+* {Describe the persona's primary difficulties, challenges, or problems.}
+* {Describe the persona's secondary difficulties, challenges, or problems.}
+* {Describe the persona's tertiary difficulties, challenges, or problems.}
+
+**Role:**
+
+* {Describe the persona's primary business title or responsibilities.}
+* {Describe the persona's secondary role or responsibilities.}
+* {Describe the persona's tertiary role or responsibilities.}
+
+**Experience level:**
+
+* {Describe the persona's primary knowledge background, education, or comfort with product.}
+* {Describe the persona's secondary knowledge background, education, or comfort with product.}
+* {Describe the persona's tertiary knowledge background, education, or comfort with product.}
+
+**Technical expertise:**
+
+* {Describe the persona's primary competencies, preferred operating systems, interfaces, or programming languages.}
+* {Describe the persona's secondary competencies, preferred operating systems, interfaces, or programming languages.}
+* {Describe the persona's tertiary competencies, preferred operating systems, interfaces, or programming languages.}
+
+**Use case:**
+
+* {Describe the persona's primary tasks to perform.}
+* {Describe the persona's secondary tasks to perform.}
+* {Describe the persona's tertiary tasks to perform.}
+
+**Thinking pattern:**
+
+* {Describe the persona's primary mindset, approach to tasks, or tolerance or aversion toward _x._}
+* {Describe the persona's secondary mindset, approach to tasks, or tolerance or aversion toward _x._}
+* {Describe the persona's tertiary mindset, approach to tasks, or tolerance or aversion toward _x._}
+
+---
+
+> Explore other templates from [The Good Docs Project](https://gitlab.com/tgdp/templates). Use our [feedback form](https://thegooddocsproject.dev/feedback/?template=User%20personas%20template) to give feedback on this template.
diff --git a/meta/reference/good-docs-project-template-1.5.0/writing-tips.md b/meta/reference/good-docs-project-template-1.5.0/writing-tips.md
new file mode 100644
index 00000000..f96ec62e
--- /dev/null
+++ b/meta/reference/good-docs-project-template-1.5.0/writing-tips.md
@@ -0,0 +1,60 @@
+# General writing guidelines
+
+Follow these writing guidelines when developing content using the templates available in this repository.
+
+## Language and tone
+
+* Use consistent language, spelling, and tone throughout your docs.
+* Describe things as clearly and accurately as possible.
+* Run your text through a grammar [linter](https://en.wikipedia.org/wiki/Lint_(software)) to check how readable it is.
+  * Tools like Grammarly help you identify grammar issues
+  * Tools like `Vale` help you identify style issues. ([This article](https://hackernoon.com/lint-lint-and-away-linters-for-the-english-language-70f4b22cc73c) includes a list of other linter tools.)
+* Avoid colloquialisms and jargon because it makes it harder for a non-native English speaker to understand your words.
+* Avoid including acronyms in your documentation without writing the spelled-out form on the first use. You can use the acronym for subsequent references.
+* Avoid adding your own opinions, or the opinions of others. Doing this clouds a reader's ability to draw conclusions from the documentation.
+
+## Writing procedural steps
+
+Here are some recommendations you can use when creating procedural steps:
+
+* For procedures with numerous steps, consider "chunking" content into sub-sections of 5-10 steps. It makes the information easier to read and remember, and gives the reader a sense of accomplishment after each chunk is completed. Chunking is recommended by major companies, such as in [Microsoft's writing style guide](https://docs.microsoft.com/en-us/style-guide/procedures-instructions/writing-step-by-step-instructions#complex-procedures), and from the Nielsen Norman Group's [research on chunking and usability](https://www.nngroup.com/articles/short-term-memory-and-web-usability/).
+* Each step is a single sentence (you should be able to read it aloud, and it should make grammatical sense).
+* When describing a step, include a lead-in sentence to remind the reader what they will be doing when following the sub-steps.
+* Aim for no more than four sub-steps in any primary step.
+* If you are indenting sub-steps beyond one indent level, break out your steps into a new main step block.
+* Too many sub-steps could suggest that you need to break out some of these steps into a new step section.
+* Screenshots and images are recommended, particularly if you can include call outs to the specific parts of the screen you are referring to.
+* Identify steps that are optional by using typing _Optional_ followed by a colon. For example,
+  * Optional: Enter a description for your repository.
+* Use conditional clause _if (condition) then (result)_  to identify steps that are applicable only if certain criteria apply. Always start the conditional steps with a condition so that users who do not meet the condition can skip the step. For example,
+  * If you are a Windows user, then install the VM VirtualBox software on your machine.
+
+For more information on writing procedures, see [Google developer documentation style guide.](https://developers.google.com/style/procedures)
+
+## Page structure
+
+* Create an outline of the headings you want to include in the document before you start writing.
+  * Use the outline to gather your thoughts about the main topics you need to tell your readers.
+  * It's a lot easier to move things around with headings than to move blocks of content.
+* You may also find that you need to create two articles if the subject starts to branch.
+* Add any links you mention in the body of your content into the "See also" section. The inline links may get lost in long articles, and scanning for links adds to your audience's cognitive load.
+
+## Titles and filenames
+
+* Make the title descriptive of the content contained within the article.
+* Make the title unique within your application space.
+* Make the title and filename the same: it makes it difficult to identify the file name when the title and filename differ.
+* Use unique words in titles so you can search and replace text later on without getting fuzzy matches.
+
+Here are some title examples and their suggested file name structures:
+
+* Using a toaster
+  * `using-a-toaster.md`
+  * `using-a-toaster.adoc`
+* Toast a slice of bread
+  * `toast-slice-of-bread.md`
+  * `toast-slice-of-bread.adoc`
+
+## Definitions
+
+If you are repeatedly using terms throughout a large article, you can define them once and then use them repeatedly in the body of the article.

From bedb991d55c936fffcb3a54cd9b8c13e2cad847e Mon Sep 17 00:00:00 2001
From: Inline Pizza <249805557+InlinePizza@users.noreply.github.com>
Date: Tue, 28 Apr 2026 16:09:40 -0700
Subject: [PATCH 2/3] Improve Promptless docs welcome flow

---
 .../docs/docs/getting-started/welcome.mdx     | 162 +++++---
 src/lib/generated/route-manifest.json         | 349 +++++++++++++-----
 src/styles/custom.css                         |   9 +
 3 files changed, 366 insertions(+), 154 deletions(-)

diff --git a/src/content/docs/docs/getting-started/welcome.mdx b/src/content/docs/docs/getting-started/welcome.mdx
index 50d448b8..3bc9b1e2 100644
--- a/src/content/docs/docs/getting-started/welcome.mdx
+++ b/src/content/docs/docs/getting-started/welcome.mdx
@@ -1,94 +1,134 @@
 ---
-title: Your Docs on Autopilot
-description: >-
-  Automated docs that eliminate manual overhead and keep your docs current with
-  your codebase
+title: Promptless Overview
+description: Learn what Promptless does, how it works, and where to start.
 slug: docs/getting-started/welcome
 sidebar:
   hidden: false
   order: 1
 ---
-import Card from '@components/fern/Card.astro';
-import CardGroup from '@components/fern/CardGroup.astro';
+import { Card, CardGrid, LinkCard, Steps } from '@astrojs/starlight/components';
 import Info from '@components/fern/Info.astro';
+import VideoEmbed from '@components/site/VideoEmbed.astro';
 
 
 All content on this docs site was generated by Promptless. See how in our public docs repo.
 
 
-Promptless automatically generates and updates docs based on your existing product and development workflows. No more undocumented new features, or out-of-date docs that confuse your customers—just fresh, accurate docs that evolve with your product effortlessly.
+Promptless is an AI agent built to support technical writers by detecting when docs need to change, gathering context from code and team tools, drafting updates, and opening reviewable suggestions or pull requests.
 
-
        
-  
-    Learn about Promptless 1.0, how it works, customer success stories from Vellum, Amplitude, and Vitess, and what's included in this release—from citations, auto-updating screenshots, and more.
-  
+Use Promptless to keep product docs, internal docs, screenshots, changelogs, and support-driven documentation current as your team ships.
+
+
        
+  
 
        
 
-
-  
-    Eliminate docs debt by automatically catching when code changes require doc updates, without disrupting your development workflow.
+Watch a short walkthrough of Promptless turning a product change into a documentation pull request. The demo shows Promptless finding the relevant docs, using code and project context, drafting an update with citations, and handing the change back to a technical writer for review.
+
+## What You Can Do
+
+
        
+
+  
+    Detect when pull requests, commits, or releases change behavior that customers need to understand.
+  
+
+  
+    Draft new pages, guides, API references, changelog entries, and release notes from the context your team already has.
+  
+
+  
+    Turn repeated customer questions, support tickets, Slack threads, and project tickets into documentation updates.
+  
+
+  
+    Ask Promptless to capture new product screenshots or regenerate stale images when your UI changes.
   
-  
-  
-    Focus on information architecture and strategy while Promptless handles the routine updates and maintenance of your docs.
+
+  
+    Check the sources Promptless used, request edits, and teach Promptless your preferred structure and style.
   
-
+
+  
+    Open documentation pull requests for docs-as-code platforms like Mintlify, Fern, ReadMe, Docusaurus, and more.
+  
+
+
        
 
 ## How Promptless Works
 
-Promptless operates through three interconnected components that work together to understand your codebase, gather context, and publish updates automatically.
+Promptless fits into the tools your team already uses. A typical documentation update follows this flow:
 
 ![Mermaid diagram](/mermaid/d2933d7a21837f25.svg)
 
-
-  
-    Monitor your development ecosystem for events that indicate documentation needs—from pull requests and code changes to team discussions.
-  
-  
-  
-    Enrich docs with real-time access to your organization's knowledge through integrations with project management tools, code repositories, and team communications.
-  
-  
-  
-    Publish updates to your Git-hosted documentation platforms—Fern, Mintlify, ReadMe, Docusaurus, GitBook, and more.
-  
-
+
+  
          
+    
        1. 
+      A trigger starts the workflow. A pull request, commit, Slack message, Teams message, Intercom ticket, or API event tells Promptless to investigate whether docs need to change.
+    
          2. 
+    
        2. 
+      Promptless gathers context. Promptless reads the relevant code, existing docs, tickets, conversations, and configured context sources.
+    
          3. 
+    
        3. 
+      Promptless drafts a suggestion. Promptless decides which pages are affected, writes the proposed update, and explains the sources behind the change.
+    
          4. 
+    
        4. 
+      Your team reviews the update. Review the suggestion in Promptless, comment in GitHub, or ask for follow-up edits in Slack or Microsoft Teams.
+    
          5. 
+    
        5. 
+      Promptless publishes through your docs workflow. When the update is ready, Promptless opens or updates a documentation pull request for your normal review and merge process.
+    
          6. 
+  
        
+        
 
-## Key Benefits
+## Common Starting Points
 
-
-  
-    Docs updates happen automatically when code changes, eliminating manual monitoring and reducing the risk of outdated information.
-  
-  
-  
-    Deep integration with your existing tools means Promptless understands your organization's specific terminology, processes, and doc styles.
-  
-  
-  
-    SOC 2 compliant infrastructure with OAuth integration, role-based access controls, and encryption at rest and in transit.
-  
-  
-  
-    Bridges communication gaps between product, engineering, and technical writing teams by automatically detecting when releases impact docs.
-  
-
+
+  
+
+  
+
+  
+
+  
+
 
 ## Next Steps
 
-
-  
-    Get Promptless running with your repositories and communication tools in under 10 minutes.
-  
+
+  
 
-  
-    Understand how triggers, context sources, and publishing platforms work together.
-  
+  
 
-  
-    Explore all available integrations and configure them for your specific needs.
-  
-
+  
+
 
 
        
   Want to see Promptless in action? Book a demo.
diff --git a/src/lib/generated/route-manifest.json b/src/lib/generated/route-manifest.json
index a909ef58..470e3751 100644
--- a/src/lib/generated/route-manifest.json
+++ b/src/lib/generated/route-manifest.json
@@ -3,12 +3,12 @@
     "sourcePath": "src/content/docs/docs/getting-started/welcome.mdx",
     "contentType": "docs",
     "routePath": "/docs/getting-started/welcome",
-    "title": "Your Docs on Autopilot",
+    "title": "Promptless Overview",
     "hidden": false,
     "order": 1,
     "section": "Getting Started",
     "tab": "docs",
-    "description": "Automated docs that eliminate manual overhead and keep your docs current with your codebase"
+    "description": "Learn what Promptless does, how it works, and where to start."
   },
   {
     "sourcePath": "src/content/docs/docs/getting-started/promptless-1-0.mdx",
@@ -102,30 +102,30 @@
     "tab": "docs"
   },
   {
-    "sourcePath": "src/content/docs/docs/configuring-promptless/triggers/slack-messages.mdx",
+    "sourcePath": "src/content/docs/docs/configuring-promptless/triggers/git-hub-issues.mdx",
     "contentType": "docs",
-    "routePath": "/docs/configuring-promptless/triggers/slack-messages",
-    "title": "Slack Messages",
+    "routePath": "/docs/configuring-promptless/triggers/git-hub-issues",
+    "title": "GitHub Issues",
     "hidden": false,
     "order": 11,
     "section": "Configuring Promptless",
     "tab": "docs"
   },
   {
-    "sourcePath": "src/content/docs/docs/configuring-promptless/triggers/microsoft-teams-messages.mdx",
+    "sourcePath": "src/content/docs/docs/configuring-promptless/triggers/slack-messages.mdx",
     "contentType": "docs",
-    "routePath": "/docs/configuring-promptless/triggers/microsoft-teams-messages",
-    "title": "Microsoft Teams Messages (Beta)",
+    "routePath": "/docs/configuring-promptless/triggers/slack-messages",
+    "title": "Slack Messages",
     "hidden": false,
     "order": 12,
     "section": "Configuring Promptless",
     "tab": "docs"
   },
   {
-    "sourcePath": "src/content/docs/docs/configuring-promptless/triggers/zendesk-tickets-beta.mdx",
+    "sourcePath": "src/content/docs/docs/configuring-promptless/triggers/microsoft-teams-messages.mdx",
     "contentType": "docs",
-    "routePath": "/docs/configuring-promptless/triggers/zendesk-tickets-beta",
-    "title": "Zendesk Tickets (Beta)",
+    "routePath": "/docs/configuring-promptless/triggers/microsoft-teams-messages",
+    "title": "Microsoft Teams Messages (Beta)",
     "hidden": false,
     "order": 13,
     "section": "Configuring Promptless",
@@ -171,13 +171,24 @@
     "section": "Configuring Promptless",
     "tab": "docs"
   },
+  {
+    "sourcePath": "src/content/docs/docs/configuring-promptless/customizing-notifications.mdx",
+    "contentType": "docs",
+    "routePath": "/docs/configuring-promptless/customizing-notifications",
+    "title": "Customizing Notifications",
+    "hidden": false,
+    "order": 18,
+    "section": "Configuring Promptless",
+    "tab": "docs",
+    "description": "Configure how Promptless notifies your team about documentation suggestions"
+  },
   {
     "sourcePath": "src/content/docs/docs/configuring-promptless/context-sources/jira.mdx",
     "contentType": "docs",
     "routePath": "/docs/configuring-promptless/context-sources/jira",
     "title": "Jira",
     "hidden": false,
-    "order": 18,
+    "order": 19,
     "section": "Configuring Promptless",
     "tab": "docs"
   },
@@ -187,7 +198,7 @@
     "routePath": "/docs/configuring-promptless/context-sources/confluence",
     "title": "Confluence",
     "hidden": false,
-    "order": 19,
+    "order": 20,
     "section": "Configuring Promptless",
     "tab": "docs"
   },
@@ -197,7 +208,7 @@
     "routePath": "/docs/configuring-promptless/doc-collections/how-promptless-learns-your-docs",
     "title": "How Promptless Learns Your Docs",
     "hidden": false,
-    "order": 20,
+    "order": 21,
     "section": "Configuring Promptless",
     "tab": "docs"
   },
@@ -207,7 +218,7 @@
     "routePath": "/docs/configuring-promptless/doc-collections/git-hub-repos-docs-as-code",
     "title": "GitHub Repos (Docs as Code)",
     "hidden": false,
-    "order": 21,
+    "order": 22,
     "section": "Configuring Promptless",
     "tab": "docs"
   },
@@ -217,7 +228,7 @@
     "routePath": "/docs/how-to-use-promptless",
     "title": "How to use Promptless",
     "hidden": false,
-    "order": 22,
+    "order": 23,
     "section": "How To Use Promptless",
     "tab": "docs",
     "description": "Learn about the different ways to interact with Promptless and leverage its documentation automation capabilities"
@@ -228,7 +239,7 @@
     "routePath": "/docs/how-to-use-promptless/working-with-slack",
     "title": "Working with Slack",
     "hidden": false,
-    "order": 23,
+    "order": 24,
     "section": "How To Use Promptless",
     "tab": "docs",
     "description": "Learn how to use Promptless directly in Slack through message actions, DMs, channel mentions, and passive listening"
@@ -239,7 +250,7 @@
     "routePath": "/docs/how-to-use-promptless/interacting-with-promptless-p-rs",
     "title": "Interacting with Promptless PRs",
     "hidden": false,
-    "order": 24,
+    "order": 25,
     "section": "How To Use Promptless",
     "tab": "docs",
     "description": "Learn how to provide follow-up instructions through GitHub PR comments and reviews after your documentation PR is opened"
@@ -250,7 +261,7 @@
     "routePath": "/docs/how-to-use-promptless/using-the-web-interface",
     "title": "Using the Web Interface",
     "hidden": false,
-    "order": 25,
+    "order": 26,
     "section": "How To Use Promptless",
     "tab": "docs",
     "description": "Learn how to use Promptless's web interface to highlight text, provide feedback, and guide documentation improvements"
@@ -261,28 +272,70 @@
     "routePath": "/docs/how-to-use-promptless/providing-feedback",
     "title": "Providing Feedback",
     "hidden": false,
-    "order": 26,
+    "order": 27,
     "section": "How To Use Promptless",
     "tab": "docs",
     "description": "Learn all the ways to provide feedback on Promptless documentation suggestions"
   },
+  {
+    "sourcePath": "src/content/docs/docs/how-to-use-promptless/deep-analysis.mdx",
+    "contentType": "docs",
+    "routePath": "/docs/how-to-use-promptless/deep-analysis",
+    "title": "Deep Analysis",
+    "hidden": false,
+    "order": 28,
+    "section": "How To Use Promptless",
+    "tab": "docs",
+    "description": "Submit large, complex documentation requests that may take extended processing time and create multiple suggestions"
+  },
+  {
+    "sourcePath": "src/content/docs/docs/how-to-use-promptless/managing-environment-variables.mdx",
+    "contentType": "docs",
+    "routePath": "/docs/how-to-use-promptless/managing-environment-variables",
+    "title": "Managing Environment Variables",
+    "hidden": false,
+    "order": 29,
+    "section": "How To Use Promptless",
+    "tab": "docs"
+  },
   {
     "sourcePath": "src/content/docs/docs/integrations.mdx",
     "contentType": "docs",
     "routePath": "/docs/integrations",
     "title": "Integrations",
     "hidden": false,
-    "order": 27,
+    "order": 30,
     "section": "Integrations",
     "tab": "docs"
   },
+  {
+    "sourcePath": "src/content/docs/docs/how-to-use-promptless/agent-knowledge-base.mdx",
+    "contentType": "docs",
+    "routePath": "/docs/how-to-use-promptless/agent-knowledge-base",
+    "title": "Agent Knowledge Base",
+    "hidden": false,
+    "order": 31,
+    "section": "How To Use Promptless",
+    "tab": "docs",
+    "description": "View and edit the files that help Promptless understand your documentation style, product context, and workflow preferences"
+  },
+  {
+    "sourcePath": "src/content/docs/docs/how-to-use-promptless/using-promptless-capture.mdx",
+    "contentType": "docs",
+    "routePath": "/docs/how-to-use-promptless/using-promptless-capture",
+    "title": "Using Promptless Capture",
+    "hidden": false,
+    "order": 32,
+    "section": "How To Use Promptless",
+    "tab": "docs"
+  },
   {
     "sourcePath": "src/content/docs/docs/integrations/bitbucket-integration.mdx",
     "contentType": "docs",
     "routePath": "/docs/integrations/bitbucket-integration",
     "title": "Bitbucket Integration",
     "hidden": false,
-    "order": 28,
+    "order": 33,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -292,7 +345,7 @@
     "routePath": "/docs/integrations/github-integration",
     "title": "GitHub Integration",
     "hidden": false,
-    "order": 29,
+    "order": 34,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -302,7 +355,7 @@
     "routePath": "/docs/integrations/github-enterprise-integration",
     "title": "GitHub Enterprise Integration",
     "hidden": false,
-    "order": 30,
+    "order": 35,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -312,7 +365,7 @@
     "routePath": "/docs/integrations/atlassian-integration",
     "title": "Atlassian Integration",
     "hidden": false,
-    "order": 31,
+    "order": 36,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -322,7 +375,7 @@
     "routePath": "/docs/integrations/linear-integration",
     "title": "Linear Integration",
     "hidden": false,
-    "order": 32,
+    "order": 37,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -332,7 +385,7 @@
     "routePath": "/docs/integrations/slack-integration",
     "title": "Slack Integration",
     "hidden": false,
-    "order": 33,
+    "order": 38,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -342,17 +395,7 @@
     "routePath": "/docs/integrations/microsoft-teams-integration",
     "title": "Microsoft Teams Integration (Beta)",
     "hidden": false,
-    "order": 34,
-    "section": "Integrations",
-    "tab": "docs"
-  },
-  {
-    "sourcePath": "src/content/docs/docs/integrations/zendesk-integration.mdx",
-    "contentType": "docs",
-    "routePath": "/docs/integrations/zendesk-integration",
-    "title": "Zendesk Integration (Beta)",
-    "hidden": false,
-    "order": 35,
+    "order": 39,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -362,7 +405,7 @@
     "routePath": "/docs/integrations/intercom-integration-beta",
     "title": "Intercom Integration (Beta)",
     "hidden": false,
-    "order": 36,
+    "order": 40,
     "section": "Integrations",
     "tab": "docs"
   },
@@ -372,7 +415,7 @@
     "routePath": "/docs/account-management/account-management",
     "title": "Account Management",
     "hidden": false,
-    "order": 37,
+    "order": 41,
     "section": "Account Management",
     "tab": "docs"
   },
@@ -382,7 +425,7 @@
     "routePath": "/docs/security-and-privacy",
     "title": "Security and Privacy",
     "hidden": false,
-    "order": 38,
+    "order": 42,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -392,7 +435,7 @@
     "routePath": "/docs/security-and-privacy/single-sign-on-sso-setup",
     "title": "Single Sign-On (SSO) Setup",
     "hidden": false,
-    "order": 39,
+    "order": 43,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -402,7 +445,7 @@
     "routePath": "/docs/security-and-privacy/compliance-and-certifications",
     "title": "Compliance and Certifications",
     "hidden": false,
-    "order": 40,
+    "order": 44,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -412,7 +455,7 @@
     "routePath": "/docs/security-and-privacy/data-handling-and-classification",
     "title": "Data Handling and Classification",
     "hidden": false,
-    "order": 41,
+    "order": 45,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -422,7 +465,7 @@
     "routePath": "/docs/security-and-privacy/network-architecture",
     "title": "Network Architecture",
     "hidden": false,
-    "order": 42,
+    "order": 46,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -432,7 +475,7 @@
     "routePath": "/docs/security-and-privacy/promptless-subprocessors",
     "title": "Promptless Subprocessors",
     "hidden": false,
-    "order": 43,
+    "order": 47,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -442,7 +485,7 @@
     "routePath": "/docs/security-and-privacy/privacy-policy",
     "title": "Privacy Policy",
     "hidden": false,
-    "order": 44,
+    "order": 48,
     "section": "Security And Privacy",
     "tab": "docs"
   },
@@ -452,7 +495,7 @@
     "routePath": "/docs/frequently-asked-questions/frequently-asked-questions",
     "title": "Frequently Asked Questions",
     "hidden": false,
-    "order": 45,
+    "order": 49,
     "section": "Frequently Asked Questions",
     "tab": "docs"
   },
@@ -462,7 +505,7 @@
     "routePath": "/docs/frequently-asked-questions/recommended-docs-providers",
     "title": "Recommended Documentation Providers",
     "hidden": true,
-    "order": 46,
+    "order": 50,
     "section": "Frequently Asked Questions",
     "tab": "docs"
   },
@@ -472,7 +515,7 @@
     "routePath": "/docs/self-hosting",
     "title": "Self-Hosting Overview",
     "hidden": true,
-    "order": 47,
+    "order": 51,
     "section": "Self Hosting",
     "tab": "docs",
     "description": "Deploy Promptless on your own infrastructure for enhanced security, compliance, and control"
@@ -483,7 +526,7 @@
     "routePath": "/docs/self-hosting/kubernetes-helm",
     "title": "Kubernetes + Helm Deployment",
     "hidden": true,
-    "order": 48,
+    "order": 52,
     "section": "Self Hosting",
     "tab": "docs",
     "description": "Complete guide for deploying Promptless on Kubernetes using Helm charts"
@@ -494,7 +537,7 @@
     "routePath": "/docs/core-concepts",
     "title": "index",
     "hidden": true,
-    "order": 49,
+    "order": 53,
     "section": "Core Concepts",
     "tab": "docs"
   },
@@ -504,7 +547,7 @@
     "routePath": "/docs/core-concepts/context-sources",
     "title": "context-sources",
     "hidden": true,
-    "order": 50,
+    "order": 54,
     "section": "Core Concepts",
     "tab": "docs"
   },
@@ -514,7 +557,7 @@
     "routePath": "/docs/core-concepts/doc-locations",
     "title": "doc-locations",
     "hidden": true,
-    "order": 51,
+    "order": 55,
     "section": "Core Concepts",
     "tab": "docs"
   },
@@ -524,17 +567,113 @@
     "routePath": "/docs/core-concepts/triggers",
     "title": "triggers",
     "hidden": true,
-    "order": 52,
+    "order": 56,
     "section": "Core Concepts",
     "tab": "docs"
   },
+  {
+    "sourcePath": "src/content/blog/technical/sdk-documentation-best-practices.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/sdk-documentation-best-practices",
+    "title": "SDK Documentation Best Practices: What Actually Hurts Developer Adoption",
+    "hidden": false,
+    "order": 57,
+    "section": "Use Cases",
+    "tab": "blog",
+    "description": "SDK documentation fails developers in predictable ways. Here's how to cut Time to First Call and keep code examples accurate as your SDK evolves.",
+    "date": "2026-04-28T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/technical/api-changelog-best-practices.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/api-changelog-best-practices",
+    "title": "API Changelog Best Practices: Write for the Developer, Not the Team",
+    "hidden": false,
+    "order": 58,
+    "section": "Use Cases",
+    "tab": "blog",
+    "description": "68% of developers cite outdated API docs as their top frustration. Most changelogs cause it. Here's how to write one developers can actually use.",
+    "date": "2026-04-24T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/technical/documentation-debt.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/documentation-debt",
+    "title": "What Documentation Debt Actually Costs Engineering Teams",
+    "hidden": false,
+    "order": 59,
+    "section": "Use Cases",
+    "tab": "blog",
+    "description": "Documentation debt generates no automated alerts. Here's how to measure what you can't see and stop paying the hidden cost in onboarding and engineering time.",
+    "date": "2026-04-22T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/technical/documentation-debt-accrues-where-your-team-cant-see-it.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/documentation-debt-accrues-where-your-team-cant-see-it",
+    "title": "Documentation Debt Accrues Where Your Team Can't See It",
+    "hidden": false,
+    "order": 60,
+    "section": "Use Cases",
+    "tab": "blog",
+    "description": "Documentation debt quietly costs mid-sized engineering teams $500K–$2M annually. The people bearing that cost aren't in your standups. Here's how to prioritize what to fix.",
+    "date": "2026-04-20T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/technical/how-to-measure-developer-documentation-roi.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/how-to-measure-developer-documentation-roi",
+    "title": "How to Measure Developer Documentation ROI",
+    "hidden": false,
+    "order": 61,
+    "section": "Use Cases",
+    "tab": "blog",
+    "description": "Most documentation teams track outputs, not outcomes. Here's how to measure developer documentation ROI, and why that return decays if docs aren't maintained.",
+    "date": "2026-04-17T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/product-updates/request-docs-via-pr-comments.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/product-updates/request-docs-via-pr-comments",
+    "title": "Comment @promptless on a PR to Request Documentation",
+    "hidden": false,
+    "order": 62,
+    "section": "Featured",
+    "tab": "blog",
+    "description": "Promptless can now be triggered by commenting @promptless on a pull request in any repo you've connected to Promptless, including merged or closed ones.",
+    "date": "2026-04-14T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/technical/developer-documentation-roi.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/developer-documentation-roi",
+    "title": "Developer Documentation ROI: The Metrics That Actually Matter",
+    "hidden": false,
+    "order": 63,
+    "section": "Use Cases",
+    "tab": "blog",
+    "description": "Most teams make the documentation ROI case with support tickets. That understates it by 10x. Here's how to measure what leadership actually cares about.",
+    "date": "2026-04-14T00:00:00.000Z"
+  },
+  {
+    "sourcePath": "src/content/blog/product-updates/starlight-support.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/product-updates/starlight-support",
+    "title": "Promptless Now Supports Starlight (Astro) as a Docs Platform",
+    "hidden": false,
+    "order": 64,
+    "section": "Featured",
+    "tab": "blog",
+    "description": "Promptless now supports Starlight, the Astro-based docs framework, with automatic detection via astro.config files and first-class onboarding support.",
+    "date": "2026-04-10T00:00:00.000Z"
+  },
   {
     "sourcePath": "src/content/blog/technical/using-slack-as-a-knowledge-base.mdx",
     "contentType": "blog",
     "routePath": "/blog/technical/using-slack-as-a-knowledge-base",
     "title": "Using Slack as a \"Knowledge Base\"? Here's What You're Missing out on",
     "hidden": false,
-    "order": 53,
+    "order": 65,
     "section": "Use Cases",
     "tab": "blog",
     "description": "Slack feels like a knowledge store because answers happen there. Its design actively destroys institutional knowledge. Here's why docs-as-code fixes it.",
@@ -546,19 +685,31 @@
     "routePath": "/blog/technical/developer-onboarding-documentation-fails-after-launch",
     "title": "Why Developer Onboarding Documentation Breaks After Launch",
     "hidden": true,
-    "order": 54,
+    "order": 66,
     "section": "Technical",
     "tab": "blog",
     "description": "44% of developers dig through source code because onboarding docs don't match the product. Here's why accurate docs drift into inaccuracy — and how to catch it.",
     "date": "2026-04-07T00:00:00.000Z"
   },
+  {
+    "sourcePath": "src/content/blog/technical/karpathys-llm-wiki-personal-knowledge-base.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/karpathys-llm-wiki-personal-knowledge-base",
+    "title": "Karpathy's LLM Wiki Went Viral. Here's What It Means for Your Personal Knowledge Base.",
+    "hidden": false,
+    "order": 67,
+    "section": "Technical",
+    "tab": "blog",
+    "description": "Karpathy's LLM wiki pattern solves the oldest problem in personal knowledge management. Here's why it matters for your personal wiki, idea file, or knowledge base.",
+    "date": "2026-04-06T00:00:00.000Z"
+  },
   {
     "sourcePath": "src/content/blog/technical/solo-writer-team-lead.mdx",
     "contentType": "blog",
     "routePath": "/blog/technical/solo-writer-team-lead",
     "title": "When YOU are the Docs Team - Lessons from Working with Some of the Best Writers and Managers in the Industry",
     "hidden": false,
-    "order": 55,
+    "order": 68,
     "section": "Featured",
     "tab": "blog",
     "description": "Whether you're the only technical writer at your company or leading the docs team, some of the structural challenges are similar: not enough resources to build infrastructure, a manager who doesn't know your craft, and an AI moment that's changing what the job entails.",
@@ -570,7 +721,7 @@
     "routePath": "/blog/technical/help-center-to-docs-as-code",
     "title": "Help Center vs Docs-as-Code: When to Switch",
     "hidden": false,
-    "order": 56,
+    "order": 69,
     "section": "Use Cases",
     "tab": "blog",
     "description": "A practical guide to choosing between a help center and docs-as-code, with specific signals for when to migrate and when to stay.",
@@ -582,7 +733,7 @@
     "routePath": "/blog/technical/agent-memory-provider",
     "title": "Which Agent Memory Provider Should You Choose, and Why Memory Alone is not Enough",
     "hidden": false,
-    "order": 57,
+    "order": 70,
     "section": "Use Cases",
     "tab": "blog",
     "description": "A practical guide to choosing an agent memory provider by workload, with clear tradeoffs, technical specs, and what to add so reliability holds up in production.",
@@ -594,7 +745,7 @@
     "routePath": "/blog/technical/llms-txt-is-not-what-most-teams-think",
     "title": "llms.txt Is Not What Most Teams Think It Is",
     "hidden": true,
-    "order": 58,
+    "order": 71,
     "section": "Featured",
     "tab": "blog",
     "description": "llms.txt won't boost your AI search rankings. But for developer-facing companies, there's a different—and real—reason to care about it.",
@@ -606,7 +757,7 @@
     "routePath": "/blog/technical/support-agent-deflection",
     "title": "How to Increase the Deflection Rate of Your Support Agent and Build a Feedback Loop",
     "hidden": false,
-    "order": 59,
+    "order": 72,
     "section": "Use Cases",
     "tab": "blog",
     "description": "Most support agent deflection problems aren't model problems — they're documentation problems. Here's how to diagnose yours and build a feedback loop that compounds over time.",
@@ -618,7 +769,7 @@
     "routePath": "/blog/technical/agent-context-engineering",
     "title": "What is Agent Context Engineering? And How is it Different from Prompt and Harness Engineering?",
     "hidden": false,
-    "order": 60,
+    "order": 73,
     "section": "Use Cases",
     "tab": "blog",
     "description": "Learn what agent context engineering is, how it differs from prompt and harness engineering, why most agent failures are context failures, and a four-layer framework for building reliable AI agents.",
@@ -630,19 +781,31 @@
     "routePath": "/blog/technical/documentation-drift-detection-problem",
     "title": "Documentation Drift Is a Detection Problem, Not a Writing Problem",
     "hidden": true,
-    "order": 61,
+    "order": 74,
     "section": "Featured",
     "tab": "blog",
     "description": "Most teams treat documentation drift as a writing problem. It's not. The real bottleneck is detection — knowing what changed before the damage is done.",
     "date": "2026-03-30T00:00:00.000Z"
   },
+  {
+    "sourcePath": "src/content/blog/technical/documentation-metrics-and-analytics-a-complete-guide-for-dev.mdx",
+    "contentType": "blog",
+    "routePath": "/blog/technical/documentation-metrics-and-analytics-a-complete-guide-for-dev",
+    "title": "Documentation Metrics and Analytics: A Complete Guide for Developer-Facing Companies",
+    "hidden": true,
+    "order": 75,
+    "section": "Technical",
+    "tab": "blog",
+    "description": "Learn which documentation metrics actually matter for developer-facing companies, how to measure them, and how to connect doc quality to business outcomes.",
+    "date": "2026-03-27T00:00:00.000Z"
+  },
   {
     "sourcePath": "src/content/blog/technical/how-teams-keep-docs-up-to-date-with-promptless.mdx",
     "contentType": "blog",
     "routePath": "/blog/technical/how-teams-keep-docs-up-to-date-with-promptless",
     "title": "What It Looks Like When Your Docs Keep Up With Your Product",
     "hidden": false,
-    "order": 62,
+    "order": 76,
     "section": "Use Cases",
     "tab": "blog",
     "description": "Three real workflows from teams using Promptless that show what changes when your tooling handles detection, context gathering, and the first draft.",
@@ -654,7 +817,7 @@
     "routePath": "/blog/technical/agent-docs",
     "title": "A Practical Guide on How to Optimize Your Docs for Agents",
     "hidden": false,
-    "order": 63,
+    "order": 77,
     "section": "Featured",
     "tab": "blog",
     "description": "A practical guide for technical writers on adapting documentation for AI agent consumption, grounded in how agents actually access and use docs today.",
@@ -666,7 +829,7 @@
     "routePath": "/blog/technical/ambient-capture",
     "title": "Ambient Capture: The Missing Layer in Modern Documentation",
     "hidden": false,
-    "order": 64,
+    "order": 78,
     "section": "Featured",
     "tab": "blog",
     "description": "Ambient capture is the intelligent listening and recommendation layer for docs owners, continuously detecting docs-impacting changes so writers can focus on analysis and communication rather than surveillance.",
@@ -678,7 +841,7 @@
     "routePath": "/blog/technical/why-were-building-promptless",
     "title": "Why we're building Promptless",
     "hidden": false,
-    "order": 65,
+    "order": 79,
     "section": "Featured",
     "tab": "blog",
     "description": "AI won't replace human labor. But people that use AI well will replace those that don't. Promptless exists to make sure as many people as possible are in the first group.",
@@ -690,7 +853,7 @@
     "routePath": "/blog/technical/parrots-are-underrated-pets-and-tools",
     "title": "Parrots are underrated pets and tools",
     "hidden": false,
-    "order": 66,
+    "order": 80,
     "section": "Other",
     "tab": "blog",
     "description": "You know dozens of useful heuristics but can't hold them all in your head while doing actual work. LLMs can run those obvious-in-hindsight checks in parallel in the background, acting as cognitive prosthetics that apply known wisdom continuously so you don't have to remember to.",
@@ -702,7 +865,7 @@
     "routePath": "/blog/technical/writing-code-was-hard-actually",
     "title": "Writing code was hard, actually",
     "hidden": false,
-    "order": 67,
+    "order": 81,
     "section": "Other",
     "tab": "blog",
     "description": "The revisionist claim that writing code was never the hard part arrives conveniently at the moment AI makes it cheap to produce. But the market, the machine, and the engineers who built it all tell a different story.",
@@ -714,7 +877,7 @@
     "routePath": "/blog/technical/i-must-scream",
     "title": "\"I Have No Mouth, and I Must Scream\"",
     "hidden": false,
-    "order": 68,
+    "order": 82,
     "section": "Featured",
     "tab": "blog",
     "description": "What happens when you give an AI agent a Slack channel to complain in.",
@@ -726,7 +889,7 @@
     "routePath": "/blog/product-updates/launch-week-december-2025",
     "title": "Launch Week: December 2025",
     "hidden": false,
-    "order": 69,
+    "order": 83,
     "section": "Featured",
     "tab": "blog",
     "description": "Five major features we launched this December, from custom voice matching to automated screenshot updates.",
@@ -738,7 +901,7 @@
     "routePath": "/blog/life-at-promptless/running-a-lightweight-research-paper-club",
     "title": "Running a Lightweight Research Paper Club",
     "hidden": false,
-    "order": 70,
+    "order": 84,
     "section": "Other",
     "tab": "blog",
     "description": "How we run a weekly paper club at Promptless that's surprisingly useful, surprisingly easy, and has led to tangible product improvements.",
@@ -750,7 +913,7 @@
     "routePath": "/blog/customer-stories/vellum",
     "title": "How Vellum uses Promptless to draft over 50% of their doc updates",
     "hidden": false,
-    "order": 71,
+    "order": 85,
     "section": "Use Cases",
     "tab": "blog",
     "description": "By democratizing documentation contributions, every team member now drives content—making docs a true team sport powered by Promptless.",
@@ -762,7 +925,7 @@
     "routePath": "/changelog/changelogs/april-2026",
     "title": "April 2026",
     "hidden": false,
-    "order": 72,
+    "order": 86,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2026-04-01T00:00:00.000Z"
@@ -773,7 +936,7 @@
     "routePath": "/changelog/changelogs/march-2026",
     "title": "March 2026",
     "hidden": false,
-    "order": 73,
+    "order": 87,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2026-03-01T00:00:00.000Z"
@@ -784,7 +947,7 @@
     "routePath": "/changelog/changelogs/february-2026",
     "title": "February 2026",
     "hidden": false,
-    "order": 74,
+    "order": 88,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2026-02-01T00:00:00.000Z"
@@ -795,7 +958,7 @@
     "routePath": "/changelog/changelogs/january-2026",
     "title": "January 2026",
     "hidden": false,
-    "order": 75,
+    "order": 89,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2026-01-01T00:00:00.000Z"
@@ -806,7 +969,7 @@
     "routePath": "/changelog/changelogs/december-2025",
     "title": "December 2025",
     "hidden": false,
-    "order": 76,
+    "order": 90,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-12-01T00:00:00.000Z"
@@ -817,7 +980,7 @@
     "routePath": "/changelog/changelogs/november-2025",
     "title": "November 2025",
     "hidden": false,
-    "order": 77,
+    "order": 91,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-11-01T00:00:00.000Z"
@@ -828,7 +991,7 @@
     "routePath": "/changelog/changelogs/october-2025",
     "title": "October 2025",
     "hidden": false,
-    "order": 78,
+    "order": 92,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-10-01T00:00:00.000Z"
@@ -839,7 +1002,7 @@
     "routePath": "/changelog/changelogs/september-2025",
     "title": "September 2025",
     "hidden": false,
-    "order": 79,
+    "order": 93,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-09-01T00:00:00.000Z"
@@ -850,7 +1013,7 @@
     "routePath": "/changelog/changelogs/august-2025",
     "title": "August 2025",
     "hidden": false,
-    "order": 80,
+    "order": 94,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-08-01T00:00:00.000Z"
@@ -861,7 +1024,7 @@
     "routePath": "/changelog/changelogs/july-2025",
     "title": "July 2025",
     "hidden": false,
-    "order": 81,
+    "order": 95,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-07-01T00:00:00.000Z"
@@ -872,7 +1035,7 @@
     "routePath": "/changelog/changelogs/june-2025",
     "title": "June 2025",
     "hidden": false,
-    "order": 82,
+    "order": 96,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-06-01T00:00:00.000Z"
@@ -883,7 +1046,7 @@
     "routePath": "/changelog/changelogs/may-2025",
     "title": "May 2025",
     "hidden": false,
-    "order": 83,
+    "order": 97,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-05-01T00:00:00.000Z"
@@ -894,7 +1057,7 @@
     "routePath": "/changelog/changelogs/april-2025",
     "title": "April 2025",
     "hidden": false,
-    "order": 84,
+    "order": 98,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-04-01T00:00:00.000Z"
@@ -905,7 +1068,7 @@
     "routePath": "/changelog/changelogs/march-2025",
     "title": "March 2025",
     "hidden": false,
-    "order": 85,
+    "order": 99,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-03-01T00:00:00.000Z"
@@ -916,7 +1079,7 @@
     "routePath": "/changelog/changelogs/february-2025",
     "title": "February 2025",
     "hidden": false,
-    "order": 86,
+    "order": 100,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-02-01T00:00:00.000Z"
@@ -927,7 +1090,7 @@
     "routePath": "/changelog/changelogs/january-2025",
     "title": "January 2025",
     "hidden": false,
-    "order": 87,
+    "order": 101,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2025-01-01T00:00:00.000Z"
@@ -938,7 +1101,7 @@
     "routePath": "/changelog/changelogs/december-2024",
     "title": "December 2024",
     "hidden": false,
-    "order": 88,
+    "order": 102,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2024-12-01T00:00:00.000Z"
@@ -949,7 +1112,7 @@
     "routePath": "/changelog/changelogs/november-2024",
     "title": "November 2024",
     "hidden": false,
-    "order": 89,
+    "order": 103,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2024-11-01T00:00:00.000Z"
@@ -960,7 +1123,7 @@
     "routePath": "/changelog/changelogs/october-2024",
     "title": "October 2024",
     "hidden": false,
-    "order": 90,
+    "order": 104,
     "section": "Changelogs",
     "tab": "changelog",
     "date": "2024-10-01T00:00:00.000Z"
diff --git a/src/styles/custom.css b/src/styles/custom.css
index 9010fb08..5aa96625 100644
--- a/src/styles/custom.css
+++ b/src/styles/custom.css
@@ -866,6 +866,15 @@ a.fern-card:hover {
   margin-top: 1rem;
 }
 
+.pl-docs-welcome-video .pl-site-video-embed {
+  max-height: 350px;
+  overflow: hidden;
+}
+
+.pl-docs-welcome-cards .card {
+  padding: clamp(1rem, calc(0.25rem + 2vw), 1.6rem);
+}
+
 .pl-docs-cta {
   margin-top: 2rem;
   padding: 1rem 1.25rem;

From 6eb6e4b25033d1ed976441af56a802ca91a51aa2 Mon Sep 17 00:00:00 2001
From: Inline Pizza <249805557+InlinePizza@users.noreply.github.com>
Date: Thu, 7 May 2026 09:58:46 -0700
Subject: [PATCH 3/3] Add blog post and refine docs welcome page

Adds "Connect Code Repositories with Documentation Platforms" blog post and applies final edits to the getting-started welcome page.
---
 ...ositories-with-documentation-platforms.mdx | 75 +++++++++++++++++++
 .../docs/docs/getting-started/welcome.mdx     |  9 ++-
 2 files changed, 80 insertions(+), 4 deletions(-)
 create mode 100644 src/content/blog/technical/connect-code-repositories-with-documentation-platforms.mdx

diff --git a/src/content/blog/technical/connect-code-repositories-with-documentation-platforms.mdx b/src/content/blog/technical/connect-code-repositories-with-documentation-platforms.mdx
new file mode 100644
index 00000000..7f29d4a5
--- /dev/null
+++ b/src/content/blog/technical/connect-code-repositories-with-documentation-platforms.mdx
@@ -0,0 +1,75 @@
+---
+title: 'How to Connect Code Repositories with Documentation Platforms'
+subtitle: Published April 2026
+description: >-
+  A practical guide to connecting GitHub or GitLab to your documentation platform, with two integration patterns and how to choose between them.
+date: '2026-04-29T00:00:00.000Z'
+author: Frances
+tag: Technical
+section: Use Cases
+hidden: false
+---
+import BlogNewsletterCTA from '@components/site/BlogNewsletterCTA.astro';
+import BlogRequestDemo from '@components/site/BlogRequestDemo.astro';
+
+Your API reference lives in Git. Your README gets updated with every pull request. Your architecture docs are in `/docs/`, versioned alongside the code that made them necessary.
+
+Your product manager is reading a Confluence page that was copy-pasted from your repo six months ago.
+
+This is the documentation split most engineering teams live with. The source of truth is in the code repository. The place where decisions get made and onboarding happens is somewhere else: Confluence, Notion, or a doc platform that non-developers can actually open without a command line. Both exist. Neither syncs with the other.
+
+The fix is connecting them.
+
+## Two Integration Patterns
+
+There are two ways to connect a code repository to a documentation platform, and they solve different problems.
+
+### Pattern 1: Make your documentation platform Git-native
+
+Platforms like GitBook, Mintlify, and Docusaurus read directly from your repository. Your docs live in the repo as Markdown or MDX files. The platform builds and deploys them automatically on push to main. There is no sync step because the repository is the source of truth for the platform.
+
+This works well when your primary audience is technical. Developers and API integrators are comfortable in a docs portal. The workflow is simple: update the docs in the same PR as the code and push. The published site reflects it automatically.
+
+GitBook's Git sync, Mintlify's GitHub integration, and Docusaurus's static site generator all follow this pattern. [Cloudflare's documentation](https://blog.cloudflare.com/our-docs-as-code-approach/) runs entirely this way: every change flows through a pull request in their public GitHub repository, with GitHub Actions and Cloudflare Pages handling deployment automatically.
+
+### Pattern 2: Push from your repository to an external platform
+
+Some teams need documentation to live in Confluence, Notion, or a similar wiki because that's where decisions and stakeholder communication happen. Non-developers won't use a docs portal. They need content where they already work.
+
+Here, the integration is a CI/CD pipeline that runs on merge and pushes Markdown files to the external platform via its API. [Squarespace's engineering team](https://engineering.squarespace.com/blog/2025/making-documentation-simpler-and-practical-our-docs-as-code-journey) documented this approach in 2025: docs stored in Git, a CI/CD pipeline that automatically updates Backstage after every merge. [Swiftlane](https://swiftlane.com/blog/syncing-docs-from-code-repositories-to-notion/) built a similar pipeline to Notion using `git-notion`, an open-source CLI tool that syncs repo documentation whenever code merges.
+
+For Confluence specifically, the [`confluence-sync`](https://github.com/zonkyio/confluence-sync) project handles the push in a pipeline step, or you can call the Confluence API directly from a GitHub Actions or GitLab CI workflow.
+
+
+
+## Which Pattern Fits Your Team
+
+The deciding factor is your audience.
+
+If your documentation audience is primarily developers evaluating SDKs or building integrations, use a Git-native platform. This is the [docs-as-code approach](/blog/technical/help-center-to-docs-as-code): documentation lives in the repository, gets reviewed in pull requests, and deploys through a pipeline. No manual steps to forget.
+
+If your audience includes product managers, legal, support staff, or executives who live in Confluence or Notion, use the sync pipeline. Keep the repository as the source of truth. Write documentation in Markdown, close to the code it describes, and push it to wherever stakeholders can find it.
+
+Mixing both patterns is valid. Many teams maintain a developer-facing docs portal for their API reference and push architecture docs to Confluence for internal stakeholders. The constraint is consistent: the repository is always the source of truth. The external platform receives content; it does not produce it.
+
+## Setting Up the Connection
+
+For Git-native platforms, setup is typically an OAuth connection to your GitHub or GitLab organization. GitBook, Mintlify, and similar platforms walk through this in their onboarding flow. Configuration specifies which repository and branch to watch, where the content directory lives, and how the URL structure maps to the file tree. One-time setup, then it runs automatically.
+
+For sync pipelines, you need three things:
+
+1. **A trigger.** A GitHub Actions or GitLab CI job that runs on push to main.
+2. **A conversion step.** Most platforms accept standard Markdown. If you're writing Markdown in your repo already, this is minimal.
+3. **An API call.** Confluence, Notion, and similar platforms have REST APIs that accept page content. The CI job sends your Markdown as a page update.
+
+The `confluence-sync` project and `git-notion` provide pre-built implementations for both. If neither fits your setup, the core pattern is the same: read the file, call the API, run it on merge.
+
+## What This Does Not Solve
+
+Connection keeps documentation synchronized with what is actually written in your repository. It does not catch the case where something changed in the product and no one updated the docs file in the first place.
+
+A pipeline that pushes `/docs/api-reference.md` to Confluence will keep that Confluence page current. It will not catch a renamed endpoint that nobody reflected in `api-reference.md`. [That's a drift detection problem](/blog/technical/documentation-drift-detection-problem), and it lives upstream of any sync pipeline.
+
+Teams that connect their repositories to documentation platforms find the pipeline handles the straightforward part: getting accurate content to the right place. The harder part is keeping content in the repository accurate as the product evolves. Treating that as [a continuous monitoring task](/blog/technical/how-teams-keep-docs-up-to-date-with-promptless) rather than a periodic review is what separates teams whose docs stay current from teams that are always catching up.
+
+
diff --git a/src/content/docs/docs/getting-started/welcome.mdx b/src/content/docs/docs/getting-started/welcome.mdx
index 3bc9b1e2..244c3b5c 100644
--- a/src/content/docs/docs/getting-started/welcome.mdx
+++ b/src/content/docs/docs/getting-started/welcome.mdx
@@ -21,18 +21,19 @@ Use Promptless to keep product docs, internal docs, screenshots, changelogs, and
 
        
   
 
        
+
        
 
 Watch a short walkthrough of Promptless turning a product change into a documentation pull request. The demo shows Promptless finding the relevant docs, using code and project context, drafting an update with citations, and handing the change back to a technical writer for review.
 
 ## What You Can Do
 
 
        
-
-  
-    Detect when pull requests, commits, or releases change behavior that customers need to understand.
+
+  
+    Detect when pull requests, commits, or releases change product behavior.
   
 
-  
+  
     Draft new pages, guides, API references, changelog entries, and release notes from the context your team already has.