The Chandler Project Blog

It’s been a couple of weeks since our last update.

Some developments on the release front…

• Last week we released Chandler 0.7.4.
• There was also a Chandler Server release, 0.12.0.
• We are close to rolling out a Chandler 0.7.4.1 which addresses a bug that complicated upgrades from version 0.7.3.

We have started making progress on our short term strategy which Katie Parlante outlined in a blog post last week.

We have outlined a prioritized list of desktop bug fixes that we feel address some of the pain points for our users. Grant has started working on many of these and you can track our progress on the wiki. We have already started removing some components of the UI that were confusing users. Our Thunderbird plugin, although still in the work queue, has been prioritized down a bit so that Brian Kirsch is available to help us on the web side for the short term. Phillip Eby is wrapping up his work on setuptools and should have the 0.6 release out today.

On the web side we have been spending quite a bit of time working out the web work queue and floating various proposals and ideas on the list. Mimi recently sent out a list of critical bugs to fix in the Web UI that address some of the barriers for people getting started. We have also been working out the detailed use cases and designs for some of our web widgets. We are currently in the process of prioritizing the work queue and dividing up the work between Travis, Jeffrey and Brian. Travis has already implemented a very early stage quick entry widget that people can play with. He is spending most of his time in the next few weeks porting our current web UI to Dojo 1.0. Randy has been circulating a proposal on the list to tackle a security hole when users share read only items. We seem to be getting close to a final solution.

We are in the process of updating the wiki so that it captures our plan of record and all the work queues and prioritizations.

Lastly, we are still taking care of a number of lingering logistical and administrative issues pertaining to the reorganization.

With so many changes around the restructuring we thought it would be helpful to start blogging about our project status on a regular basis so people get a sense of the ongoing activities.

While we work the strategic next steps, our new team will focus on getting a release out for both the desktop and server.

+ Chandler Desktop 0.7.4 will be released in the next week or so. Some highlights…
+ We have addressed a number of sharing and recurrence bugs found through usage.
+ We have added a new German localization.
+ The recorded scripts branch was integrated, which is more of a development item.

+ Cosmo Server 0.12 will also be released this week. We fixed a few bugs found during hub usage and addressed a number of security bugs.

A more detailed summary will be sent out with each release announcement.

Over the next several weeks, we will be spending most of our time working out the details of our long term roadmap and goals. Our smaller team will be coming together for an off-site at the end of January where we will engage in a number of sessions around planning, strategy and marketing. We have been using a shared collection in Chandler to collaborate on a number of different projects and have published a public Chandler Project collection so others can track our progress.

We continue to work closely with our current users and are in the process of scheduling a number of detailed user interviews which will help us refine our marketing message and provide us with more detailed information about usability patterns. We are currently actively working on addressing a number of security and usability issues. We are also looking for ways to reach out to more users and are investigating projects such as building a Thunderbird plug-in which was posted on the blog and the design list recently.

Finally, as with any reorg there is a period of knowledge transfer and redistributing responsibilities such as builds, systems support and testing. We are also taking care of a number of administrative type tasks and logistics such as consolidating some of our mailing lists, meetings and revisiting a number of processes to make more effective use of the smaller team. We now have short daily scrum-style checkins.

We have just released our latest milestone, Chandler 0.7alpha3, which you can download at http://downloads.osafoundation.org/chandler/milestones/.

Highlights for this release are – background sync, Intel Mac support and a handfull of performance improvements. We suggest that 0.6 and 0.6.1 users switch to using the calendar with 0.7alpha3. For further details on all the new features go to http://chandler.osafoundation.org/newinalpha3.php

As with our previous milestone, you will need to migrate your data from the previous release.
http://wiki.osafoundation.org/bin/view/Projects/ChandlerZeroSevenAlpha3DataMigration

For those interested in a following our progress on Chandler 0.7, we released our latest milestone, Alpha2 on May 26th. You can download this at http://downloads.osafoundation.org/chandler/milestones/

This milestone features some enhancements to the calendar and a number of bugs fixes reported from our users. We also have the beginnings of some lightweight scheduling workflows and have started to build out other areas of the app such as the table view. For all the details and known bugs go to http://chandler.osafoundation.org/newinalpha2.php

We have already started working on our next milestone Alpha3 which focuses on peformance. For more details about Alpha3 and future milestones, refer to our 0.7 planning page at http://wiki.osafoundation.org/bin/view/Projects/ZeroPointSevenPlanning

Our latest Chandler milestone, M6, was released on Oct 19th. This is a significant milestone for us since we are now officially “feature complete” and the bug fixing phase is already underway.

A list of the latest completed features and known bugs can be found in the milestone report card.

Milestone Notes

