Hiring

Dan Steinecke started working full-time yesterday -- QA Intern

Discussion of Cosmo and Scooby staffing levels

Status

Chandler: 30-40 documentation bugs

• Possible to fix blockers by the end of this week, depending on incoming blockers
• Trying to go into office dogfood very shortly and broaden circle a bit

Dogfooding on cosmo demo server:

• Fix from Jackrabbit
• Java 1.5 required
• IT's cosmo servers aren't Java 1.5 ready yet -- eta 3 days to deal with this
• Need to consider pulling 1.5 back out
• Mitch asks whether we need more process for considering architectural changes to Cosmo, particularly that affect cosmo demo servers.
• Dogfood goals: Cosmo availability, more than just Chandler availability. Need performance and stability goals for Cosmo as we've had for Chandler. This will help us know how to set expectations publicly.
• The value-add of Chandler 0.6 integrally involves calendar sharing -- that's the differentiator, and why we're reluctant to release 0.6 if cosmo doesn't allow smooth sharing yet. * Consider resource shifting to Cosmo temporarily as well as long run staffing
• Can we have clearer goals? or at least are our goals clearly communicted?

0.7 planning

Going round the table: "What's critical for 0.7?"

Lisa: a short release should be considered a critical feature of 0.7

Katie: A usable table, and some non-calendar features, to prove that we're an integrated PIM. Continued investment in infrastructure (CPIA refactoring). After 0.7, or possibly two short releases, we should have a strong sense of the API we're supporting.

Philippe: The dashboard is a good focus point and helps us make inroads into longstanding wx issues. Need a tight vision like we had for 0.6 -- an equivalent to "usable calendar", quickly statable. We need to make progess on email, so as not to lose mindshare in community. On process, we need high quality (usable and demoable) milestones all along.

Sheila: Channel energy into table. Infrastructure investments. Fixes of areas we deferred fixing at the end of 0.6 -- stamping, for example.

Ted: Usable, high-quality milestones. Ramp up test automation, particularly UI tests. Make progress on the virtuality so we have time to prove those ideas. Performance for 3000-item repository and beyond -- put pressure on this with email functionality.

Jared: Features that block dogfood: Synchronization to palm. Data safety -- good upgrades.

Heikki: 1. Continuing performance work, new goals for 0.7 and definitely don't regress. 2. Linux packaging [ted concurred] and switch to Ubuntu. 3. WebDAV ACL to improve security above tickets. 4. PDA synching.

Mitch: Let's move this discussion to a mailing list. Figure out how to do this kind of discussion publicly, as part of the evolution of the project (Sheila will pursue). As far as my perspective goes, we need to shift from thinking of ourselves as a client, to thinking of ourselves as a network system. Your calendar should just work on your PC, offline, on any device. This is a mindset shift to thinking about systems of interrelated pieces.

We know we'll need a set of performance targets, and some features we just don't have which are part of everybody's definition of what a calendar does: freebusy and search. Endless calendar polish is not on the must have list. I'm for the dashboard though we need clarity on what we're developing - whether the vision is oriented around tasks, the comprehensive vision, or .. ? We have process to develop clarity here, my personal vision is around integrating tasks cleanly with events.

We need to do something about PDA synching, I don't know what that is yet. We need to decide first what is the right thing to do. Putting it off doesn't do anybody favours. We'll measure our success by the increase in distributed development and management, too -- a meta-tenet. We need some goals for that and the timing is good for that. The broadened discussion on design list and outside help on cosmo have been good recent developments along that line. We'll brainstorm about community at the offsite.

We've already done a great deal towards making community decision making. There will be hard choices, such as what we do about email. We're going to have to be extraordinarily disciplined about picking goals: we can do CPIA refactoring or table work, but we can't do six or eight infrastructure things.

Beyond Chandler 0.7, if we want to give people an alternative, today, we need to give people a place for sharing and synching that's always available, so the hosted service is critical. The right place for a hosted service isn't quite calendars and events because we can't host this for 50000 today, but there are things that can be done. The foxmarks bookmark synchronization might be the thing. This is our entree into some kind of revenue stream, whether by ads, affiliates, or some other tie-in built from the community coming to the site.

Should the services project be independent of Cosmo? Yes - and the service may not use Cosmo if it's not ready. It's not clear that anybody has the right services to provide around calendaring so some experimentation is appropriate.

Offsite

Ted sent around a list of community issues. We seem to have some buy-in to that. Katie and Ted can work on how to pursue that for an offsite. We may want to brainstorm on some issues. We may not want to spend the entire offsite on community stuff -- we could talk more about the network system view of things, or 0.7 planning. However the 0.7 planning topic is one we'll get to regardless, so it doesn't really fit under the offsite rubric.

Plan to leave some slack in the offsite schedule to deal with things that come up -- it is unlikely we'll leave early.

MOTW: 0.6 push has been good!