Feedback on CO320

_episodes/01-co.md

@@ -10,7 +10,7 @@ keypoints:
 - "List the key takeaways for the episode"
 ---
 
-COmanage is a multi-tenet tool. This means that for each installation, one or more top-level groups can be expressed. These groups are called Collaborative Organizations or COs. Individuals are added to these fundamental groups (COs), but once there, the individuals can be included in multiple sub groups of the CO.
+COmanage is a multi-tenant tool. This means that for each installation, one or more top-level groups (_group is ambiguous, maybe stick with tenant?_) can be expressed. These groups are called Collaborative Organizations or COs. Individuals are added to these fundamental groups (COs), but once there, the individuals can be included in multiple sub groups of the CO.
 
 # 1. The Collaborative Organization (`CO`:gear:)
 
@@ -22,7 +22,7 @@ Some traits of these `COs`:gear: include:
 * They share common policies for vetting the identities of collaborators.
 * They may include individuals in a single organization, or individuals may be in multiple organizations, geographically different regions, or even work independently.
 
-While COmanage can support multiple `COs`:gear:, it is rare for someone who is just getting started to have more than one. During this workshop, each of us will be working with just one `COs`:gear:.
+While COmanage can support multiple `COs`:gear:, it is rare for deployers who are just getting started to have more than one. During this workshop, each of us will be working with just one `COs`:gear:.
 
 # Administrator Roles
 
@@ -36,6 +36,7 @@ COmanage Registry defines several types of administrators.
 * Add people to the `CO`:gear: (using an enrollment workflow. we will talk about these in a future lesson)
 * Manage `CO Person`:gear: information for people connected to the `CO`:gear:
 * Create and manage sub groups within the `CO`:gear: (we will be talking about these sub groups in the next section.)
+* Connect the CO to provision applications used by the collaboration (_This point might not be covered enough in the introductory materials - the primary purposes of person attribute management is to enable access to applications (and remove it when no longer required)_)
 
 ## Other top-level administrators
 
@@ -64,6 +65,8 @@ In this lesson you each will start to build an organizational model to serve as
 
 # Hands on - CO Settings
 
+_Most CO Settings only make sense in another context. For example, the automatic expiration setting only makes sense once Expiration Policies are defined, and Identity Source Sync only makes sense if Org Identity Sources are configured in some sort of batch mode._
+
 ![Interactive system activity](/assets/img/hands-on-keyboard.png)
 
 `COs`:gear: have a number of settings that will dictate how it will behave. These settings are outlined on the worksheet, [CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf). As we review each of the settings, mark the values for each on the worksheet for your `CO`:gear:.
@@ -101,7 +104,7 @@ In this section, you can set the required fields for physical addresses and name
 
 We will now implement what you have specified on your worksheets.
 
-## Sign into the Registry
+## Sign into (the _typically we don't use prepositions with the product names_) Registry
 
 1. Using the credentials you specified as part of the COmanage setup, sign into the system. These credentials have Platform Administrator privileges which enable you to create `COs`:gear:. Once you sign in you will see a list of available collaborations. 
 

_episodes/02-cous.md

@@ -16,33 +16,32 @@ As a collaboration grows in size, it may be useful to create various structures
 
 Collaborative Organizations Units (or `COUs`:gear:) allow you to define an organizational structure within a CO. While many organizations have natural groups within them, the reason that you would divide your CO into COUs are because there are differences across your CO that necessitates different policies in one or more of the following:
 
-* How individuals join and/or leave the group
+* How individuals join and/or leave the group (_"collaboration" instead of group?_)
 * There are different rules about how applications get provisioned or deprovisioned
 * Who manages person membership and privileges in the group
 * The information stored or used about members of the group 
 
-If your collaboration–a single entity with common goals–has unique requirements among the different groups and/or departments regarding how participants will join those parts of your collaborations, then, you have a CO that contains COUs. If you have only one common set of policies that define how individuals are added or removed from the CO, then you do not have COUs even though you may have groups for simple access control.
+If your collaboration–a single entity with common goals–has unique requirements among the different groups and/or departments regarding how participants will join those parts of your collaborations, then, you have a CO that contains COUs. If you have only one common set of policies that define how individuals are added or removed from the CO, then you _probably?_ do not have COUs even though you may have groups for simple access control.
 
