Calendar:F2F Intro Notes

Attendee Introductions

dmose: Paid by Oracle to work on Calendaring, "calendar to help manage and organize information"

Matt - worked on Calendaring for part of Cornell U. Currently seeking employment. Worked on Mac theme, converted prefs to toolkit, localization. Wants to help the app get out of its incubator state - cleanup old/dead code. "Make calendar a first class aviary app."

Joey - Involved in Calendar for a year and a half. Moved Sunbird to Lightning Views. Did a lot of the alarm code. Interested in extracting calendaring data from web pages since calendar web publishing isn't here yet, and the bar needs to be low. Working on Sunbird because he's looking for a good calendaring solution for himself. Wants calendaring to be more flexible, e.g., daily events that don't have a fixed time, or some 2 hour task that needs to be done in the next month. "Make calendar handle my flexible schedule"

Shaver - long time Mozilla person. Did initial Lightning work, extraction from Sunbird. Interested in calendaring initially because there was an opportunity to get Oracle to pay people to work on Mozilla calendaring, and there was no good calendaring out there, especially open source or cross-platform. There's an opportunity to use the Mozilla reputation and Firefox halo to advance the way calendaring is done, move from enterprise to person to person calendaring, flexible events like Joey described. Interesting technical challenge, and we can make a difference to people. Extensions built on Sunbird/Lightning could be really huge and provide lots of innovation in calendaring, similar to Firefox extensions. "Make calendaring useful and available to everyone".

Discussion - How to turn To Do List items into events - eventually To Do List items should be scheduled.

MVL - involved in Mozilla for a couple years. Looking for a calendaring solution for himself to stop missing meetings, also wants to be able to use handheld for calendaring. Has worked on calendaring for two or three years. "Don't miss opportunities".

Stefan (ssa) - works for Sun. Open Office users need an open source calendaring solution alternative to MS Office. Server group has a wCap calendaring server and they want a fat client to run against it. Many customers are interested in it. Especially interested in Lightning because they want an Outlook-style integrated solution, mail/address book/calendaring. Eight people at Sun in Hamburg working on this code. One marketing guy gathering requirements from customers and server people. "Provide an Outlook alternative"

Chrisj - User experience team of Star Office. Specifies UI, does user studies, was asked to join Calendaring team at Sun. Looking for a good alternative to Outlook, w/o having to relearn everything, like Chandler. "Getting things done!"

Discussion re fidelity to Outlook, vs. learning new UI model. Nobody recommends Outlook because they love it.

Clint (ctalbert) - works for SimDesk. Started looking at calendaring & Thunderbird before getting hired at Sunbird. At Simdesk, injected Sunbird .2 into Thunderbird. Current offering is a server solution, and want to move to free open source clients and pay for service. "Organize & connecting people"

bienvenu - Calendaring/Lightning very important for Thunderbird users/deployment.

History

MVL - first task was to fix ics backend implementation to be more flexible, w.r.t. the initial calendaring extension. Then, made extensions standalone, i.e., Sunbird.

Shaver - Lightning was inspired by the realization that e-mail and calendaring go together like peanut butter and chocolate. Wanted to piggy back on Thunderbird user base, and show extensibility of Thunderbird. Sunbird had some backend issues that made it not fit in with Lightning, e.g., synchronous i/o, so backend was torn apart to make it shareable between Sunbird and Lightning. Jan '05 Cal-Dav(?) was demo'd at a conference. Then some members of the Oracle calendaring team left Oracle and full-time calendar work. Dmose took things over from the Oracle side. Still a need for a stand-alone calendaring apps - MS and Apple have stand-alone calendaring apps.

Lightning & Thunderbird - pretty likely that TB would like to have Lightning as an optional install-time extension.

How to not break Lightning when Thunderbird changes. If not frozen api's, at least get informed when Thunderbird changes something that Lightning depends on. Shaver is trying to get overlay targets in xbl implemented to make the integration less fragile. Communication is the most important thing; freezing api's and id's costs much more than the benefits in terms of what products you end up with. Having a Lightning startup test on Thunderbird Tinderbox page would be a big help. Differentiation with competitors - most we can do is do competetive analysis: see what they've done right and wrong. But our limited resources don't allow us to really go for feature parity for feature parity's sake. Focusing on our typical end-user needs should be sufficient. We should have a goal that new features/UI can be measured against. Playing around with the user experience can be a big differentiation for us. Making it as easy and fun as possible to use your calendars will go a long way to having users forgive missing features.

Dmose has been trying to get some help from Mozilla for project management/planning which could help in feature planning/differentiation.

How to do we want to describe our goals, feature specifications? flash demos? Feature specification means different things to everyone.

Performance - avoiding premature optimizations is good - profiling. Setting goals up front will help - e.g., how many events do we want to be responsive with? What UI is important to be fast? Where is OK to feel the effects of scale and where isn't it? Can we avoid tearing apart and re-assembling the backend for performance? Can we pre-fetch around a local point and avoid pulling everything into memory? Recurring events cause lots of issues. Will we need schema changes to speed up handling of recurring items, or can we simply flatten/unfold the recurring items into the database?

Backend server support? What kinds of servers do we want to support? Which servers do users not have a choice about, e.g., Exchange. If we support Exchange perfectly, IT departments will still be motivated, because of cost, to migrate away from Exchange. What protocols, e.g., gData, ship by default, which protocols are in the tree, what do users want, what incremental adoption increase will we get for a given protocol? Can extensions help us support new protocols? It's best to have stuff in the tree so that code doesn't bitrot, as long as it can be triple-licensed. Does it help demonstrate the benefits of open source calendaring?