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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
