Agenda

Part I

• Introduction of the target user for Scooby 0.3 and the usage scenario in which this user may use Scooby. (5 minutes)
  • Why did we picked this target user?
  • Review what the target user does today.

• High-level work flow scenarios on how the target user receives the ticket to read/read-write the 'Office Calendar' (10 minutes - Mimi)
• Walk through 3 different scenarios on how a user could view/edit the 'Office Calendar'. (30 minutes)
• Questions on the target users, work flows and scenarios. (5 minutes)

Part II

• Working back through the workflow, what are the technical limitations? Questions? (20 minutes)
• Discussion questions, capture questions that need further discussion (20 minutes)
• Summarize discussions phasing options, next actions (5 minutes)

Notes

• Active debate about URLs being passed around the ecosystem
• Workflows here: http://wiki.osafoundation.org/bin/view/Journal/ZeroDotThreeWorkflows

• Andi PTO workflows (see pdf at link above)
  • Getting the URL to Andi
    • Mimi: URLs passed around in different channels, the time when they are used might be far from original sending of url
    • Mimi: workflows are complex
    • Todd asks: how much of this is due to not having better ticket management facilities?
    • Mikeal asks: how common is it going to be that tickets/calendars change?
      • What about people hosting their own?
  • Andi adds PTO info
    • Bobby asks: if it "remembers me" on the computer, how is that not having an account? Info stored in a cookie, not creating an account on scooby.
  • Office calendar sharees see...
    • John: is this part of the spec? Sheila: we have some options (like special chandler headers) that we're still working out
    • Mimi: we have a spec for end-user experience, not yet for implementation
    • John: we're not expecting stamping to be implemented any time soon, are we? Priss: Not 0.3. Bobby: we might fake it...
  • Subscribing to the Share via Scooby
    • Bobby: this is all what happens when you click on a link?
    • Mimi: no, click on a link and you preview in scooby, decide if you want to download or subscribe
    • Bobby: even if you are using desktop, you would go to scooby first
    • Mimi: you could have the option, right click previews in scooby, left click subscribes -- you have the option
    • John: changes that take place in the server not reflected in ics file -- so its not really subscribe -- its download
    • Mikeal: no different from RSS feed subscriptions. Mimi: yes

• Useage scenarios (0.3 target user would receive and edit a shared calendar/collection)
  • Scenario A: Does not use a calendar
  • Scenario B: Does not use a calendar, subscribes to scooby
  • Scenario C: Uses some other calendar, e.g. iCal
    • clicking on URL -- automatically launches iCal? list discussion has focused on this. What does URL look like?
  • Scenario D: Existing scooby user
    • Copy URL to clipboard is Esther setting up the share, getting the ticket
    • Todd: Whats the difference logged in vs not logged in? Priss: If you are not logged in, then actions are anonymous (who has made the change).
  • Matt: Only thing to prevent random people making changes to the calendar is that they don't have the ticket, right? Yes. Like wiki spam!
  • Mikeal: we have the same issue on wiki, and in chandler desktop. Well, maybe the signup discourages some edits.
  • Matt: ACLs are supposed to limit the impact of an anonymous user on the shared calendar? Eventually yes. Might not work with anonymous users. At least some other avenue for people with complete read/write access. ACLs are in the future, not even 1.0. Tickets are problematic.
  • Mimi: unclear that we need finer grain workflows for a small workgroup
  • Grant: model is very similar to evite. Only thing stopping me from tweaking someone's evite is that I don't know the url.
  • Mimi: if people needed to add what they are bringing to the office picnic, casual editing scenarios, these might make sense. Hard to know for Esther if she's going to want to allow Andi to edit someday at the time she creates the ticket. Want to allow her to make that decision not at the time she's publishing the calendar.
  • Matt: want to be able to know who can change what.
  • Priss: posted pros and cons for having logins/signup on the wiki -- go through