-When you have `COUs`:gear:, they may represent recognized groups of collaborators like departments, divisions, projects; or they may be related to the privileges that those in the group may have, for example, alumni or parents. The primary purpose of a `COUs`:gear:, however, is to allow for delegation of person management operations. 
+`COUs`:gear: may also be used to represent recognized groups of collaborators like departments, divisions, projects; or they may be related to the privileges that those in the group may have, for example, alumni or parents. (The primary purpose of a `COUs`:gear:, however, is to allow for delegation of person management operations. _In the "also" exmaples, it's still delegation of person management operations_)
 
-If `COUs`:gear: are defined, they can be associated directly with the `CO`:gear: or they can have another `COU`:gear: as a parent.
+`COUs`:gear: can be organized in a hierarchy, or a flat structure can be used where each `COUs`:gear: has only the `CO`:gear: as a parent.
 
 # `CO Person Roles`:gear: - a.k.a., associating `CO Persons`:gear: with `COUs`:gear:
 
 Any `CO Person`:gear: in the `CO`:gear: can be part of any of the `COUs`:gear: in the `CO`:gear:. This connection happens through an object called a `CO Person Role`:gear:.
 
-The attributes (information) stored in the `CO Person Role`:gear: object typically includes
+The attributes (information) stored in the `CO Person Role`:gear: object typically include
 
 * Link to the associated `CO Person`:gear: who is connected to the `COU`:gear:
 * Link to the person who is sponsoring the `CO Person`:gear:. Sponsors are usually used in relation to guest systems. We'll talk more about sponsors when we talk about enrollment workflows.
 * Status
-* Personal information about the person
-  * Date of birth
+* Role-specific information about the person
   * affiliation (eduPerson)
   * organization, department, & title
 * List of physical addresses / phone numbers
 
-These roles also can include information about the percent time the registered person is allocated to this role.
+These roles also can include information about the percent time the registered person is allocated to this role. (_This is an extended attribute, it is not configured by default._)
 
 `CO Persons`:gear: can have any number of `CO Person Roles`, usually one for each `COU` that the person is part of.
 
@@ -54,6 +53,8 @@ When a `CO Person`:gear: is connected to one or more `CO Person Roles`:gear:, th
 
 Active statuses are most preferred, followed by expired statuses, followed by invitation statuses.
 
+_Maybe again filter this list like for CO Person status_
+
 Preference | Status | Description
 ---------- | ------ | -----------
 1 | Active | Person or Role is an active member of the organization or collaboration
@@ -87,10 +88,12 @@ Let's add to the organizational model that we're using as an example and its rel
 
 _[INSTUCTOR NOTE: it's a good idea to see which workshop participants have natural COUs in their organizations, and use this opportunity to clarify the purpose of a COU. If no one has natural COUs, the interactive part of this episode can be skipped OR the participants can go through this exercise, creating two COUs and using the content below to highlight a common use case for multiple COUs. If there is time, it is best to keep this section in.]_
 
-Your organization may not need more than one COU. 
+Your organization may not need more than one COU. _It probably doesn't make sense to have exactly one COU, at that point just use a CO without COUs_
 
 On this worksheet you will see spaces to describe two COUs. Write the name of two of your COUs in these sections. If your organization doesn't have COUs, lets use these two as examples:
 
+_For a VO oriented example, maybe "Researchers" and "Administrators"?_
+
 field | COU #1 | COU #2
 ----- | ------ | ------
 Name | Main university | Medical school
@@ -109,7 +112,7 @@ You can optionally include this information on the [COU Planning Worksheet :memo
 
 We will now implement what you have specified on your worksheets.
 
-## Sign into the Registry
+## Sign into Registry
 
 1. Using the credentials you specified as part of the COmanage setup (or the `CO Administrator`:crown: that you established in the last section), sign into the system.
 2. Navigate to your `CO`:gear:. If necessary, select your `CO`:gear: by selecting **Collaborations** from the menu on the left, and then selecting your Collaboration.

_episodes/03-groups.md

@@ -14,7 +14,7 @@ keypoints:
 
 COmanage Groups (`CO Groups`:gear:) are defined at the `CO`:gear: level, and `CO Group Memberships`:gear: are attach to the `CO Person`:gear:. `CO Groups`:gear: provide group functionality enabling actions to be applied to all members of the group at the same time, for example, granting access to an application, joining a mailing list, or expiring membership at the same time. By default, any `CO Person`:gear: can create a new `CO Group`:gear:.
 
-In some cases you will have more sophisticated provisioning needs than can be managed from within COmanage. In these cases, COmanage can be connected to Grouper. 
+In some cases you will have more sophisticated provisioning needs than can be managed from within COmanage. In these cases, COmanage can be connected to Grouper. _Grouper is really for group management. Provisioning would most likely be another tool, of which there are several to choose from._
 
 The attributes for a `CO Group`:gear: include:
 
@@ -60,7 +60,7 @@ Nested Groups are not designed to scale to very large groups, and in particular
 
 Email Lists are data structures that associate `CO Groups`:gear: and their memberships with listservs. COmanage does not provide actual message delivery capabilities, but rather maintains metadata about lists in order to provision list management software that support Email List objects. Currently supported email list-aware provisioners include:
 
-* LDAP Provisioning Plugin
+* LDAP Provisioning Plugin (_I don't think this is implemented yet..._)
 * Mailman Provisioning Plugin
 
 `CO Email Lists`:gear: in COmanage include
@@ -124,7 +124,7 @@ We will now implement what you have specified on your worksheets.
 
 **REQUIRED ROLE**: any Active `CO Person`:gear:
 
-## Sign into the Registry
+## Sign into Registry
 
 1. Using the credentials you specified as part of the COmanage setup (or the `CO Administrator`:crown: that you established in the last section), sign into the system.