Topic: Whether to do weekly bug-bashes: entire day devoted first to fixing bugs

Consensus that it would be too much (agree with issues raised on dev list) particularly in conjunction with the test period when we reach a major milestone. Also the apps team is working exclusively on bugs anyway. So we won't schedule any bug bashes now; instead we'll wait until Aparna flags that there are new unscheduled 0.6 bugs that we could focus on in a bug bash.

Topic: Build and QA roles

Couldn't remember what issue was under this topic... Aparna is responsible by default for all QA, Mike for all Build stuff (and Heikki acts as manager and backup, not as first-owner)

Topic: Status reporting

Let's try to generate a summary consolidated status report

Discussion of whether to do this automated or manually (and various levels of possible automation).

How to break it up: by team; by Progress/Plans/Problem division

Topic: Personal task management

Some of us still use status.osafoundation.org to manage our goals (and managing tasks to reach goals). Should we look into alternatives?

Lisa looked for PC applications to do task management and couldn't find something free that seemed appropriate. There are, however, free WebUI^? task management tools. These might be worth installing if other people were interested in using as well.

There are also Web services that do this in a centrally hosted place like BaseCamp^?...

Conclusion was that this isn't an organizational need. For people who want to do task management of their own tasks, they need to find their own tool, if it's Wiki or outliner or Emacs or whatever, until Chandler does task management.

Topic: Linux platforms to support in 0.6

We'd like to get volunteers but currently there are dependencies that make it difficult for volunteers to do packaging. So we should make it a 0.6 goal to reduce those dependencies, insofar as it doesn't put Bear's other goals at risk.

We plan to move away from Fedore Core 2 at some point, but when? Do we have time in our 0.6 release to support more than one Linux version? wxPython currently causes some problems for supporting multiple Linux platforms.

Conclusion: We should wait until our build and package issues are simpler before extending our support platforms.

(Note that Phillip is providing valuable ideas for reducing dependencies, which he's discussed on IRC with Andi and plans to discuss with Bear)

To make this happen we should see when the wxWidgets people can deal with some of their issues... are there people in the wxWidgets community that can help with this?

Also we should enter each task into bugzilla and be watchful for tasks that are appropriate for the 'helpus' flag.

Heikki, Philippe and Katie and possible Robin will follow up and discuss

Topic: Migration, backup and restore

The repository format doesn't actually change that much. What happens when schema changes? What do we do when schema changes can't be handled automatically? We need a little code to do this migration automatically. We probably need a design for this before we go into 0.7.

This problem does bring in parcel development issues -- we need ways for parcels to upgrade their own schema/data.

Our stake-in-the-ground plan for 0.6 is that we rely on manual Import and Export of calendar data to iCalendar format in order to allow people to upgrade their code when schema changes occur. Note the consequences are:

• People must know when a schema change build is happening and manually export, then upgrade, then import.
• Only calendar data will be preserved. Notes and email may be lost.

Lisa will follow up to make sure Mitch is OK with this product plan.

Topic: Code reviews

Lisa took the temperature of the services WG and they want to continue doing code reviews as scheduled in the plans (as was done in 0.5) and during the end-game when all checkins are tied to bugs which have patches and reviewers.

General discussion:

• The bigger the system, the more precautions are needed.
• Katie noted that a Code Review was a different thing than a review-before-checkin. The latter is likely to be more cursory.
• No checkin is guaranteed to be safe. The absolutist position is clearly to review any change.
• The nature of 0.6 work in Apps (mostly bug fixing) affects how they might want to do code reviews in the short term.
• we all agree code reviews are a good thing to do.

Philippe isn't in this meeting so we'll pursue this topic again next week and continue surveying the teams.

Topic: Debrief next steps

Ran out of time -- we'll pursue that followup again Thurs at 4pm.

Topic: Where is 0.6 planning at?

• ZeroPointSixPlanning
• ZeroPointSixEngineering

Different levels of planning are at different levels of completeness. The 1-2 month granularity goals for 0.6 are understood for now (until more detailed plans or new information causes changes). The work of the Services team has been broken down into 1-2 week tasks for the first 8 weeks of implementation, and the Services engineers are working on more detailed estimates. The Apps team work is now described in a bottom up plan involving 8 weeks of implementation time working on the "List One" features of the ZeroPointSixPlanning page. Functional specs are in progress, we need a master spec list which Sheila will do. Some specs are needed even for the "List one" work, as well as somewhat forward-looking specs for post-list-one work.

We need to link the two pages above to each other and explain the relationship -- if not merge them. Originally the two pages were one but the engineering stuff was split out because the planning page was so big and it was work to tease out actual planned engineering deliverables from all the plans.

On a side note, do we have a better handle on vacations and how they affect the schedule in 0.6? Last time, right around our code freeze, we had developers on vacation. General discussion that we need to let people take vacations when they need to and plan around that, rather than try to plan vacations around schedules (which so often backfires).

Topic: heads up on Persona Definition

Lisa described the process, plan and idea of this work. General discussion: personas are just one technique for good user-centered design. Aparna thought this would be useful in testing.

Topic: World Usability Day

In October or November... something for community team to plan for We should participate in this day in some way.