[Design] [Scooby] Defining 1.0 Goals

[Mimi Yin]

Perhaps one of the first questions we should ask ourselves is:

What are the criteria by which we evaluate possible directions for  
Scooby in the 1.0 timeframe?

1. How will Scooby 1.0 support the goals of the OSAF-Chandler/Scooby/ 
Cosmo eco-system? (Assuming we have a clearly articulated goal for  
the eco-system).

2. How will Scooby 1.0 attract more users? How will Scooby 1.0  
attract more users for Chandler? or Cosmo?

3. How will Scooby 1.0 forward the cause of open-standards?

What are some others?


Then I think we can ask: Given, these higher level goals, what user  
problem(s)* can Scooby realistically solve in the next year?

*User problems are targeted usage scenarios that define a specific  
user need. User problems are finer grain that more general  
descriptions of functionality, such as, provide web-access to  
personal calendar data. User problems answer the question of "Why"  
does the user want web-access to their calendar data. Understanding  
"why" helps us answer feature-questions such as:
+ Does the user need to be able to edit?
+ Does the user need to be able to create new items?
+ Does the user need to see Chandler-specific metadata?

Some examples of user problems include:
1. Provide university users with web-access to their schedule, so  
they can figure out where they need to go next.
2. Provide university users with a way to browse and "sign-up" for  
campus events.
3. Provide Chandler users with web-access to all the stuff they need  
to be dealing with "NOW".

Once we have a concrete problem to solve, then we can make some  
decisions about what features we need to have in order to solve that  
problem.

Mimi

On Mar 3, 2006, at 3:45 PM, Katie Capps Parlante wrote:

> Hi Bobby,
>
> These are good questions, and I know that Priscilla, Mimi and  
> Sheila are starting to tackle the product strategy for the whole  
> ecosystem (Scooby, Chandler and Cosmo).
>
> With that in mind, my personal thoughts about some of these  
> questions...
>
> When we talk about big picture goals, we perhaps have two  
> timeframes in mind: a grand vision (5 years out) and the 1.0  
> release for each project (12-18 months). It is good to have the  
> grand vision in mind because it inspires us, but the critical  
> decisions right now are about the 1.0 strategy. The 1.0 releases  
> are very important, because they are our shot at getting users. Its  
> very important for us to get users to sustain the project, both  
> financially and in terms of getting people to help us build the  
> grand vision.
>
> Bobby Rullo wrote:
>> Hi guys,
>> Now that we are about to release Scooby 0.1 I wanted to start the  
>> conversation on Scooby/Chandler Sharing and interoperability in  
>> general.
>> Scooby right now is a straight-up CalDAV client and knows nothing  
>> about the features that make Chandler special - like having events  
>> that can exist in more than one Calendar/Collection.
>> Some open questions:
>> * How much of Chandler's special* functionality do we want in  
>> Scooby?  And how should that affect interoperability?
>
> In the grand vision, both Chandler and Scooby would implement the  
> ideas that we've been excited about all of this time: from GTD to  
> tagging/labeling to being a shared data hub for all different kinds  
> of personal information.
>
> In the short term, we need to identify the use cases and the target  
> users for a 1.0 release. We've identified calendaring as the first  
> central application, but we haven't flushed it out to understand  
> who would be using it and how for 1.0. Priscilla, Mimi and Sheila  
> will be working on this (in an open way) and this should drive what  
> "special" functionality we include in Scooby.
>
>> * Do we want to extend CalDAV/WebDAV  to accomodate this stuff?
>
> Ultimately, that sounds like a good strategy. In the short term, is  
> that too ambitious for 1.0? I'm interested in hearing more about  
> the options from the folks who understand CalDAV/WebDAV better than  
> I do. ;)
>
>> * Is Scooby just a calendar client, or is it the online version of  
>> Chandler?
>
> I don't think Scooby needs to match Chandler feature for feature,  
> but that doesn't mean it has to be just a calendar client. We do  
> need a narrow enough focus that we can deliver a 1.0 in a  
> reasonable timeframe. Again, Priscilla, Mimi and Sheila are  
> starting the exercise that will answer this question.
>
>>    * In collections that have stuff other than icalendar  
>> resources, what should scooby be expected to do?
>
> Scooby could ignore the data if the feature set for a given release  
> doesn't need it. This decision should be driven by what features  
> Scooby wants to support for a given release.
>
>>    * How about plug-ins? Should Scooby have server-side plugins to  
>> match the client side plugins?
>
> I think the plugins make more sense for Chandler's 1.0 plan than  
> Scooby's 1.0 plan. A PIM enthusiast with just a little bit of  
> programming knowledge could customize the environment with some  
> Python code and share that parcel with other users, who would  
> download the parcel into their client. For Scooby, it requires  
> someone to run a different instance of Scooby on their server to  
> add their modifications.  Yes, Scooby should be written cleanly and  
> have a modular architecture so that people can run Scooby on their  
> own server with modifications, but that is a different bar than  
> allowing people to mod their personal copy of the client.
>
> My 2c is that Scooby server-side plugins to match the client side  
> plugins is *not* a requirement for 1.0, but am interested in  
> hearing from anyone who disagrees.
>
>> * What ARE these special features?
>> *special here means the functionality is not something than can be  
>> expressed with WebDAV or CalDAV semantics, like the events in  
>> multiple calendars example above.
>
> Off the top of my head:
> - bidirectional references between items
> - collections and how they are constructed (see ongoing thread  
> about collections)
> - stamping (one item has attributes from different "types" e.g.  
> mail and tasks)
> - events in multiple collections (calendars)
>
> I think you are correct that we need to make some decisions about  
> what the shared data model will support. The key piece here is  
> probably the "sharing format" which is going to need to be stable  
> across releases. Morgen is looking at this in more detail now.
>
> Cheers,
> Katie
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design