diff --git a/docs/operator-manual/project.yaml b/docs/operator-manual/project.yaml
index c4d93f536239f..ec8dd4d6544b5 100644
--- a/docs/operator-manual/project.yaml
+++ b/docs/operator-manual/project.yaml
@@ -14,12 +14,16 @@ spec:
   sourceRepos:
   - '*'
 
-  # Only permit applications to deploy to the guestbook namespace in the same cluster
+  # Only permit applications to deploy to the 'guestbook' namespace or any namespace starting with 'guestbook-' in the same cluster
   # Destination clusters can be identified by 'server', 'name', or both.
   destinations:
   - namespace: guestbook
     server: https://kubernetes.default.svc
     name: in-cluster
+  # Destinations also allow wildcard globbing
+  - namespace: guestbook-*
+    server: https://kubernetes.default.svc
+    name: in-cluster
 
   # Deny all cluster-scoped resources from being created, except for Namespace
   clusterResourceWhitelist:
diff --git a/docs/user-guide/projects.md b/docs/user-guide/projects.md
index d027193421d49..5a8fc9a01a204 100644
--- a/docs/user-guide/projects.md
+++ b/docs/user-guide/projects.md
@@ -123,7 +123,7 @@ argocd app set guestbook-default --project myproject
 
 ## Project Roles
 
-Projects include a feature called roles that can be used to determine who and what can be done applications associated with the project. As an example, it can be used to give a CI pipeline a restricted set of permissions allowing sync operations on a single app (but not change its source or destination).
+Projects include a feature called roles that can be used to determine who and what can be done to the applications associated with the project. As an example, it can be used to give a CI pipeline a restricted set of permissions allowing sync operations on a single app (but not change its source or destination).
 
 Projects can have multiple roles, and those roles can have different access granted to them. These permissions are called policies which follows the same [RBAC pattern used in Argo CD configuration](../operator-manual/rbac.md). They are stored within the role as a list of policy strings. A role's policy can only grant access to that role. Users are associated with roles based on the groups list. Consider the hypothetical AppProject definition below:
 
@@ -135,10 +135,10 @@ metadata:
 spec:
   ...
   roles:
-  - description: some-role
+  - name: admin 
+    description: some-role 
     groups:
     - some-user
-    name: admin
     policies:
     - p, proj:sample-test-project:some-role, applications, *, *, allow
   ...