Summary and Agenda

These are the notes from a 0.5 debrief follow-up where we met to discuss open questions from the official 0.5 debrief meeting. We only were able to get through a handful of issues and will continue during the engineering meeting on Tuesday April 12th 2005.

Attendees

Ted (phone), Sheila, Katie, Lisa, Aparna and Heikki

Notes and Decisions

1. Observations.

• Ted commented that after reviewing the debrief notes he felt that the "More Of" items fell into 2 categories: Testing related issues and communication issues/shared understanding/transparency.

2. Feature driven milestones?

• Yes we should have feature driven milestones for 0.6.
• We are proposing longer official feature driven milestones more like integration points.
  • Integration/milestone point A (4 weeks) -> clock starts on the 25th which will give us some time to work on design and specs
• Need to figure out the exact criteria once some of the dev estimates are available.
  • list #1 minus some big stuff
  • plus some services goals.
  • one week of testing after integration point.
  • candidate for first integration point - May 23rd.

Decisions Made: Have a four week integration point scheduled for May 23rd with feature driven goals. Need to finalize criteria for goals based on specs and dev estimates. The clock will start on April 25th to allow us to finish specs/planning and to come up with list of more concrete integration point deliverables.

3. Quality driven milestones?

• How do we define this for a milestone?
• This is subjective.
• Currently we have some level of smoke tests preformed and if they don't pass then delay the milestone.
• Did we do this in 0.5? Somewhat but maybe we need to raise the bar on this for 0.6.
• What does this mean -> more comprehensive smoke tests.

Decisions Made: We will raise the bar on quality for the milestones (integration points) and supplement this with checkpoint builds in between (see below).

4. Bug bashes with each milestone?

• how frequently, weekly vs every 2 weeks?
• how focussed?
• every other wed is bug bash day or should we have this each week?

Decisions Made: We will have bug bash days after a feature and quality milestone is reached. Aparna owns this and will pick dates and communicate expectations.

5. Are clockwork milestones working?

• We should consider checkpoint builds to compliment longer official milestones.
• Date: Proposal -> change the build day to Monday early in the day.
• Frequency: Proposal -> move to weekly build (checkpoint), semi certified builds

Decisions Made: Heikki will communicate this proposal to the dev team.

6. Review code before checkin?

• probably need a discussion with developers to get buy-in.
• talk to team leads - get buyin.

Decisions Made: Still an open issue. Philippe plans to propose something and circulate it.

---

Notes continued 20050526 with some edits above

---

7. Doctesting

• Do doctests get run by Tinderbox?
• Do we need to schedule a tutorial or something?
• What kind of modules benefit from doctesting? Most APIs could benefit from this -- more so even than unit testing, doc testing forces the writer to think about how to explain to somebody how to use this API.

Decisions Made: Lisa to ask PJE to schedule a doctesting tutorial for next visit

8. Documentation during release

• Epydoc: we kind of expect this to be done during coding, not at the end of the release
  • Code reviews are good for reminding this
• Is there an issue of code needing to have epydoc generation "turned on" per module? Is there stuff that's epydoc'ed but not turned on?
• How can we put the epydoc in people's faces so it becomes part of the landscape?
• Aparna suggested possible intern project

Decisions made: Heikki to enter bugs suggesting scans of epydoc to see where we have coverage and what's plugged in

9. Automated GUI testing

• Progress made since 0.5 debrief -- Donn's work

no decisions needed

10. Easier cross-platform testing for developers

• Already have an IT project planned to make a remote machine available for testing
• Other steps taken

no decisions needed

11. Better Mac dev environment

• Options: WingIDE^?
• Is full debugging possible?

Decisions made: Philippe will follow up to see if this is in part a wxWidgets problem

12. How to coordinate server project

• Brian and Bear are making server part of automated builds right now
• The rest of the coordination will be addressed in ops meetings, not here

13. Quality requirements for "test" menu

• Katie to follow up on not releasing the test menu live

14. Process changes approaching dogfood

• More stability, naturally
• Longer bug fix period allocated?
• How to get more focus on testing as we approach a usable release? Do we expect developers to shift some cycles to testing?
• How do we get people actually using software as "dogfood?"
• Could ensure more stability by enforcing checkins pass a quality bar -- later, not now, but closer to dogfood

Decisions made: Aparna to file more 'nit' bugs if they affect usability; Next IRC "test" session (Jun 8) we should set expectations for active participation from developers; Schedule evening or day-long "bugathons" where all OSAFers participate; Have a "tickler" for this theme and revisit in two months or so

15. How do I know what my change affects

• Is architecture fuzziness the source of unnecessary pain here?

Decisions made: Katie to continue refining and documenting and communicating the architecture.

16. Technical communication

(from questions: presenting Chandler to outside world (Dev platform, end user); demos; marketing)