About a year ago, the product team at OSAF adopted a planning technique we refer to as “stickie” planning. As it sounds, this involves listing product features onto post-it notes, mapping them onto a whiteboard and assigning them to a particular dot release in our product plan. The features are described are fairly coarse-grain. A stickie might be “calendar month view” or “email forward and reply”. We estimate the size of a “stickie unit” to be approximately one month of work for a developer. We realize that the scope of some features are considerably less than 1 “stickie” and some will be more but for planning at this level, it’s adequate to get a ballpark stake in the ground for our next release. It isn’t until we start to drill down and scope out the details that we can understand if some of these projects are larger or smaller, at which point, we return to the stickie board so to speak for another round of refinements.

More recently, we have taken this process one step further in an effort to use our stickies for a longer-term planning initiative. Our application pivots around distinct end-user workflows. Stickie planning around these workflows helps us ensure that our dot releases aren’t simply a bucket of features that may or may not be useful to anyone, but actually meet a coherent set of user needs. This coherent set of user needs can be described as a workflow track. Each of these tracks in turn has distinct stages of usability in the product. By mapping stickies to a track and a phase, we can articulate some notion of a product roadmap. So with a bit of html and css wizardry, what might this thing look like?

NOTE: Until we fix some bugs, this timeline is best viewed using Firefox.

Roadmap

This visual shows a snapshot of a possible path to get us to a usable Chandler 1.0. I say “possible” since we expect to tweak with this on a regular basis depending on how priorities change from release to release.

Across the top are the workflow areas we have identified so far: Calendar, Email, Dashboard, Dev Platform, Sharing/Collaboration, App Basics (a mix of infrastructure work and basic product gestalt).

Each of the colored boxes represents specific stage of feature area usability.

Embryonic: infrastructure in place with no UI
Initial: test UI
Plausible: user model is in place
Dogfood: testable user workflows
Usable: usable workflows for early-adopters

The sub items in each box list what features (stickies) we think we need in order to reach that stage of usability in a particular workflow track (ie. Plausible Sharing). For example, can we call Email plausible without forward and reply? Probably not.

Another benefit of stickie planning is that the graphical and easy-to-change layout allows us to group stickies in a variety of ways that help us answer questions and load balance. Are the different workflow tracks progressing at fairly comparable rates (even if they are at very different stages of usability)? Is work being distributed across the development team evenly? It also helps us recognize patterns and dependencies. In the past two releases, we’ve been able to finish x-number of stickies, what’s the likelihood that we will be able to accomplish more in future releases? Is there an upward trend in stickies across releases? Can we get to a usable Dashboard without first having at least Plausible Email? If not, how can we move these stages around so the features roll out in the right order?

So what’s next in the evolution of this process? We will continue managing our live “stickie” board, capturing a proposal at regular intervals and hope that we don’t run out of post-it-note colors to choose from.

Our latest milestone was released on Sept 8, 2005. The app is coming together nicely and we are on track for our feature complete milestone due out Sept 28th. You can download the lastest milestone at…

