0.6 Debrief

Topics

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

More Of

• non code deliverable planning (wiki, website, service, etc.)
• close on tenets earlier
• planning efficiency
• shorter releases
• preplanning
• decoupling development and planning
• planning around architecture goals
• coordination between cosmo, chandler, scooby, hosting service
• public code review comments
• bugzilla for task tracking
• user testing of design alternatives
• public design discussions
• clear discrete questions on design list, with timeline for answering
• atomic design discussions with specific goals
• more summaries of design list discussions
• paper trail of work (more descriptive checkin comments, more discussion in bugzilla, dev list)
• design discussion about code before it gets written
• higher quality milestones
• checkpoint summaries in the last few months
• access to checkpoint summary from download
• automated testing (functional tests, unit testing, tinderbox observing)
• automated testing between components (chandler, cosmo)
• more perf load testing for chandler
• more perf testing of whole system
• more linux dogfooding
• more irc bug bashes
• test interoperability sooner
• talkback feature
• bugfixing as we go (instead of saving until the end)
• developer in loop for bug triage
• punt bugs sooner
• more clarity on bug council intention w/bug priority (p3/p4)
• more error logging for tinderbox
• tinderbox tracking automated tests, functional tests
• separate commits list for developer documentation
• schedule time for documentation writing
• css stylesheet for the documents
• more landing page-like wiki/website communication
• summaries of conversations
• complete notes in meetings
• demos at staff meetings
• staff meetings even when mitch is unavailable
• clear expectations about dependencies (chandler/cosmo)
• involve everyone in decisions about governance
• integrated help files

Less Of

• irc decisions (secret decisions)
• general design discussion in bugzilla
• manual testing
• bundling fixes into a single checkin
• fewer forks from upstream packages
• documentation and release overlap
• cross posting
• cc'ing people already on the list
• irc office hours for broadcasting information
• decisions made in hallway conversations (irc, skype, meetings)
• staticy polycom conversations in gotham

Same As

• tenets
• functional specs
• screenshots - look like what would be implemented
• specs in svn
• linking bugs, tasks to specs
• bugzilla for task tracking (apps team)
• philippe's bug and task graphs
• checkin comments
• checkpoint/milestone system
• irc sharing testing
• bug prioritization
• bug council
• fixing/reporting/triage cycle
• chandler landing page
• management style - engaged but not micromanaging
• multiple channels for feedback

Open Questions

• should we have a changelog? tag checkin comments? require someone to summarize?
• should we create a mock server for testing?
• chandler/cosmo field testing (beta) -- at universities?
• should we podcast meetings?

Feel free to add free form comments here!

-- ReidEllis - 11 Jan 2006
I made a recording of the meeting (low quality - recorded over the phone). I think recording meetings and making them available via podcast would:
* require little to no work, and
* serve as a valuable reference resource
As someone who joins most meetings over the phone, I would appreciate being able to refer to a high-quality (compared with phone) recording.