Grouper Users - Open Discussion List

["RL 'Bob' Morgan" <>]

> We're currently thinking of this set of top level containers:

https://wiki.cac.washington.edu/display/infra/UW+Group+Naming+Plan

This seems to be working well enough for us.

Bob's naming rule of thumb:  hierarchies, if needed, should be based on 
naming authorities, ie, a defined group that manages names in its 
subspace.  Taxonomy is to be avoided, especially if the naming authority 
for the taxonomy elements is "me, the architect".  8^)

 - RL "Bob"

On Tue, 23 Aug 2011, Steven Carmody wrote:

> I'm seeking thoughts and experience. Let me provide some background 
> information, and our current thoughts. However, I'm really looking to start a 
> conversation, and hear what other people are thinking.
>
> We've begun to walk down the road to providing departments with 
> department-related groups. We're expecting to provide 1) some auto-magically 
> provisioned groups using information from various Business systems, and 2) 
> delegate to the department the authority to create and manage groups for 
> their specific needs. Beyond that, of course, we have the usual range of 
> departments, from very small to very large, including both administrative and 
> academic. So there's a wide span of requirements and complexity.
>
> Having spent too many years with naming hierarchies of various sorts, my 
> initial inclination is to provide a small standard set of top level 
> containers within each department container. Having a single flat name space 
> at the top level frankly gives me a bad sort of itch; I think our experience 
> with file systems, etc gives us enough hints about the types of groups people 
> will want that we can make some educated guesses about "categories". OTOH, we 
> don't want to over-prescribe a single framework on everyone, and we don't 
> want to force a deep multi-level hierarchy on everyone.
>
> We're currently thinking of this set of top level containers:
>
> -- People (this would contain auto-provisioned groups like Faculty, Staff, 
> Grad Students, Concentrators, student workers, etc). The dept could manage 
> groups containing "affiliated faculty" (eg people in other depts who aren't 
> official members of this dept but are considered to be unofficial members of 
> this dept; some affiliates could be from other campuses);
>
> This container would likely also contain groups related to the administrative 
> structure of the dept. In all likelihood, these would have to be manually 
> maintained by the dept.
>
> -- Projects This would contain groups related to various Projects that the 
> dept is involved with; many of these could contain people from other depts; 
> research groups could contain people from other campuses. The dept would be 
> authorized to manage everything in this container. We're assuming that a 
> Research group would create their own container and namespace within this 
> container.
>
> -- Applications (or Services). This would contain groups that have various 
> privileges within centrally-offered services (eg who can edit/approve changes 
> to the dept web site on the central web server). We expect that each 
> application will include a "grouper-lite-lite" GUI allowing an admin to 
> browse and manage memberships relevant to this application. These groups are 
> placed in a well-defined location so that the relevant application can find 
> them.
>
> -- Other (love that name...) The dept can do whatever they want within this 
> container...
>
> -- a dept can also ask us to create additional top level containers for 
> their use.
>
> -- Note that Course-related groups are placed elsewhere in the hierarchy.
>
> So... what are other sites doing with departmentally-related groups ?