[Design] [Scooby] Anonymous access to read-write tickets and security

[Priscilla Chung]

Please see my notes in line.

On Jul 18, 2006, at 11:59 AM, Mimi Yin wrote:

> I think there may be some implicit assumptions in what Priss is 
> describing that I'm saying don't hold true for small workgroups.
>
So this is where I'm a bit confused when we talk about small workgroups. 
There seems to be two types of small workgroups and my belief is if we 
focus on one, we may be able to satisfy the other as well. What I am 
hearing from you sounds more like we need to satisfy one and putting in 
a layer of security will make it too complicated for the other group to 
work effectively.

Here are my definition of the two types of small workgroups:
1. Small professional organizations including schools, fraternities, 
home owners association,  docent co-ordination for galleries etc. have 
policies and structure
2. Informal gatherings (such as book clubs, household scheduling, study 
groups etc.) which do not have a policy/structure, but usually have an 
organizer to set up the meetings. The roles may switch and it's pretty 
fluid, but someone usually takes the lead for organizing.

Please chime in if you don't think I am correctly identifying the small 
workgroups. Now if it's a staging issue in product planning and we're 
making the conscious decision to only target #2 first, then perhaps we 
had not thought through about our target user for Scooby 0.3.

> The main question we're trying to answer is:
> How is the nature of trust different for small groups (5-30) versus 
> large groups (100s), versus gigantic groups? (10s of thousands)
I'm not really sure that the trust is really that different from small 
organizations vs. large ones. You can have a small group that is formal 
and a large group that is informal. A groups dynamics may not be 
entirely related to size.

> The answer to this question is the key that will unlock the mystery of 
> how to get small groups to use collaboration software (beyond email).
>
So in the two workgroups I described: The professional organization 
chooses the software its members would use to collaborate. The members 
would be obligated to use this software. In an informal gathering, the 
group may collectively decide to use the collaboration software. Though 
it still takes a person to lead and organize the gathering and push the 
other members to use the software. In the book club interview we did, 
one used evite to organize and the other used e-mail. Whatever form of 
communication the organizer chooses, the members will generally follow.

> Assumptions for Beta/1.0 Ecosystem:
Maybe there are some misunderstanding in language that I used. Let me 
try to clarify.

> 1. There is no IT department setting up a sharing service for the 
> 'company'. (Calendars without IT is and has always been a main tenet 
> of our product plan.)
So here is a question I have about the ecosystem: If a small company 
were to use Chandler/Scooby/Cosmo without the OSAF hosted service, is it 
still considered part of the ecosystem?

I understand that in the informal gatherings, Calendars without IT 
support is important for adoption. I don't think I said there needs to 
be a formal dedicated IT department.There are however care taking tasks 
that are done with any computer software. If a small workgroup does not 
choose to use the OSAF hosted solution, then someone in the workgroup 
would need to set up the Cosmo server. If so, then Cosmo should be easy 
enough for small workgroups to set up on their own.
> 2. In many cases, there isn't even really a 'company' or 'company 
> policies'
I think I defined this to 'Informal gatherings' work group.

> 3. You may not even be given a 'company' email address
Also part of the 'Informal gatherings' work group.

> 4. Everyone knows each other in the collaboration group. In other 
> words, there is intrinsic, unstructured trust. It would feel rude to 
> give different people in the organization different grades of access 
> privileges to shared workgroup information.
I disagree. If people in the workgroup have a stake in the outcome of a 
collaboration, it may change the groups dynamics.

> 5. There is a real need for more than 1 person to collaborate heavily 
> on a single item. The Stamping Storyboards sketch this out in great 
> detail: 2-3 people collaborate heavily to send out a meeting 
> invitation / agenda proposal.
>
So clarifying what you're saying about collaborating on a single item. 
This is an example of where ACLs can help focus the collaboration by 
eliminating clutter and distractions in shared collection.

> *Business Question. *Would an organization like LPFI normally have 
> such resplendent IT resources if it weren't affiliated with other 
> geeky organizations?
>
Yes. It would most likely be a contract IT support or in many cases, 
someone in the group plays the role of technology support. In larger 
organizations, they can afford to have specialists. A person to set up 
e-mail, another person to set up development tools, etc.
> In the end, it's not just a matter of small workgroups require less 
> security than large workgroups. It's really that small workgroups 
> won't work / can't work in security frameworks designed for large 
> workgroups.
>
I don't think this is an all or nothing decision. You don't have to have 
a super heavy handed approach with security. There are some social rules 
that structure interactions. ACLs can help provide structure for a 
collaboration. Just because you have the ability to add that layer of 
security doesn't mean you have to use it.

-Priscilla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060719/0ec88f4b/attachment.htm