website/developer-docs: add a baby Style Guide

website/developer-docs/docs/style-guide.mdx

@@ -0,0 +1,81 @@
+---
+title: Style Guide
+---
+
+Here are a few guidelines to ensure that the documentation is easy to read and uses similar phrasing. Remember to use our [docs templates](./templates/index.md) when possible; they are already set up to follow may of the style guidelines below.
+
+If you find any documentation that doesn't match these guidelines, feel free to either open an [Issue](https://github.com/goauthentik/authentik/issues) or a [PR](https://github.com/goauthentik/authentik/pulls) so they can be fixed.
+
+To test how the documentation renders use the Netlify Deploy Preview, especially when using Docusaurus-specific features. Or [build it locally and test](./writing-documentation.md#set-up-your-local-build), using the `make website-watch` command.
+
+:::info
+Make sure to add any new pages to the appropriate `sidebar` file. Otherwise, the new page will not appear in the table of contents to the left.
+:::
+
+## General guidelines
+
+-   Try to order the documentation sections in the order that makes it easiest for the user to follow. That is, order the sections in the same order as the actual workflow used to accomplish the task. Use headings (sub-titles) to break up long documents, and make it easier to find a specific section.
+
+-   You can use standard [Docusaurus-specific features](https://docusaurus.io/docs/next/markdown-features), which include MDX elements such as tabs and admonitions.
+
+## Terminology
+
+### authentik names
+
+-   The product name authentik should always start with a lower-case "a" and end with a "k". Even if it is the first word in a sentence. :-)
+
+-   Our company name is Authentik Security, Inc. but in non-legal documentation you can shorten it to Authentik Security.
+
+### Industry terms, technology, and other tools
+
+-   When referring to external tools, or an industry term or technology, always follow the exact capitalization that the product or company itself uses on their website, in their official documentation, or what the industry uses in consensus.
+
+-   Try to avoid using abbreviations if possible.
+
+-   Use acronyms where it makes sense (for commonly used terms like SAML or RBAC). If an acronym is less-known, spell it out in parentheses after the first use.
+
+## Writing style
+
+-   authentik documentation strives for a friendly, but not overly so, tone. It's ok to be a little bit conversational, and to address the reader in second person: "Next, you need to configure the log in settings."
+
+-   Our documentation uses American English ("z" not "s").
+
+-   Phrasing should almost always be in present tense and active voice:
+
+    -   DON'T: "The Applications page will be loaded."
+
+    -   DO: "The Applications page displays."
+
+-   Phrasing should never blame the user, and should be subjective:
+
+    -   DON'T: "Never modify the default file."
+
+    -   DO: "We recommend that you do not modify the default file, because this can result in unexpected issues."
+
+## Formatting
+
+Formatting in documentation is important; it improves comprehension and readability, and allows the brain to more quickly determine what is a command or a configuration setting, what is a field name, or what is a variable.
+
+-   When referring to UI elements or components in the authentik UI, such as field names, labels, etc., use **bold** text.
+
+-   Use `code` format when referring to:
+
+    -   commands
+    -   file paths
+    -   directory names
+    -   code snippets (single line or a block of code)
+
+-   For variables or placeholders use _italic_ font for the variable, and use place-holder names that makes it obvious that the user needs to replace it.
+
+    Example: <kbd>https://<em>company-domain</em>/source/oauth/callback/<em>source-slug</em></kbd>
+
+    When using variables in code snippets, make sure to specify if the value is something the user needs to define, is system-defined or generated.
+
+-   When referring to authentik functionality and features, such as flows, stages, sources, or policies, do not capitalize and do not use bold or italic text. When possible link to the corresponding documentation.
+
+### Titles and headers
+
+-   Both titles and headers (H1, H2, H3) use sentence style capitalization, meaning that only the first word is capitalized. However, if the title or header includes a proper noun (name of a product, etc) then capitalize those words.
+    Examples:
+    -   Configure your provider
+    -   Configure the Google Workspace provider

website/developer-docs/docs/templates/combo.md

@@ -9,7 +9,7 @@ title: "Combination topic"
 wget https://raw.githubusercontent.com/goauthentik/authentik/main/website/developer-docs/docs/templates/combo.tmpl.md
 ```
 
-Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#general-guidelines) for writing tips and authentik-specific rules.
+Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#writing-guidelines) for writing tips and authentik-specific rules.
 :::
 
 For a combo topic, the title is typically the name of the feature ("Branding" or "Remote Access Control").

website/developer-docs/docs/templates/conceptual.md

@@ -9,7 +9,7 @@ title: "Conceptual topic"
 wget https://raw.githubusercontent.com/goauthentik/authentik/main/website/developer-docs/docs/templates/conceptual.tmpl.md
 ```
 
-Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#general-guidelines) for writing tips and authentik-specific rules.
+Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#writing-guidelines) for writing tips and authentik-specific rules.
 :::
 
 Use a title that focuses on the feature, component, or technology you are writing about... for example, "About authentik polices" or "Understanding outposts". For conceptual docs, the verb in the title should indicate a concept, such as "About" or "Overview" or "Understanding", followed by the noun (the component or object you are writing about).

website/developer-docs/docs/templates/procedural.md

@@ -9,7 +9,7 @@ title: "Procedural topic"
 wget https://raw.githubusercontent.com/goauthentik/authentik/main/website/developer-docs/docs/templates/procedural.tmpl.md
 ```
 
-Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#general-guidelines) for writing tips and authentik-specific rules.
+Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#writing-guidelines) for writing tips and authentik-specific rules.
 :::
 
 For a procedural topic, use a title that focuses on the task you are writing about. For example, "Add a new Group" or "Edit user profiles". For procedural docs, there should be a verb in the title, and usually the noun (the component or object you are working on). For the title (and all headings) use the infinitive form of the verb (i.e. "add") not the gerund form (i.e. "adding").

website/developer-docs/docs/templates/reference.md

@@ -9,7 +9,7 @@ title: "Reference topic"
 wget https://raw.githubusercontent.com/goauthentik/authentik/main/website/developer-docs/docs/templates/reference.tmpl.md
 ```
 
-Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#general-guidelines) for writing tips and authentik-specific rules.
+Edit your markdown file as you work, reading this page for the descriptions of each section. You can build out a "stub file" with just headers, then gradually add content to each section. Use screenshots sparingly, only for complex UIs where it is difficult to describe a UI element with words. Refer to our [General Guidelines](../writing-documentation#writing-guidelines) for writing tips and authentik-specific rules.
 :::
 
 Create a title that specifies the component you are documenting. For example, "Group attributes".

website/developer-docs/docs/writing-documentation.md

@@ -2,74 +2,56 @@
 title: Writing documentation
 ---
 
-Writing documentation for authentik is a great way for both new and experienced users to improve and contribute to the project. Here are a few guidelines to ensure
-the documentation is easy to read and uses similar phrasing.
+Writing documentation for authentik is a great way for both new and experienced users to improve and contribute to the project.
 
-## Setup
+## Set up your local build
 
 Requirements:
 
--   Node.js 16 (or greater)
+-   Node.js 20 (or greater, we use Node.js 22)
 
-The documentation site is situated in the `/website` folder of the authentik GitHub repository.
+The docs and the code are in the same Github repo, at https://github.com/goauthentik/authentik, so if you have cloned the repo, you already have the docs.
+
+You can do local builds of the documentation to test your changes or review your new content, and to run the required `prettier` and linters before pushing your PR.
+
+The documentation site is situated in the `/website` folder of the repo.
 
 The site is built using npm, below are some useful make commands:
 
 -   **Installation**: `make website-install`
 
     This command is required before running any of the following commands, and after upgrading any dependencies.
 
--   **Formatting**: `make website` or `make website-lint-fix`
+-   **Formatting**: `make website`, `make website-lint-fix`, or `npm run prettier`
 
-    Run this command before committing, to ensure consistent syntax, clean formatting, and verify links. Note that if the formatting command is not run, the build will fail with an error about linting.
+    Run the appropriate formatting command for your set up before committing, to ensure consistent syntax, clean formatting, and verify links. Note that if the formatting command is not run, the build will fail with an error about linting.
 
 -   **Live editing**: `make website-watch`
 
     For real time viewing of changes, as you make them.
 
 :::info
-Be sure to run the formatter before committing changes.
+Be sure to run a formatting command before committing changes.
 :::
 
-## General guidelines
-
--   The product name authentik should always be stylized as `authentik` (with a lower-case "a" and ending with a "k").
--   Documentation should use American English.
--   You can use standard [Docusaurus-specific features](https://docusaurus.io/docs/next/markdown-features), which include MDX elements such as tabs and admonitions.
--   Use abbreviations where it makes sense (for commonly used terms like SAML and OAuth) for common terms. If an abbreciation is less-known, spell it out in parentheses after the first use.
--   Phrasing should almost always be in present tense and active voice:
-
-    -   DON'T: "The Applications page will be loaded."
-
-    -   DO: "The Applications page displays."
-
--   Phrasing should never blame the user, and should be subjective:
-
-    -   DON'T: "Never modify the default file."
-
-    -   DO: "We recommend not modifying the default file."
+## Writing guidelines
 
--   When referring to UI text or UI components in authentik, use **bold** text.
--   When referring to other objects in authentik code or functionality, use _cursive_ text, and link to the corresponding documentation if possible.
--   When referring to external tools, give an example how to use the tools or explain how the user can use them.
--   Make sure to add the documentation to the sidebar, if adding a new page.
--   Test how the documentation renders using the Netlify Deploy Preview, especially when using Docusaurus-specific features. Or build it locally and test, using the `make website-watch` command.
+Please refer to our [Style Guide](./style-guide.mdx) for authentik documentation. Here you will learn important guidelines about not capitalizing authentik, how we format our titles and headers, and much more.
 
-If you find any documentation that doesn't match these guidelines, feel free to either open an [Issue](https://github.com/goauthentik/authentik/issues) or a [PR](https://github.com/goauthentik/authentik/pulls) so they can be fixed.
+Whenever possible, use one of our [doc templates](./templates/index.md). This makes it a lot easier for you (no blank page frights!) and keeps the documentation consistent.
 
-## Integration guidelines
+Make sure to add the new pages to the appropriate place in `/website/sidebars.js`. Otherwise, the content will not appear in the table of contents to the left.
 
-These guidelines apply in addition to the ones above.
+Following the guidelines will make getting your PRs merged much easier and faster, with fewer edits needed. We appreciate our community contributors helping us keep the Docs consistent, easy-to-use, and high quality.
 
-See the template in `/website/integrations/_template/service.md`.
+## Documentation for Integrations
 
--   For placeholders, use angle brackets and italicize the text inside the brackets, to indicate that it is a variable (`_<placeholder-name>_`).
+In addition to following the [Style Guide](./style-guide.mdx) please review the following guidelines.
 
-    Make sure to also define if the placeholder is something the user needs to define, is something another system defines, or is randomly generated.
+For new integration documentation, please use the Integrations template in our [Github repo](https://github.com/goauthentik/authentik) at `/website/integrations/_template/service.md`.
 
-    If you're adding configuration snippets to the documentation, and the snippet is in a language that supports comments, other placeholders may be used, for example comments referencing an earlier step.
+-   Make sure to add the service to a fitting category in `/website/sidebarsIntegrations.js`. If this is not done the service will not appear in the table of contents to the left.
 
 -   For placeholder domains, use `authentik.company` and `app-name.company`, where `app-name` is the name of the application that you are writing documentation for.
--   Try to order the documentation in the order that makes it easiest for the user to configure.
 
--   Make sure to add the service to a fitting category in `/website/sidebarsIntegrations.js`
+-   Try to order the documentation sections in an order that makes it easiest for the user to configure.

website/developer-docs/index.md

@@ -7,6 +7,8 @@ slug: /
 
 The following is a set of guidelines for contributing to authentik and its components, which are hosted in the [goauthentik Organization](https://github.com/goauthentik) on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
 
+We appreciate contributions of code, documentation, enhancements, and bug fixes. Read more [below](#how-can-i-contribute) about the many ways to contribute.
+
 ## Code of Conduct
 
 We expect all contributors to act professionally and respectfully in all interactions. If there's something you dislike or think can be done better, tell us! We'd love to hear any suggestions for improvement.
@@ -121,6 +123,8 @@ This is documented in the [developer docs](./setup/frontend-dev-environment.md)
 
 Contributions to the technical documentation are greatly appreciated. Open a PR if you have improvements to make or new content to add. If you have questions or suggestions about the documentation, open an Issue. No contribution is too small.
 
+Please be sure to refer to our [Style Guide](../developer-docs/docs/style-guide.mdx) for the docs, and use a [template](./docs/templates/index.md) to make it easier for you. The style guidelines are also used for any Integrations documentation, and we have a template for Integrations as well, in our [Github repo](https://github.com/goauthentik/authentik) at `/website/integrations/_template/service.md`.
+
 ### Pull Requests
 
 The process described here has several goals:
@@ -144,7 +148,9 @@ While the prerequisites above must be satisfied prior to having your pull reques
 
 -   Use the format of `<package>: <verb> <description>`
     -   See [here](#authentiks-structure) for `package`
-    -   Example: `providers/saml2: fix parsing of requests`
+    -   Examples:
+        `providers/saml2: fix parsing of requests`
+        `website/docs: add config info for GWS`
 
 ### Git Commit Messages
 
@@ -154,7 +160,7 @@ While the prerequisites above must be satisfied prior to having your pull reques
 -   Reference issues and pull requests liberally after the first line
 -   Naming of commits within a PR does not need to adhere to the guidelines as we squash merge PRs
 
-### Python Styleguide
+### Python Style Guide
 
 All Python code is linted with [black](https://black.readthedocs.io/en/stable/) and [Ruff](https://docs.astral.sh/ruff).
 
@@ -165,6 +171,14 @@ authentik runs on Python 3.12 at the time of writing this.
 -   Ensure any database migrations work properly from the last stable version (this is checked via CI)
 -   If your code changes central functions, make sure nothing else is broken.
 
-### Documentation Styleguide
+### Documentation Style Guide
+
+Refer to the full [Style Guide](../developer-docs/docs/style-guide.mdx) for details, but here are some important highlights:
+
+-   Our product name is authentik, with a lower-case "a" and a "k" on the end. Our company name is Authentik Security.
+
+-   We use sentence style case in our titles and headings.
+
+-   We use **bold** text to name UI components, and _italic_ text for variables.
 
--   Use [MDX](https://mdxjs.com/) whenever appropriate.
+-   Use [MDX](https://mdxjs.com/) whenever appropriate. MDX, which uses React components, is useful for creating tabs, action buttons, and advanced content formatting.

website/integrations/_template/service.md → website/integrations/template/service.md

@@ -6,7 +6,7 @@ title: Service Name
 
 ## What is Service-Name
 
-> Insert a quick overview of what Service Name is and what it does
+> Insert a quick overview of what Service Name is and what it does. Simply describe the product and what it is, how it is used, and do not include marketing or sales-oriented content.
 >
 > -- https://service.xyz
 

website/sidebarsDev.js

@@ -76,6 +76,7 @@ module.exports = {
                 id: "docs/writing-documentation",
             },
             items: [
+                "docs/style-guide",
                 {
                     type: "category",
                     label: "Templates",
@@ -87,6 +88,7 @@ module.exports = {
                         "docs/templates/procedural",
                         "docs/templates/conceptual",
                         "docs/templates/reference",
+                        "docs/templates/combo",
                     ],
                 },
             ],