• Why have a login?
  • You can view it, you can add stuff, but not make other changes.
  • What does Andi do today? Just sends an email. With scooby, has to go to scooby and enter info and then send out email. More steps. Does save Esther time.
  • Problem scenario: Cosmo-demo running at osaf. Priss has a business, running a cosmo instance -- cosmo-home. Esther at cosmo-demo, sends Priss a url. Priss says, yes, I have a scooby account. But the account is on cosmo-demo, not cosmo-home -- different instances. Scooby comes up previewing, will be scooby running on cosmo-demo, not scooby running on cosmo-home. No way of knowing about all instances of cosmos in world. Federated identity? Do we want to solve this problem?
    • dialog -- subscribe to some other server?
    • Mimi: originally idea we wouldn't try to reconcile people trying to share across different servers for chandler desktop.
    • general consensus not to try and tackle this scenario
    • only jabber is doing this
  • logging into photo site? standard in terms of doing anything -- incompatible?
    • tickets can still be used for identifying share
  • should we allow editing without logging in? revisit this decision
    • could be a hobbled edit
  • Mimi: has repercussions with Chandler. You can have read/write access to a share without logging into cosmo. Subtle differences between flicker (public access to viewing photos -- stuff is out there for people to publicly access) and us. No one can go to scooby and search for events -- you have to receive gnarly url. We do require you to have this url in hand. One security measure for another.
  • Matt: without the login, you don't know who did what. Who deleted a shared event.
  • John: Chandler not an online webservice. Just takes one url and put on online forum. Calendar spam -- you don't want to deal with that. Having an account is a standard mechanism to prevent spam.
  • Mikeal: we're a ways from being a huge production service. John: I disagree.
  • Todd: wikipedia is a model. Infinite version control. Allow anonymous access. As a wikimedia user, inadvertently make changes in anonymous mode because it allows it, which causes some problems. If you have an account, it should tell you to log in.
  • John: we'd like to have revenue at some point.
  • Mimi: don't want to turn people away and prevent them from using it at all.
  • John: feature not just used for use case you describe, others will use it for other things.
  • Ashkan: seems to be a need for a security model talk.
  • Sheila: do people feel strongly that we should be revisiting this decision? Yes, seems important for the beta, but not for 0.3.
  • Matt: don't want to take something away from users.
  • Sheila: PPD will figure out right time and forum to bring this issue back up. Jared is important for this.

• Scenario #1 (A)
  • Mikeal brought up the magic URL proposal.
• Scenario #2 (B)
• Scenario #3 (C)
  • Mikeal: webcal:// the rest of the URL can be the same. We can present people with an URL that automatically launches the client. Outlook responds to one of the URLs. caldav:// would be good for Linux. We can look at different platforms, look at useragent, guess. Should be easy way in box to give feedback if URL doesn't do anything.
  • Bobby: wizard or box asking about client
  • Todd: does not degrade gracefully
  • Ted: same for RSS
  • Grant: confuses protocol and content type, which is why it doesn't work
  • Matt: either works flawlessly or you get bupkis
• Scenario #4

• Remember me?
  • Priss: not helpful for remote access, traveling
  • Mimi: might be good for casual collaborator who reuses scooby, even if they don't sit in scooby (Andi, for example)
  • Mikeal: remember things you've done until you sign up for an account, assumption nothing I'm doing thats not private. Bad feature to have if you allow people to modify calendars without logging in. I'm at apple store, anyone who walks by now has access.
  • Mimi: why would you do that at an apple store? (Library or somewhere similar)
  • Mimi: what is the default? Checked or unchecked? If the default is unchecked, you'd have to actively go check it.
  • Mimi: different ticket for every person? ticket represents username password. sort of acls, don't require an account.
  • John: compromise: anonymous user browses around within a session, sign up within a session adds calendars within an account, can remember them.
  • Todd: implementation comment: cookies only associated with a particular domain. If there are multiple scooby instances, remember me status would be per scooby instance. One scooby talking to multiple cosmos, for example.

• Questions
  • how would better ticket management options change the picture?
  • how common is it going to be for tickets/calendars to change?
  • how is remember me going to work and what relationship does this have to accounts?
  • does scooby need to support stamping and when?
  • what email/notification features are we going to implement and how?
  • security model? read/write tickets problematic?
  • webcal://?

• Wrap up: bring up some of these on design list. (Technical conversations that get spawned can happen on cosmo or scooby lists).
• Uncertainties in 0.3 plan:
  • Chandler would have to change to solve "single url" problem -- scheduling dependency
  • 0.3 timeframe -- may not make decision about anonymous read/write ticket issue -- do we go ahead in scooby? we need to make this decision.
  • this has brought up new issues not on stickie plan
  • Bobby: no major red flags (as long as we don't have to implement whole stamping spec)
  • Sheila: need to have separate discussion about how to stage stamping