Management Committee Meeting

1. Release Numbering - Numbering through the 0.3 dot release will stay the same. At 0.4, we will make a change to the way we number milestones (see last week's notes for the rationale). Heikki will post relevant details on a wiki page.

2. Development and Inter-working group issues

• a) Apps group: do the bottoms-up schedule. Big dependency is a UI topic, and there is a meeting on this for Tuesday.
• b) Repository group: Heikki to figure out right after this meeting. No big dependencies.
• c) Design group: making sure hand-off to apps team is good; review ZaoBao^? UI design; recalibrate approach for design process; "catepiller" UI issue; review Brian's early doc about "notes" design.
• d) Community group: Get consensus on our general role.

Coordinators here should check in with Mitch after getting an idea of the bottoms-up schedule.

3. How to make sure we're doing the right thing to get to 0.3? Mitch would like to see Bugzilla as accurate as possible through 0.3, not just the next milestone. The apps group will be working hard on its part of this task.

4. Heikki demo of how he uses Bugzilla. We thought since Heikki has used this tool as a manager before, he might have some tips. We looked at a few of the Reports that Bugzilla generates by default. Action plan: Katie will play with Bugzilla reports to see how useful they are. Chao maybe as well. Heikki will come up with a plan of action. Mitchell volunteered Asa to provide more demos of power use.

5. Updating the Project Hierarchy -- code related changes submitted. Ducky will talk with Pieter and Morgen to get implemented soon. Mitchell will get changes to community piece in the next day or so. Changes being made to Status Manager and the wiki. Will test it out for a couple of weeks before changing Bugzilla.

6. Wiki Reorg

• a) Will use the same Project Hierarchy
• b) Standarding dates and dot releases
• c) Apps group then needs to focus on its content to develop an organized place to track info from the apps group. Needs to reflect the work and the design docs and so on, and be logical so that we can find things. Katie will come up with a plan for the apps group. Then the other groups should do the same things.

7. Reflecting high level decisions

• a) We made a decision about security. How should we communicate this? Decided should be an email message, and should be reflected on a project page. One or the other of these messages or both should include the rationale for the decision.

• b) Before too long we should make some high level decisions about sharing: how shall we communicate this? Should be the same way. Should be a project page for this as well.

8. Expectations for availability when people aren't in the office. Each person should set an expectation of his or her standard pattern so we can work closely together when we're remote. In general should be available over IRC. If it's a problem to have IRC running, then log into the server but don't join a channel. That way people can send a private query.

9. Investigate Apple and MS developer programs. We want to do this, but later.

10. StarterProjects page. Brian is moving to a Product Management role working with Chao, so won't be the contact for StarterProjects projects, which should remain in the engineering world. So each working group should discuss. See if there are projects that can be identified discretely enough to become StarterProjects projects and for which there is a good contact.

-- MitchellBaker - 08 Dec 2003