Tomboy Dev Meeting for Planning 0.10.0 release

1. Action Items Determined In Meeting (rough)

• Compile list of bugs to be handled immediately in trunk and gnome-2-20 branch (for 0.8.x releases).

• Test 0.6.x -> 0.8.x upgrade scenarios, especially focusing on Mono.Addins.

• Re-enable tagging UI in trunk. (Boyd)
• Sum up proposed note renaming solutions in bug #350990. (Sandy)
• Revert change applied for bug #449478. (Sandy)
• Create wiki page of Tomboy UI "gotchas".
• Investigate if users still have performance problems with large note sets. Document problems and write test plan.

2. Original Meeting Plan

• Tomboy/DevMeetingZeroPointTen/Plan

3. IRC Log

• Tomboy/DevMeetingZeroPointTen/Log

4. Tomboy 0.8 Postmortem

4.1. Successes

• Gained an awesome and passionate additional maintainer. Welcome aboard Sandy!
• Got note synchronization out to our users
• New contributors, better DBus interface, etc

4.2. Drawbacks

• Started the note synchronization a bit late in the cycle
• Unable to focus on general bug fixing because limited time had to be devoted to working on unfinished feature (sync)
• 184 open Tomboy bugs, vs ~100 open when 0.6.0 was released
• Will require some 0.8.x releases because of this

4.3. Improvements

What can we do better this time?

• Begin large features early
• Don't branch for feature development
• Pay more attention to our progress relative to GNOME release schedule
• Bug "pow-wow" around GNOME feature freeze to assess where we are

5. Development Plan for Tomboy 0.10 (GNOME 2.22)

• Compile list of 0.8.x bugs, knock them out as quickly as possible
  • Sync stuff

  • Mono.Addins stuff (0.6.x -> 0.8.x upgrade scenarios, especially)

  • Selecting title instead of content in new notes (My bad! --SandyArmstrong)

• Tasks
  • In for 0.10.0
  • We need to be less hung up on integrating with EDS. Focus first on making a great task/TODO experience that makes sense in Tomboy. We do not necessarily need to mirror the "heavy weight" task features offered by EDS.
    • Relying on Conduit or an optional EDS sync add-in were both discussed as means to put Tomboy tasks in EDS.
    • There was an idea that typing an EDS task name in Tomboy would create a link to the task in Evolution
    • Users expressed desire for EDS integration to address PDA sync, GNOME clock/calendar widget integration, etc
  • Need to be able to easily create a single standalone task
  • Need to support users who make task lists inside a single note
  • Discussed "heavy" vs "light" UI approaches. We will most likely pursue a lighter UI:

    • Heavy: Full EDS-style tasks application within Tomboy, where tasks and notes are well integrated

    • Light: Type "[]", rest of line becomes Task with checkbox in front. Click on line to create a new note associated with that task (maybe titled "TODO: Name of task"). Task notes are just like regular notes, except they have completion status. Task notes have different icon in notes menu.

• Tagging
  • Need to re-enable the existing UI
  • Need to follow-up on Boyd's work to awesome-ize the tagging elements of the Search UI. This work may be entirely dependent on contributions from outside developers.
  • Discussed utilizing tags to provide "Notebooks" in Tomboy. This could include switching "modes" based on tags. For example, in "work mode" new notes would automatically be tagged "work". Nobody currently slated to work on this.
  • What other features could we build based on tagging?
    • Bulk export operations from the search window based on tags
    • Discussed restricting sync based on note tags, but most were convinced that there would be too many "gotchas"
• Synchronization
  • Will revamp sync UI to be an automatic/background process. Ideas discussed:
    • Notification bubbles to alert user of conflicts, etc
    • Tomboy applet icon changes to reflect sync status
    • If viewing a note and sync updates it, display GEdit-style "Reload?" bar
  • Near-Zero Configuration
    • Strong desire to have sync backend that doesn't require the user to have a server. Online Desktop and GStorage were discussed. This work will ultimately depend on available developer resources. Lower priority than UI work.
• Revamp note renaming behavior
  • Lots of discussion here...will update bug #350990 with the various proposals
• Scalability
  • Need to determine if there are still scalability issues, what they are, how they can be tested, etc, before we can fix them

  • Discussed moving many NoteAddins to the hypothetical add-in type NoteWindowAddin that is only instantiated for open notes.

6. Other Items

• We are keeping our current version number convention. The stable release delivered at the end of this cycle will be 0.10.0.

• We will adopt the Mono Coding Guidelines entirely. We might need somebody to clean up the existing code.

7. Schedule Preview

The complete GNOME 2.22 schedule can be found here: TwoPointTwentyone

Some of the important dates are:

• Oct 29, 2007: GNOME 2.21.1 Tarballs Due (First unstable release)

• Dec 17, 2007: GNOME 2.21.4 Tarballs Due (String Change Announcement Period Begins)

• Jan 07, 2008: API/ABI Freeze

• Jan 14, 2008: Feature Freeze

• Jan 28, 2008: UI Freeze

• Feb 11, 2008: String Freeze

• Mar 03, 2008: Hard Code Freeze