Anonymous access to read-write tickets and security

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

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