Meeting notes from the 0.3 release debrief

Attending: most everyone at osaf, including ted remotely Date: 24 Feb 2004

Topics discussed

• Release Expectations and Goals
• Bug council and end of release code reviews
• Design reviews/code reviews
• Milestones and demos (2 week clock tick)
• Testing
• Platforms
• Tools
• Documentation
• Office hours
• Marketing communications
• Process
• Bugzilla

More Of

• tracking progress (in a quantified way) through the release process
• forum for intergroup/interoffice/intraproject communications
• making release expectations clear, write them down
• set goals earlier in the release, make goals clear
• branch during the release process to not slow development
• stabilize repository (and infrastructure layers in general) early in the release
• setting priorities in an organized way from the beginning of the cycle, not just at the end
• make expectation changes clear when it happens, write it down and publish it
• planning for the release early on
• integration of community working group into the process
• strategic decisions about efforts put towards the community
• short/effective bug council meetings
• clearly define blocking bugs criteria, don't spend time at bug council meeting defining it
• clarity about attendees for bug council meeting
• wiki page for bug council with important links, attendees, policies, ...
• look at bug list before the bug council meeting, link available for the table that we use
• marcomm plan for each release ahead of time
• standard formats for documentation (to reduce time worrying about format, better info management)
• get more than one person to review design (either before coding, or early on enough to refactor according to feedback
• write up design and get feedback -- from the dev list and other teams, etc
• demos of some sort from the design team (informal, short)
• upfront planning of documenation for release
• reqular testing, during office hours, plan during the release
• better cross platform development environment for developers
• public display of the build state
• health of project dashboard
• lxr tool
• investment in making tools better (bugzilla, wiki, etc)
• more useful list of bugzilla components
• feedback on existing docs, to know what's useful
• one person to own docs, notice holes, consistent style
• better bugzilla components

Less Of

• changing expectations at the very end of the release (gold plating the end of the release)
• code building up in a private environment (branch instead)
• sprinting at the end (more consistent marathon pace throughout)
• meaninless milestones
• office hours as a burden (think about how to make them work better, perhaps less often)
• orphaned projects/snakes (manage snakes as projects, set expectations and priorities, track progress)
• hard to find info on wiki, bugzilla

Same As

• bug council triaging bugs worked pretty well, useful
• raise expectations when appropriate, to have a target to shoot for
• firewalling at times to not disrupt focus
• code reviews during freezes
• milestones as a target to shoot for
• demos at milestones (especially brief demos)
• prebuilding libraries for the different platforms
• unit tests, unit test framework
• tinderbox
• expectation that builds "run green"
• commits list and web notify
• debriefing meeting
• midcourse correction on release goals

Open Questions

• Which sorts of things benefit from review and consensus building? When stakeholders are involved? Interfaces between projects?
• Should we stick with 2 week milestones or extend them?
• Should we have a testing office hours, every 5th office hour?
• How can we make cross platform development easier? Standard environments? Make file transfer easier? Show people how to use diffs/patches? Support from source control?
• What kind of documentation should we be writing? Who are the stakeholders at this point? Focused on people who want to contribute? Interteam communication?
• How useful are the office hours to the community? Do office hours provide a good return on investment vs other sorts of efforts?
• How could we get more useful conversations at office hours? Is it better to have an open discussion to do work amongst ourselves (inviting outside participants as well) vs show and tell?
• Should bugzilla's platform field default to all?
• Do we want to set midterm milestones? test at the milestone? have a debriefing at that time?
• Experiment with other mediums like video for communicating with "outside"? (IRC can be low bandwidth)
• How can we better track progress? Measure programmer productivity?
• Documents in release (html) vs wiki?
• Should Chandler pull the various subprojects from stable branches instead of everything being on CVS HEAD? Seems to work well for mature subcomponents (for example, Mozilla pulls NSS from a stable branch).

• -- KatieCappsParlante - 25 Feb 2004
• -- HeikkiToivonen - 25 Feb 2004

Comments