0.5 post-mortem March 31, 2005

Agenda or topic list

To discuss how we did with 0.5 in terms of "More of", "Less of", " Same as", addressing the following areas.

• Planning
• Design
• Development processes
• Testing
• Bug fixing, reporting and triage
• Build/Release
• Documentation
• Community
• General

More Of

• clear realistic goals
• dependency planning
  • implement core pieces early
• design upfront of architectural issues
• communication across groups
• keep wiki specs updated with current thinking
• transparency into dev planning process
• track development tasks in scheduling, track dependencies
• define api/contract between modules (reduce schedule dependencies)
• bear to know when libraries are going to be needed by developers, added to build.
• 1:1 paired design (mimi and developer)
• deliverable from 1:1 meetings - wireframe or screenshots of specifics
• visual representation of release goals
• more regression tests (reviewers enforce)
• unit tests
• automated integration tests
• require smoke tests before checkin at the end of the cycle
• UI level unit tests
• better communication about expectations at the end of the release
• structured support for design/development working together (regularly scheduled meetings)
• features (visual, end user) showing up earlier in the release
• more code reviews
• more review before checkin
• fix bugs earlier in the release (all along, bug bashes)
• design an review of public api.
• high level perf tests
• better environments on all platforms
• better sharing of information about development environments
• automated sharing testing
• backing out changes that break the build
• more dogfood
• everyone owning whole product
• everyone has shared understanding of architecture
• more tech design and review
• encapsulation functional description
• everyone has shared understanding of functional design
• release notes on milestone builds
• documentation for end users and developers
• clearly defining the target audience for a document (devs, end users, both)

Less Of

• discussions about future issues
  • schedule dependencies
• large changes at the end of the release
• breaking existing functionality (especially at the end of the release)
• committing late in the day at the end of the release or milestone
• Bear and Aparna up late at night because of release process
• cvs (more subversion)

Same As

• developers included in design process
  • involved in design meetings
• ui specs
• cross boundary in org to help fix bugs
• some developers using linux as primary platform
• respect the watchdog
• ask specific questions to community
• bug fests (irc) are productive
• irc office hours every other week
• investment in dev platform - in parallel with the feature development
• Mimi, Sheila and Aparna meeting with the apps team regularly

Questions

• Bug bashes with each milestone?
• Review before checkin?
• Doctesting?
• Documentation during release?
• Are clockwork milestones working?
• Feature driven milestones?
• Quality driven milestones?
• Automated UI testing
  • silk test
  • CPIA event
• How to make xplatform testing easier, more common?
• How to improve the development environment on the Mac?
• How do we coordinate server project?
  • know when to make it part of automated build process.
• Set time requirements for build?
• Known major bugs crashing in test menu block release?
• How does our process change as we get closer to dogfood?
• How do I know what my change affects?
• Better way to present what we are doing to outside world? Dev platform? End user?
• Channel volunteers into end user docs?
• How can we support audiences interested in Chandler? Potential end users, Mellon etc?
• Can we have demo materials to explain Chandler? Macromedia website, Jon Udell.
• How do we expose marketing goals?
• Should we have a group blog? (higher exposure, less chatter)
• Wiki vs blogging?

Debrief Follow-up Notes

• DebriefQuestions20050407

Past Notes

• ZeroPointFourDebrief20041101
• ZeroPointThreeDebrief20040224