• Making virtuality more clear: already planning a presentation on this internally, should be followed by public document explaining same
• Katie, Pieter and Ted did a pass on the Web and Wiki structure
• Some Wiki changes are gated on not having an IT/Wiki resource
• Lisa thinking about "Tourist Guide" to Chandler
• Mimi writing about virtuality needs to be factored in
• Lisa discussed with Mitch and Peter St. Andre how one approaches these overarching tech communication problems with an open source project
• Ideas for demo site (like macromedia): yes but not an immediate opportunity
• Web site needs to be scrubbed of obsolete plans

Decisions made: Lisa to follow up with new IT Lead on Wiki admin problems; Heikki to think about Wiki layout

17. Blogging

• Group blog? Let's bring up at next ops meeting
• Should group blog be used for OSAF site home page?

Decisions made: Follow up with Mitch and Pieter (Lisa to put on agenda)

---

More notes continued on Jun 21

---

18. Dev and release planning "more of" items

• More transparency into dev planning
• More dependency tracking
• Better communication about expectations at the end of release

Discussion:

• We believe we're doing a better job of transparency and making inroads into remembering to communicate this kind of thing. Maybe we'll get a different read at the end of 0.6. E.g. the whole spec process and their status page and "final review" calls is all much more transparent.
• Ted suggests seeing more spec feedback on dev mailing list -- e.g. transcriptions of skype calls? But to a limit naturally...
• Some people don't do everything publically by preference... we don't want to discourage spec-writers who circulate their specs privately first

Decisions made:

• Katie will take ownership of better task tracking to see if we can do a better job of seeing dependencies before they bite us the wrong way
• Lisa is going to post what we've been discussing about Sheila, Aparna, and others' roles during release
• Continue doing what we're doing now with spec "final review"

19. Testing "more of" items

• More regression tests
• More unit tests (we sorta already covered this in doctesting)
• More automated sharing testing
• More dogfood testing

Discussion

• When a bug is fixed, part of the development discipline should be to check in a unit test that verifies the fix -- particularly when the bug is marked 'regression'. We're not sure what we can do about this besides remind people... We could put reminders in bugs, we could try to remind in code reviews at the very end of the cycle.
  • People might not see this as part of developer discipline

Decisions made:

• We always need more regression tests and Aparna is constantly thinking about this and acknowledges it
• We should make the automated regression test practice expectations a "message of the week" at some point -- Ted will draft a note to dev mailing list.
• Lisa will make sure this is on our contributing code practices Wiki page
• Philippe is already documenting our code review processes which will include reviewing the unit tests
• Katie will find out if anything's blcoking automated sharing testing
• Eating our own dogfood more: need to re-evaluate whether this is possible at the end of the 0.5.04 milestone.

20. Release notes on milestones

• We did a "report card" on the last milestone -- this seemed to be more useful than release notes. It satisfied the need to know what was in the milestone without having to document all bugs.
• We do release notes on releases

---

Issues still not discussed as of Jun 21

21. More structured ways for design/dev to work together

• Paired design/dev with Mimi and an Apps developer was suggested
• Are there ways for Mimi to iterate the UI more easily? Can she do it directly?
• Regular contact with Apps developers

Decisions

• Mimi will preschedule features she wants to iterate on and review in the live code together with developer

22. Review published/supported APIs

• How do we know what our published and supported APIs?
• Can Katie set aside the time to identify what APIs will eventually need to be published and supported?
• Is this a non-code release deliverable? Sheila owns many of those but this particular one is not easy for Sheila to manage -- can Ted own?

Decisions

• Clearly responsibility of Dev platform team, so in one sense or another Katie owns this.

23. Dev environments

• Debrief: people asked for better environments on all platforms and more communication about dev environments
• Note that much of the concern here comes from the Apps team -- naturally, given their challenges involving wxWidgets.
• Is this just about IDEs and other tooling or is it about build practices and other broad issues?
• Has anybody tried Eclipse lately?
• Are there tricks in Wing that people don't all know about?
• Apps team was planning to try Eclipse but it's not a high priority at this moment
• Currently some are using Visual Studio -- but this only works on Windows
• Right now the environment problem is a significant barrier for volunteers, particularly wxWidgets work.
• People who only do Python code will have a much easier time getting started on Chandler. It's hard to go back and forth between Python code and widget code (or other C code)

Decisions

• Ask PJE to think about this, maybe watch people work next time he comes down. Some things that might help aren't necessarily related to tooling, but instead better practices
• David is going to work on a solution for the Mac

24. More shared understanding of architecture

• We already have Katie thinking about this
• Specs are also helping build shared understanding
• Package and parcel hierarchy flattening will make code browsing easier

Decisions

• Request for Katie to prepare architecture overview to combine with parcel/directory flattening
• PJE again a good resource

25. End-user documentation

• Documentation that's suited to our target audience
• User manual (not programmer documentation, not epydoc at all)
• Note wiki reorg and how it plays into this
• Guided tour doesn't quite replace user manual

Decisions

• Sheila will own this (as part of non-code release deliverables) and delegate very heavily
• We'll need to update what we've got and think about what to add when we get closer to release