Meeting notes: http://wiki.osafoundation.org/bin/save/Journal/DesignSessionCosmoScoobyMerge

Highlights:

Issues we discussed were largely orthogonal to the Cosmo/Scooby merge issues being discussed on scooby-dev.

There are 3 product areas defined around 3 kinds of users:
+ Ecosystem end users trying to do calendaring, task management and other collaboration scenarios
+ Developers and power users who would like more of a generic file management view of data on Cosmo. This is similar to how people currently use / will use the Chandler repository viewer.
+ Server/Service administrators.

Next actions:
+ BCM to propose a vote on the cosmo/scooby merge
+ Primary stakeholders make the decision: BCM, John T, Bobby, Matthew
+ Voting is just a polling technique

+What's the next logical discussion to have. Wait for John T to come back and after OSCON
+ Summarize Cosmo/Scooby merge thread: John T?

+ Need meeting for Project planning issues

Question: How do these target users and usage scenarios speak to the merge? Answer: This discussion clarifies open questions about how UI grows on both Cosmo and Scooby

Fallout:

+ UI for Ecosystem end-users, calendaring, task management, collaboration scenarios
+ UI for administrators
+ UI for browsers and debuggers

Thx, Mimi


On Jul 18, 2006, at 9:42 AM, Sheila Mooney wrote:

Today from 2:30-4:00PM, we will be having a Design Session in Whoville on the Cosmo-Scooby Merge issue that has been brewing on the Scooby-dev list.


Brian Moseley, Bobby and Matthew (John T is out this week), will be hosting a question and answer session with PPD as we try to wrap our heads around how a Cosmo-Scooby merge would affect product planning, marketing and product positioning and organizational / logistical issues. These discussions will span multiple sessions and We WON'T be addressing all these issues in today's meeting. This discussion will focus on the various UI requirements these products will need.

Agenda
30 minutes: Collect questions and Issues
55 minutes: Q&A
5 minutes: Next actions

Below is a preview of some of the questions we have. We don't expect to cover everything. However, we would like to kick off a conversation that can be continued on the list.

1. UI requirements. e.g. Does Scooby need admin UI? Maybe spend 5-10 minutes brainstorming all the different usage scenarios we need to support. Does this change our 1.0 Scooby sticky plan?

2. Branding, Marketing and Positioning.
+ How is Cosmo-Scooby (the OSAF version) separate from the Hosted Service? As an end-user, do you really think of all 3 as 1 product/service; like .Mac?
+ Will Cosmo-Scooby be something a 3rd party can set up on their own? Do we need UI for that?

3. Target users. Who would use these UI elements? For what purposes?

4. Interoperability. What clients do we want/need to interoperate with to fulfill our target user needs?

=====

Issues we're not going to discuss (waiting for John T. to return before addressing higher-level product strategy issues.)

1. Interoperability. 
+ How does this change how we support CalDAV clients down the road?
+ Short and long-term: Do we hope to interoperate with other clients on their terms (just CalDAV) or do we also aspire to interoperate with other clients on our terms (stamping, user-defined attributes, etc)
+ What are different options for how we might satisfy our Ecosystem scenarios AND interoperate well with other CalDAV/WebDAV clients and servers? Can this be staged?

2.Scooby as more than a CalDAV client.
+ Scooby and Morgen's sharing format proposal
+ Implementing Chandler-specific features in Scooby (e.g. Stamping, User-defined attributes, etc)

3. Repository sync. How does this affect issues like:
+ Syncing my Chandler world in Scooby
+ Syncing my Chandler world in a second Chandler client on another machine

4. Branding, Marketing and Positioning.
+ Up until now, Scooby was a CALDAV web client...Is it now, the web-face to the OSAF Sharing Service?
+ Will Scooby be able to subscribe to calendars on other CALDAV clients? shares on other WebDAV clients? 
+ These questions apply to Chandler as well. How does this affect the sharing format discussions for Chandler? Currently, Chandler can subscribe to calendars from other CALDAV servers ie: rpi.

+ Does this affect how we name releases? Is there still a Scooby 0.3 and Cosmo 0.5 or is it just one thing..ie: Cosmo/Scooby 0.X?
+ What should we call this now...Cosby?

5. Organizational logistics. 
+ How will the release schedule work? With a new Cosmo release we want to upgrade Cosmo Demo...I am just thinking of the QA impact since it seems like all 3 products will have to be synched up.

+ What about meetings, PM roles etc but those aren't part of this discussion. Perhaps we could ask questions of the Cosmo/Scooby team that would help the OPS group figure out the right organizational structure.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to