<< previous meeting | index | next meeting >>

Meeting Details

• Thursday April 27, 17:00 UTC, in #calendar-mtg
• IRC log

In Attendance

bienvenu,chris-j,dmose,bienvenu,lilmatt,jminta,mickey,mschroeder,mvl,ssa,ssitter,ulf

Agenda

1. Sunbird 0.3a2 status
2. Future weekly meetings: phone or IRC?
3. Feature Planning
   1. Find an agreement on a time line
   2. Organization of feature discussions
   3. How do we come to a conclusion and stick to it (to avoid endless discussions)
   4. How to deal with proposals and mockups
   5. Clarify who works on which feature proposal to avoid duplicate work (eg calendar subscriptions)
4. Future agenda items

Sunbird 0.3a2 status

• small number of bugs left
  • Try to land all patches including 0.3a2 branding today
  • Hopefully Friday's nightly builds can be used as RC2
  • If we're lucky, use those as 0.3a2 final bits next week
    • Tag retroactively by date
    • Unslush the tree!

Future meetings

• Consensus: let's try voice
• Action item (dmose): figure out moco/mofo POTS cost options, possible other POTS
• Action item (ssa): figure out online voice chat options, possible other POTS
• Post-meeting agreement: keep next week's meeting on IRC so that we have more than a few days to get the details sorted out

Feature planning

• Timeline for 1.0
  • Action item (dmose): drive raison d'etre newsgroup discussion to rough consensus, target: next Thursday's meeting
  • Action item (dmose): drive product definition discussion to very rough consensus, target: next Thursday's meeting
  • Tentative target for rough design methodology consensus: 2006-05-11 meeting
  • Tentative target for 1.0: Spring 2007
• Organization of feature discussions
  • dmose speculated that this would largely flow from overall design methodology
  • consensus was that we'd come back to this at next week's meeting after the design methodology discussion has progressed further
• Reaching conclusions and avoiding infinite discussion
  • The old suite didn't do a good job of avoiding this problem
  • Firefox and Thunderbird have dealt with this by
    • Focusing high-level design and ownership to a very small number of people
    • Trying for simple and clean UI
      • Consensus that "simple/clean" is more testable than "better".
      • Enterprise features can't necessarily tolerate more complexity than any other set of users
      • Simplicity has to live in the core app, as pushing it to an extension forces unsophisticated users to deal with extensions
      • No overall conclusion here; mostly brainstorming
  • Consensus: group decisions are bad for design coherence: small group of UI / design owners is the right way to go
  • Action Item (everyone): consider possible ways to select this group for next week's meeting
• Proposals and mockups: out of time, pushed until next week
• Avoiding feature work collisions: if you want to start working on an unclaimed feature, add your name to the wiki page for that feature and post to the newsgroup. For claimed features, talk to the people who have already claimed them.

Future Agenda Items

• Anyone can Add to the Proposed Agenda section of the meeting page during the week beforehand
• Just before the meeting, dmose will attempt to sort and prioritize
• At the beginning of the meeting, deal with any sorting/prioritization issues