Calendar:Status Meetings:2006-07-26

From MozillaWiki
Jump to: navigation, search

<< previous meeting | index | next meeting >>

Meeting Details

Telephone Info

  • Toll free numbers
  • Access Code
    • 3646989
  • Conference controls
    • *6 mute line
    • *7 unmute line
  • Each time you say something, please say your name first so people know who's speaking

Proposed Agenda Items

  • Discuss status of the following issues:
    • Sharing preferences between Lightning and Sunbird - see this newsgroup thread for background information (lilmatt)
    • Sunbird logo copyright assignment and trademark registration progress (lilmatt)
    • 0.3 release: Who's driving this bus?
    • Tasks-in-View
    • Roadmap


  • lilmatt
  • ssa
  • dmose
  • jminta
  • mvl
  • ctalbert
  • mickey


All action items are in blue

Sunbird Trademark

  • lilmatt has been working with Frank Hecker and other folks at Mozilla Foundation to get proper paper work filed. Once things are filed, the lawyers will vett everything we'll be done.
  • This will get us the "R" and "TM" added to our logo
  • This is another reason the generic branding had to happen.

Sharing Preferences

  • Not enough people weighed in on the newsgroup post.
  • The main goal is to reuse the code from Sunbird in Lightning
  • It seems the best way to do that is by putting in a single Calendar page in the Thunderbird preferences with several tabs.
  • It might be best acheived through overlays rather than javascript includes
  • There are many questions revolving around where this code would live in the source tree. These are not resolved at this time
  • It was decided that for now, it will be good to keep the preference settings apart so that Lightning can serve as a ground for UI expirimentation on this front, such as with alarm preferences.
  • However, there are several defects that seem to be blocked due to the lack of Lightning preference settings in Thunderbird.
  • For now, things will likely remain as they are which will allow some UI expirimentation in the nightlies with the preference UI, but we will need to solve this problem sooner rather than later.
  • lilmatt will post the items from this discussion to the NG and discussion will continue there (if needed)

Driving the Bus

  • Wanted to ensure that we are making progress toward 0.3 release
  • The blocking list is not written in stone. Should feel free to add/remove items from it.
  • Do not want the process to detract from the time spent moving toward the release. Do not want to be too process heavy.
  • Decided not to use metabugs because Bugzilla support is not sufficient for them
  • jminta will drive the 0.3 release
  • Add permanent item to agenda on meetings for 0.3 release status
  • Add a wiki page to track progress toward 0.3 goals

Tasks in View

  • Lots of discussion in NG on this
  • Semantics of tasks in view and tasks in general are poorly defined in current implementation
  • Decided to turn the "Tasks In View" option off by default for 0.3 release only
  • Everyone is willing to allow this, acknowledging that we will reivew the task support and possibly remove this feature entirely if need be.
  • UI owners will discuss this compromise, and will determine if this is something they can live with for 0.3.
  • The entire idea of tasks vs. views requires much discussion and design and that is defnitely a post 0.3 decision.
  • In the meantime, people should start trying to use Tasks in other programs and understand the benefits and shortcomings of them so that we can create a better model.


  • dmose will pull the remaining TODO's from the Toronto discussions and begin making a true 1.0 road map
  • From a PR standpoint, there must be some roadmap document for 0.3
  • That document should contain a decent amount of granularity so that people will have a good sense of what the 0.3 release contains. However, the document should not be a list of bug numbers.
  • We will use the Firefox template for this page: Firefox2/Requirements
  • The 1.0 page will be a bit higher level than that page; however.
  • lilmatt will remove all old roadmaps from the wiki
  • Do not want the development process to become dictatorial; want it to remain community driven.
  • A clear roadmap will give people a sense of what we're doing, help the developers to stay on track in their specific area of expertise.

Raw Notes From the Telephone Conversation

Here is the raw meeting log from the call.