update: Rename Redis to Aiven for Caching

.github/CODEOWNERS

@@ -1,2 +1,3 @@
-* @ArthurFlag
+# * @ArthurFlag
+* @aiven/aiven-technical-writers
 static/includes

.github/vale/styles/Aiven/First_Redis_is_registered.yml → .github/vale/styles/Aiven/First_Caching_is_registered copy.yml

@@ -4,5 +4,5 @@ level: error
 scope: text
 ignorecase: false
 
-first: '\b(Redis)(?!®\*)'
-second: '(Redis)(?:®\*)'
+first: '\b(Caching)(?!®)'
+second: '(Caching)(?:®)'

.github/vale/styles/config/vocabularies/Aiven/accept.txt

@@ -111,6 +111,7 @@ Grafana
 Grafana/M
 GSuite
 hardcoded
+HAProxy
 HashiCorp
 Heatmap
 Hillyer

.gitignore

@@ -16,6 +16,9 @@
 .env.test.local
 .env.production.local
 
+# JetBrains IDEs
+.idea
+
 # Yarn
 !.yarn/patches
 !.yarn/plugins

.vscode/settings.json

@@ -21,7 +21,8 @@
   "markdown.extension.orderedList.marker": "one",
   "files.associations": {
     "config": "properties",
-    "_redirects": "ini"
+    "_redirects": "ini",
+    "CODEOWNERS": "ini"
   },
   "[properties]": {
     "editor.formatOnSave": false

docs/platform/concepts/corporate-billing.md

@@ -17,7 +17,7 @@ based on the services running in a project. Each project is charged
 separately, but the charges for multiple projects can be consolidated by
 assigning them to a
 [billing group](/docs/platform/concepts/billing-groups). Likewise,
-[organizations](/docs/platform/concepts/projects_accounts_access) can have multiple billing groups.
+[organizations](/docs/platform/concepts/orgs-units-projects) can have multiple billing groups.
 
 ## Credit card fees
 
@@ -36,7 +36,7 @@ different. The fee may be applied even if the card was charged in the
 card's default currency (USD).
 
 Such fees are not added by Aiven and are not visible to us or our credit
-card processor, and we're thus unable to include them in our prices or
+card processor, so we're unable to include them in our prices or
 waive the fees.
 
 ## Invoice payments

docs/platform/concepts/free-plan.md

@@ -3,9 +3,9 @@ title: Free plans
 ---
 
 The free plan is available for Aiven for PostgreSQL®, Aiven for MySQL,
-and Aiven for Redis®\* services. You don't need a credit card to sign
+and Aiven for Caching® services. You don't need a credit card to sign
 up and you can create one free service for each type. This means you can
-create one free PostgreSQL, one free MySQL, and one free Redis service.
+create one free PostgreSQL, one free MySQL, and one free Caching® service.
 
 To try a different service, you may want to consider a
 30-day
@@ -27,7 +27,7 @@ Free plans include:
 -   1 CPU per virtual machine
 -   1 GB RAM
 -   For PostgreSQL and MySQL: 5 GB disk storage
--   For Redis: `maxmemory` set to 50%
+-   For Caching: `maxmemory` set to 50%
 -   Management via our web console, CLI, API, Terraform provider, or
     Kubernetes® operator
 -   Monitoring for metrics and logs
@@ -48,7 +48,7 @@ There are some limitations of the free plan services:
 -   Only a limited number of DigitalOcean regions, no other cloud
     providers
 -   Only one service per service type per user and
-    [organization](/docs/platform/concepts/projects_accounts_access)
+    [organization](/docs/platform/concepts/orgs-units-projects)
 -   Not covered under Aiven's 99.99% SLA
 
 Free plans do not have any time limitations. However, Aiven reserves the

docs/platform/concepts/maintenance-window.md

@@ -23,7 +23,7 @@ Aiven service upgrades are performed in rolling forward style, which
 means that new service nodes are first created alongside with the older
 nodes one at a time, after which the old nodes are retired.
 
-For **MySQL®**, **PostgreSQL®** and **Redis®**\*, the maintenance
+For **MySQL®**, **PostgreSQL®** and **Caching®**, the maintenance
 window usually lasts around several seconds. The downtime comes from old
 master stopping itself in a controlled manner and new master executing
 promotion sequence after this. Once the promotion is complete the old

docs/platform/concepts/orgs-and-units.md

@@ -2,4 +2,4 @@
 title: Organizations and units
 ---
 
-You automatically have an organization when you sign up for Aiven and helps you [centrally manage billing and access](/docs/platform/concepts/projects_accounts_access#organizations-and-organizational-units). Add organizational units in your organization to group related projects together.
+You automatically have an organization when you sign up for Aiven where you [centrally manage billing and access](/docs/platform/concepts/orgs-units-projects). You can add organizational units in your organization to group related projects together.

docs/platform/concepts/orgs-units-projects.md

@@ -0,0 +1,121 @@
+---
+title: Organizations, units, and projects
+---
+
+The Aiven platform uses organizations, organizational units, and projects to efficiently and securely organize your services and manage access.
+
+import Overview from "@site/static/images/content/figma/organizations-overview.png";
+
+<img alt="Hierarchy showing two organizational units, each with two projects, nested within one organization." src={Overview} width="58%" class="centered"/>
+
+There are three levels in this hierarchy:
+
+1. Organization: Contains all of your projects and services. It's recommended to have one
+    Aiven organization.
+1. Organizational units: Added to the organization, giving you greater flexibility to
+   organize your infrastructure based on your specific use cases. For example, you can
+   split production and testing workloads into different organizational units.
+1. Projects: Created in the organization or organizational units to group your services
+    together.
+
+## Organizations
+
+When you sign up to Aiven, an organization is created for you. You can use your
+organization to create a hierarchical structure that fits your needs.
+
+Organizations also let you centrally manage settings like:
+
+- [Domains and identity providers](/docs/platform/howto/list-identity-providers):
+   Only available at the organization level
+- [Authentication policies](/docs/platform/howto/set-authentication-policies):
+   Only available on the organization level
+- Access control lists (ACLs): Can be set on all levels (organization,
+  organizational unit, and project)
+  - ACLs for service plans are inherited, meaning all projects
+    within an organization or organizational unit have the same service plan.
+- [Groups](/docs/platform/howto/list-groups): Managed only at the organization level
+   and assigned to projects
+- [Support tiers](/docs/platform/howto/support): Specific to a single organization and
+   apply to all units, projects, and services within that organization. They cannot be
+   shared between organizations.
+- [Billing information](/docs/platform/concepts/hourly-billing-model): Managed at the
+   organization level. They can be used for all projects in the organization
+   and its units. They cannot cannot be shared between organizations.
+
+## Organizational units
+
+Organizational units are collections of projects. Customers often use these to group
+projects based on things like:
+- Departments in their company like finance, marketing, and engineering
+- Environments such as development, testing, and production
+
+You can create as many units as you need in your organization, but you cannot
+create units in other units.
+
+## Projects
+
+Projects are collections of services and user permissions. You can
+[create projects](/docs/platform/howto/manage-project) in an organization
+or in organizational units.
+
+Projects help you group your services based on your organization's structure or processes.
+They also let you apply uniform network security settings across all services within
+the project. The following are some examples of how customers organize their services:
+
+-   Single project: One project containing services that are
+    distinguished by their names. For example, services have names based
+    on the type of environment: `demo_pg_project.postgres-prod` and
+    `demo_pg_project.postgres-staging`.
+-   Environment-based: Each project represents a deployment environment,
+    for example: `dev`, `qa`, and `production`. This can make it easier to apply
+    uniform user permissions, such as developer access to production infrastructure.
+-   Project-based: Each project contains all the services for an
+    internal project, with naming that highlights the relevant
+    environment. For example: `customer-success-prod` and `business-analytics-test`.
+
+## Users and roles
+
+To add users to your organization, you send them an invite. Organization users can be
+made super admin or they can be added to specific projects. They can also be [added to
+groups](/docs/platform/howto/manage-groups) to control access to the services in a project.
+
+Super admin have full access to the organization, including all organizational units,
+projects, and services. Users are automatically made super admin when they create an
+organization, and they can [make other users super admin](/docs/platform/howto/make-super-admin).
+
+You grant other users access to services at the project level by
+[adding them as project members](/docs/platform/howto/add-project-members),
+either individually or in groups. You give project members a role that defines the
+level of access they have to all services in the project.
+
+The Aiven platform lets you use a mix of group and individual access
+rights for projects.
+
+## Best practices for organizations
+
+### Small organizations
+
+For smaller organizations that have a limited number of projects it's
+recommended to consolidate all your projects within one organization.
+This makes it easier for your teams to navigate between projects and
+services.
+
+Good naming conventions also help with finding projects and services.
+For example, you can include the environment type,  `dev`, `prod`,
+etc., at the beginning of project names.
+
+### Medium organizations
+
+For more complex cases, take advantage of the
+organizational units. Organizational units group related projects.
+
+You can, for example, group projects into organizational units that
+correspond to your internal departments. Alternatively, you can group
+them by categories like testing, staging, and production environments.
+
+### Large organizations
+
+For large organizations, keep your projects in
+organizational units instead of organizations. By keeping your
+projects in organizational units you can centrally manage things like
+support contracts and billing groups for each group of projects.