diff --git a/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
index 957d382bc3c..67bde0843af 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
@@ -10,8 +10,8 @@ While most types of Kubernetes secrets store sensitive information, [ConfigMaps]
 
 ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
 
->**Note:** ConfigMaps are only available within [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) and not projects.
-
+>**Note:** ConfigMaps are only available within [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) and not [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects).
+({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces)
 ConfigMaps store general configuration information for an application, such as configuration files, command-line arguments, environment variables, etc. ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. Add ConfigMaps to your Rancher workspaces so that you can add them to your workloads later. For more information on ConfigMaps, see the official [Kubernetes Documentation: Using ConfigMap](https://kubernetes-v1-4.github.io/docs/user-guide/configmap/).
 
 >**Note:** ConfigMaps can only be applied to namespaces and not projects.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
index 8de1474c94b..8544a43439a 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
@@ -113,13 +113,7 @@ Alternatively, you can switch between projects and clusters using the main menu.
 
 ## Namespaces
 
-Kubernetes resources belong to specific [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which are virtual clusters backed by a physical cluster. Rancher 2.0 uses namespaces as objects that:
-
-- Isolate users and apps within a cluster that is shared among other teams and apps. When a user deploys an app from the catalog, for example, they can deploy that app into its own namespace, so that resource names in one app will not conflict with resource names in another.
-
-- Provide a unique name for an application. Namespaces must be globally unique. It is often difficult for users to pick unique namespace names. Rancher therefore encourages the pattern where users work with projects, and the system generates unique namespace names automatically.
-
-- Divide hardware resources between multiple resources. Using [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/), you can limit the vCPU and memory that each namespace can access so that performance is evenly distributed among the cluster.
+Within Rancher, you can further divide projects into different Kubernetes [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which are virtual clusters backed by a physical cluster. You can then assign resources within a project to individual namespaces.
 
 For more information, see the [Kubernetes Namespaces Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
 
@@ -157,7 +151,7 @@ Depending on your role within Rancher and your organization, the context in whic
 
 ### Moving Namespaces to Another Project
 
-Cluster admins and members may occasionally need to move a namespace to another project, such as when a project runs out of hardware resources to support all of its existing namespaces.
+Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
 
 1. From the **Global** view, open the cluster that contains the namespace you want to move.