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

[Mimi Yin]

I think there may be some implicit assumptions in what Priss is  
describing that I'm saying don't hold true for small workgroups.

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)

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:
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.)
2. In many cases, there isn't even really a 'company' or 'company  
policies'
3. You may not even be given a 'company' email address
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.
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.

Business Question. Would an organization like LPFI normally have such  
resplendent IT resources if it weren't affiliated with other geeky  
organizations?

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.

Here is a pre-internet analogue to our URL ticket situation:
A small business (a partnership that has anywhere between 2-10  
temporary to semi-permanent employees at various times) has 2 phone  
lines. 1 is public-facing, for the business. The other is a private  
line for family, close friends and employees that are closer to the  
permanent end of the spectrum.

Both are phone numbers. The private line does not have a white list  
or a password. Both 'could' be passed out to the public in a way that  
renders the private line useless.

However, the private line, for the most part, remains private. Why?  
Because the group is so small that:

1. The members of the group have personal relationships with each  
other. Therefore, members have a vested interest in not screwing up  
those trust relationships by carelessly giving away information that  
was entrusted to them in confidence.

2. The shar-ER pretty much knows everyone they've given the private  
line number to and knows enough about them that when there is a leak,  
they could probably figure out who leaked the number. (e.g. Why are  
all of Kelly's friends calling for her on the private line?) The fact  
that this is possible gives sharees extra incentive to not violate /  
compromise their trust relationships with other members of the group.

As for when will the security framework change?
My personal take on that issue is: The security framework should  
change when:
1. We can make it more secure without making it more onerous for  
small workgroup users.
2. We are ready to target medium to large size workgroups that have  
different group dynamics and different trust relationships.

Mimi

On Jul 18, 2006, at 11:14 AM, Brian Moseley wrote:

> On 7/17/06, Priscilla Chung <priscilla at osafoundation.org> wrote:
>
>> We've agreed that the target user for Scooby 0.3 is an employee at
>> OSAF who is to update their PTO on the office calendar.
>
> i agree with everything in this section. this is how i expect basic
> shared calendaring to work in an office setting.
>
>> Planning for the Target Users at 1.0
>>
>> Now let's think of it in terms of a visiting 'Casual Collaborator'
>> target user, someone who is outside of the organization and would
>> communicate very infrequently.
>
> this is where you get into areas where creative solutions are needed,
> but i can't really provide anything beyond the basic office shared
> calendaring, which is all i've thought about in detail. all i can say
> is that while i see the need for some level of anonymous interaction
> with shared calendars, i'm worried about being too relaxed with
> privacy issues.
>
>> One final thought. If we are consciously making the decision to trade
>> low security for higher adoption for now–when does enforcing more
>> security become a higher priority?
>
> yeah, when? :)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

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