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

Jeffrey Harris jeffrey at osafoundation.org
Wed Jul 19 18:45:23 PDT 2006


Hi Priss,

> 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.

Interesting.  I think I understand the line you're drawing, but I don't 
really see these as being distinct in anything specific except how they 
name themselves.

In both groups, there's likely to be some amount of structure, *some* 
willingness to conform to rules, and some amount of tech support 
available within the group.  But in almost all groups of 5-30 I've met, 
whether professional or not, I've seen people bump up against 
curmudgeons or insufficient tech support resources.

[snip]
> 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.

Well, of course one can only make statistical observations, not definite 
statements about these groups, but my observations of very-small and 
small groups has led me to believe there are, broadly speaking, trust 
shifts at 5-8 people, again at somewhere between 30-50, and another one 
above 100 or so.  All those numbers are heavily affected by how 
carefully the group selects for socially compatible membership, but the 
shifts appear nonetheless.

>> 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.

The members will generally follow in both types of organizations, but 
you almost always bump into the "Pine user who refuses to read HTML 
mail" phenomenon, and I don't think the density of these issues is 
related to whether the organization is professional or not.  I think it 
tends to be more connected to whether you try to get people to create 
accounts (or use a different email client!).

[snip]
>> 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.

Hmm.  There may be different kinds of collaboration in the mix here. 
I'm certainly not insulted when a friend invites me to a party using 
evite. I want to throw my net wide when inviting people to parties, 
inviting people I don't trust, so making it easy to limit people's 
participation in creating the list of attendees is very helpful.  This 
is certainly one form of collaboration.

My idea of the kind of collaboration that's happening in the 
Chandler/Scooby workflows is pretty different from this, however, much 
more bi-directional.

It would of course be cool to allow Chandler/Scooby do evite-like 
things, where invitees could change the shared data in very restricted 
ways.  Perhaps the museum docent could invite a dozen schools to an 
event, they could see who else was coming and confirm attendance, but 
nothing else.  Or the docent could even let schools schedule themselves 
in a first-come-first-served way, filling unused, pre-defined time 
slots.  ACLs would clearly be helpful here.

But I think enabling the non-ACL parts of this workflow in a generalized 
way would take a lot of work, so I thing we're not likely to get to it soon.

Sincerely,
Jeffrey


More information about the Design mailing list