Calendar:Status Meetings:2006-10-25

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

Agenda Items

Next version planning

Attendees

sipaq, ssa, ctalbert, lilmatt, mvl, daniel, christian, mickey

Meeting Log

There was discussion in the NG about the next release list

Analyzing the "Next Release List"

0.3 stuff is pulled out of toronto list and is put below it (too low level for the "Toronto list") Items in yellow is stuff that should be able to make it into 0.5 with no problems Last week we left off at "Views" Christian has created a pain point list to address the issues with the views.

  • Item creation and modification
    • events vs tasks - there is much discussion on this, there doesn't seem to be consensus. Can we bring the event-tasks discussion to a close so that we can move forward with the task and event improvements in the UI.
      • No other app has abililty to switch tasks to events and vice versa so that might be interesting
      • Perhaps the best way to handle it would be to just do something simple and then we can extend later. Essentially turn the tasks into a grocery list style list
      • Later we can decide how intricate we can make it.
      • We want to keep the feature set w.r.t. tasks fairly low without precluding us from expanding the functionality later. We definitely don't want to become a lightweight version of a project planner. That can be done in extensions or in post 1.0 timeframe.
      • Interoperability will limit how innovative we can get with the tasks as well.
      • For 1.0 we should be certain that everything works well with existing standards and interoperating with other applications.
      • If you could click the agenda and start typing and then you have a task using defaults - Basically one-click tasks.
      • We should focus on round-tripping the 2445 information and not lose information. We shouldn't implement something that varies from the 2445 spec w.r.t. tasks.
      • It is possible to convert events to tasks but some task specific data will be lost (percent complete etc). You could keep the data by using an X-Property, but you may not be able to unconvert it if you publish the converted task to a provider and bring it back.
      • Not going to solve the convert task to event in 0.5
      • Drive the thread to a conclusion.
      • The idea to convert them is a neat idea but the user must be okay with the resulting and inevitable data loss.
      • Drag the task into the calendar and the task becomes an event, and the information that is easily transferable transfers, other info is lost. It could pop up the "new event" dialog and you can add your information into it.
      • Drag an email into a calendar in Outlook, and Outlook creates an event with the title==subject and the description==note. But the email is left in place. We could do something like that.
      • Pose some of these ideas to the news group, and talk about these various issues with converting them.
      • But, the other discussion about what is an event and what is a task, is essentially settled by stating that tasks and events are as RFC 2445 says.
      • Joey wanted to upgrade the task display to a true task view.
      • the more interesting questions are: how does task work with alarm, how to replace the task in view with something that works well, how to handle a task view and what to do with the left pane task view. We should solve these first.
      • the reason the question of conversion came up was because people wanted a start and end time for tasks, if we just add that we may not have to deal with converting them.
      • Stephan (ssa) will enumerate the ideas about tasks in the newsgroup.
    • Autocompletion
      • Adding title, description, searchbox, attendees to use autocompletion. This is a lower priority 0.5 item
      • Need to understand where we store this information RDF, Db?
      • We need to implement the underlying structure of the data storage
      • Determining places where to use autocompletion
      • writing the autocompletion modules for those items
      • wiring that autocompletion logic into the views.
      • We can use some of the infrastructure that currently exists in the toolkit. For ex. in Firefox you have two autocomplete stores: FormHistory and History. The interfaces for this and how it interacts with XUL is well-defined.
      • If you implement one of these steps, it's not that difficult to implement them all, so it would be pretty simple to get this into 0.5
      • How important is this? Does it really improve usability for now?
      • It's probably a P3 or P4, not a P2.
      • For invitation stuff, it's a big win, other locations, it's probably not that important.
      • Mark this as a 0.7.
      • title, location, search, attendee lists (might do this in 0.5).
    • From external sources
      • Someone edits something on my calendar from another application? Is that what this is meant to be?
      • ICS file on desktop somewhere and dropping it onto your calendar, would automatically import.
      • We can make it so that we "own" ICS files on that system.
      • Working with remote calendars -- how do you recognize that something has changed in the remote calendar? If someone changed the remote file, how do you understand that has changed and cause an update your local calendar on your system in your view.
      • Need an auto-refresh for calendar might address part of this issue.
      • This also begs the question of Conflict Management, how do you handle when two people's changes conflict?
      • Should view these subtasks and decide if any of these should get bumped to a later version?
  • Alarms
    • Email
      • Should the email be a lightning only thing?
      • Probably not a P2.
      • Several settings would be required for it - email accounts, user name, password etc.
      • In WCAP case the email is sent by the server, and not the client. So, it might be that we can push this setting down into a provider.
      • Would involve pushing the item down to the interface for the provider.
      • Perhaps Provider should simply have the ability to override the email setting - default would be email sent by Thunderbird, but provider could change that, WCAP could have the server send it.
      • Push this to 0.7, and prioritize it there pending the amount of work?
      • Fix the VALARM roundtripping as stated in 2445. That is addressed in the "get data out" and "get data in" categories below". It will be fixed in 0.5. There are bugs on this already.
      • DECIDED: Push to 0.7
  • Get data out
    • timezones, x properties, data loss, all of that must go into 0.5
    • printing - that is in review now.
    • need to figure out what we are going to do with printing. We need to be able to print a task list. Should this be in 0.5?
    • publish a specific set of items should be possible
    • clipboard should also be added as another way to get data out (copy /paste)
    • sync - external files/other calendars -- essentially offline support
      • sharing an ICS file over the network
      • Sync with external files means resolving conflicts.
      • Storing on the network. We should do this and do this earlier than 1.0.
      • Offline usage of remote calendars, and that way you can take a calendar offline. Once you connect, your changes will be sync'd.
      • Sync with devices is a different item -- it's about six lines down.
      • Both sync over network and sync with devices will reuse a lot of code
      • Need Conflict Resolution
      • Should be fleshed out better on the list to indicate that it is sharing an ICS file over the network, and that it will require conflict resolution.
  • Get data in
    • Subscribe means "no data loss" and "if something's failed, we should alert the user, no silent bugs"
    • Public Holidays are different.
      • Interface for finding holiday files and holidays should be shown as time off.
      • If we need FreeBusy for 0.5 then we should have holiday support
    • Sync from device should be bumped.
      • Full sync with phone, pocket PC and iPOD isn't going to happen in this timeframe
    • Importing From existing calendar applications
      • Mostly complete, but it is a moving target as other applications change
      • Need to keep working with this
  • Email integration
    • Better integration of lightning into thunderbird.
      • How do I look at calendar while seeing email in Thunderbird -- that's apart of this.
      • Addressbook integration with calendar - for example birthdays from addressbook should show up into the calendar
      • Addressbook integration is addressed about 9 lines down
      • This is more about using Thunderbird's undo/redo, using Thunderbird's copy/paste, printing, drag/drop, etc.
      • Leave this as 0.5 and see what we can get. If we can get copy/paste in that would be a big win.
  • Calendar Interoperation
    • Being able to invite other people via iTIP and iMP
      • allow invite and decline
      • do not have to support reschedule etc at this time.
    • Sharing
      • A few people sitting in a room that want to share my calendar with one click
      • Sunbird or Lightning would be serving your calendar to people on your network
      • This would be a good feature to have
      • Is it a 0.5?
      • Serverless sharing might be a better way to describe this item
      • Pushed to another release - not 0.5
    • Freebusy
      • Publishing a composite of freebusy information is not critical for 0.5 and so it should be bumped.
    • Addressbook integration
      • autocomplete of addresses
      • automatically importing birthday dates of addressbook people
  • Sync with device should go to 0.7. Offline support is much more important at this point
  • Bumping holidays with webservice integration is probably okay since we deicded to bump freebusy and we should bump the other holidays as well
  • Backup
    • Since it is a low priority we can leave it in.
    • backs up storage Db to an ICS file - would not be difficult
    • making a backup implies you want to do something with it.
    • events stored on servers do not have to be backed up
    • need to backup the storage calendar and the autocomplete information, perhaps preference settings?

What to do with this list

  • Matt will take this list that has all the 0.5 stuff and remaining 0.3 items and we will use that to drive the release. It will be much like what joey did for 0.3.
  • We'll have bugs associated with that as well
  • It might be good to have a high level list of things that are post of 0.5, in order to describe the project a little better.
  • There is work similar to that is going on for Firefox 3 and so Matt will look at that and see if we can do something similiar

Current stats - who's doing what

  • Daniel is working on performance stuff
  • Joey is working on the migrator
  • Matt and Clint are working on the iTIP next version
  • mvl and Matt are working on bugs
  • Matt will continue working on getting this list together
Retrieved from "https://wiki.mozilla.org/index.php?title=Calendar:Status_Meetings:2006-10-25&oldid=54317"