applies results from UAT with Bas

README.md

@@ -9,8 +9,7 @@ Roles:
 
 * New User: new key to be added; can be a new employee being added for first time, existing employee getting access to a new repo, key rotation, etc
 * Existing User: user who already has access to the appropriate project
-  * E.g. look up in the [groups](/groups/) dir    <!-- Review from Bas: The "e.g." is a bit confusing to me. Did you mean "i.e." instead? I'm OK if you leave the "e.g." out. -->
-  * E.g. look up in in [verify/.sops.yaml](verify/.sops.yaml)
+  * Definition: List of all users: [verify/.sops.yaml](verify/.sops.yaml)
 
 ## 1a. Onboarding: [New User]: create and add a gpg key
 1. Clone this repository
@@ -29,6 +28,10 @@ Roles:
 
 ## 1b. Onboarding: [Existing User|New User]: Add new user to groups
 
+Determine the groups to which access is needed, e.g. a specific repository.
+
+If uncertain, ask a Team Member for help!
+
 Access for each repo is tracked using the `./groups/` directory; each sub-directory represents a "group" (Note: some "groups" are also "roles", e.g. `admin`)
 
 Most of the groups correspond directly to a git repository names, aka "project name"
@@ -38,8 +41,6 @@ cd groups/<project_name>
 ln -s ../../<path_to_key.gpg.pub>
 ```
 
-Note: this step can be performed by anyone (either new user or existing user), but it makes the most sense for an existing user to configure the groups since this is domain-specific knowledge (i.e. new users won't typically know the grups)
-
 ## 3. Onboarding: [Existing User]: Configure sops config
 
 Context: This repo stores the keys used to encrypt secrets in other repos; these "consumer" repos each contain a sops config `.sops.yaml` which manages access to the encrypted files (e.g. `secrets.yaml`)