(http://downloads.osafoundation.org/chandler/milestones)

The following report card, summarizes the new features and notable bugs.

(http://wiki.osafoundation.org/bin/view/Projects/MilestoneNotes0505)

I thought I had better post my belated impressions of OSCON 2005 soon or I might as well wait until next year.

This was my first trip OSCON and in addition to simply attending, I was pleased to be able to participate in the CALDAV panel. It was very well attended, with standing-room only, demonstrating that there is clearly a great deal of interest around calendaring and interoperability. Due to some technical difficulties, I was the only one able to get a demo up and running and showed off a few sharing scenarios between Chandler and Cosmo which seemed to generate some buzz from the audience. The BOF immediately afterwards meant more time for Q&A where people asked some tough questions about scheduling. I realized how wide reaching calendaring pain goes when one individual spoke up about the specific challenges of managing calendars for booking a concert venue. The only other related session, was a discussion on the complexity of calendar data interchange, the various formats and clients available. Chandler made the list and did pretty well in a comparison of different clients handling of all day events.

In addition to attending the Chandler presentations and BOFs I also registered for the Open Source Business Review which was a special track of panels geared towards the needs of enterprise businesses. Some of these sessions were more informative/relevant than others. In general, I tried to attend a variety of sessions that I thought would be interesting. I was a bit disappointed that there weren’t more sessions geared towards community building or strategies for product adoption.

A few interesting talks worth noting…

Computational Origami by Robert Lang was extremely fascinating. In addition to impressing us with a detailed cuckoo clock made out of a single sheet of paper, he discussed the math and algorithms behind origami and how those can be applied to solve real engineering problems.

Saul Griffith, one of the keynotes, spoke about Howtoons, one-page cartoons showing kids how to build things with ordinary stuff (Turkey Baster Flute, Shockwave Air Cannon). It was an interesting perspective on how we can expose the younger generation to open-source philosophies and collaboration.

Women in Open Source was a also a great panel discussion. I was surprised to learn that less than 2% of the open source community is female which is significantly less than for closed source development. Based on the animated discussion as well as attendance, I suspect this will be a topic covered at future conferences.

Overall, it was educational, fun and I came away with a much better sense of the wide variety of open source projects that are in the works.

Highlights

• Based on some further analysis of the remaining 0.6 tasks for the apps team, we have decided that we need to have an additional milestone M6 in 0.6. M5 will be as planned on Aug 24th and M6 will be on Sept 14th (3 weeks later). The release date will be adjusted accordingly to Nov 2nd 2005.

Design

• Progress: Mimi presented virtuality vision to osaf last week.Will work on follow-up paper and thinking about big issues for 0.7 and logging 0.6 bugs. Sheila helped with estimates for remaining 0.6 work and coordinating recurrence/timezone tasks.
• Plans: Final review of sharing spec, checking tasks and bugs for M5, 0.7 planning, CSG re-calibration mtg planning and OSCON demo.
• Personnel: Sheila at OSCON Aug 3-5

Applications

• Progress: Proceeding on M5 work. All 0.6 tasks logged in bugzilla and swagged.
• Plans: Completed assignment of whole 0.6 workload left and identified necessary 3 week M6. Continue with M5 tasks.
• Personnel: Philippe, Bryan, Jed and John are at OSCON next week.

Sets/Collections

• Progress: Integration work started and in progress.
• Plan: John, continuing with integration and addressing issues with support from Ted and Andi.

i18n

• Progress: added Text (an alias for UString, LocalizableString), added new repository types for schema api. Updated specs and reviewed i18n tasks with apps team.
• Plan: Refine gettext API proposal to allow dynamic registration of localization files, Begin working on i18n Repository additions, meet with QA to design test.

Sharing/Webdav

• Progress: Fixed a bunch of sharing bugs. zanshin: Most of the way through implementing detection of CalDAV support, the MKCALENDAR method, and correctly retrieving the CalDAV calendar resource type. Detailed spec review.
• Plan: Continue Zanshin CALDAV work, publish individual ics files, support unpublish and unsubscribe, work on sharing dialogs.

Security:

• Progress: Set date for ACL presentation
• Plan: Investigate the differences between the different ACL systems we will be using, review zanzhin plans and API to figure out what makes sense regarding higher level ACL API.

Recurrence/iCalendar/Timezone

• Progress: Implemented saving and retrieving default timezone, first cut at tz popup in calendar. Added support for handling this and future events.
• Plan: Proxy work for editing recurrence, handle import of calendar with recurrence, some beginnings of gui work for recurrence/tz.

Dev Platform

• Progress: more work on Flickr parcel, ported del.icio.us parcel to schema API, more parcel loader work (implemented experimental alternative, analyzed perf), moved parcel and parcel.manager out of chandler.pack. Implemented draft startup and thread extension points.
• Plan: look at implementing other extension points in terms of Startup and Thread, experiment with translating current parcel.xml files to Python, add progress callbacks to the “Startup” extension, to support displaying startup status in the progress bar

Other Projects:

• released PyLucene 1.0

QA

• Progress: Testing this week’s checkpoint, continue with idle chandler memory tests, code review CPIA script and working on next set of enhancements necessary to use CPIA script for regression testing.
• Plans: Add utility methods and test cases to CPIA script, develop test plan for i18n, usual review and triage of tasks and bugs.

Cosmo/Scooby

• Progress: Added support for MKCALENDAR.
• Plans: Mat’s started July 25th and will coming up to speed with chandler and cosmo and beginning a research project on ajax and other advanced javascript techniques and technologies. On the Cosmo front, continuing to add CALDAV support and working on GETing and PUTing icalendar events.
• Personnel: Brian M at OSCON next week.

Community

• Plans: OSCon Aug 1-5 and planning for Aug CSG meeting

IT

• Progress: 30 tickets closed this week. Office network perf plan approved, backup status evaluated.
• Plans: begin network perf and backups updates. Implement cosmo demo server (pilikia replacement).

Improving application performance is one of the many projects ongoing for 0.6. One of the steps in this process is to select the appropriate hardware that we will use to run and benchmark our performance tests. Our ballpark was to pick the mid-range setup that a consumer would have bought in 2003.

Windows/Linux: Pentium(R) 4, ~2 GHz, 512 RAM
Mac: G4, ~1GHz, 512 RAM

The 3 machines we have decided to use, along with configuration details are listed below. We realize that these are a bit faster than our original target but feel they are close enough to meet our needs for 0.6.

1. Winxp
* Processor : Pentium(R) 4
* CPU : Single CPU, 2.8 GHz
* Memory : 512 MB RAM
* OS : Win XP Professional Edition SP2

2. Mac Mini
* Processor : 1.25 GH G4
* CPUs : Single CPU, 1.25 GHz
* OS : Mac OSX 10.4 Tiger
* Memory : 512 MB DDR SDRAM

3. Linux
* Processor : Penitum(R) 4
* CPU : Single CPU, 2.8 GHz
* Memory : 512 MB RAM
* OS : Red Hat Linux Fedora Core 4

You can read more about the performance project on the following wiki page (http://wiki.osafoundation.org/bin/view/Chandler/PerformanceProject)