All Hands Meeting October 2, 2003

A. New Employees. We tried to start a new tradition where each new employee states 3 "facts" about themselves, one of which is not true. Then we took pity on our current new employees and decided that we'd do this next week.

• 1. Stuart Parameter -- will start working on agents with Andy and Andrew

• 2. Mimi Yin -- new UI designer.

B. An expresso machine should be arriving today. Takes about 90 minutes to install -- we take our caffeine seriously here. Pieter will supervise, as he does with all things related to expresso.

C. Phones will be done sometime Saturday -- don't try to send us important phone messages then.

D. Status Reports. OSAF employees now do weekly Status Reports, which have mostly information which could be public and some information which is private. We'd like to find a way to break these apart so that all the info that could be public is public, without adding too much to the time necessary to create Status Reports. Pieter showed suggestions of how the types of info could be recorded in separate places without too much overhead for the staff.

We talked a bit about how to get useful info into status reports. Before long we'll need to start aggregating info, it won't be possible to read each person's Status Reports, we'll need some aggregation method.

We also talked a bit about tools we might use to create good status reports more easily. We're not sure about this yet, since we think Chandler is probably the tool we need

We didn't make a decision about how to do this yet; we need to look at tools and methods for doing this. Meanwhile, Mitch and Mitchell will spend some time in the next couple of months to canvass the community and see what we're doing that are helpful and not; and whether there are other useful things we need to do. Research into community building to complement transparency.

Pieter will continue to do the bi-weekly Status Updates.

E. 0.2 post-mortem.

We didn't want 0.2 to be a big event, since it was a time-based release. This seems to be what happened. We identified a set of topics realting to the 0.2 release and spend some time talking about them.

• 1. Dot Releases" clock based or features based? Some believe that we shouldn't have called it an 0.2 release. Basing milestone releases on the calendar is good. But basing dot releases on the calendar is another question. It didn't feel like we hit the sweet spot, where loose ends were tied up. Also it didn't serve a giant forcing function for some of the developers, although it did for others. Certainly is a forcing function for documentation, but other docs were blocked because the development wasn't done.

Didn't take a lot of development time. We did stop and do some bug-fixing, which is good.

Seems like letting a dot release slide a week or two is acceptable. If it's more than that, then there is a planning or execution failure.

Proposal: (a) have some goals for 0.3 -- the pile of stuff we want to have included. Dot releases should have "units of meaningful accomplishment." The things that barely miss we'll slip the release a bit. But we won't slip very much, because this forces us to examine why we missed. Release will be clock-ish, but not completely. One might want to revise the forecast in the middle of the period at least once. (b) set up a place on the public wiki -- plan, evaluate what we did, look at the delta between plan and accomplishment, see what we learned. Let's see if there is a pattern to our errors, like chronic over-optimism.

• 2. Productivity -- how are we doing? Also a discussion that 0.2 included only a portion of all the things we had initially hoped to include. So we need to estimate better, and plan better. Discussed the need to have a better shared understanding of the interaction between Chandler building blocks to improve productivity.

• 3. Fit, finish and Quality -- Andy H's topic of last week -- when do we start focusing on fit, finish and quality? 0.3 will be more of a completed package than 0.2 was. Brian suggests that once we commit to fit and finish for something, we should keep it polished going forward. This idea was well received. As to getting to a release that end usersmight use: Chao to work on a plan for what minimal features and infrastructure needed for very hardy types (theoretically, like those at OSAF) to start using the release for something, probably calendar functionality.

• 4. Tracking progress against schedule -- do we have the right system? How do we improve ability to predict in the 2 or 3 month timeframe?

We'll continue the two week interim releases. Try to figure out how people estimate their tasks well -- can everyone work the same way?

• 5. Build issues --"Make" still doesn't work reliably on all platforms.

• 6. Release process -- locking down the tree, and meeting. This was smooth this time. Might be more contenious when we have feature releases.

-- MitchellBaker - 03 Oct 2003