Team thoughts on continuous improvement 15

Comments from WTP 1.5 Debriefing

Purpose

Following our WTP 1.5 release, we had a short meeting with committers to discuss possible ways our project might improve. One of the things suggested was to start a wiki page for all these good ideas where they can be "discussed", evaluated, and implemented (or not). So, this one action is implemented already! :)

The following (as starting off, at least) are the notes taken for the ideas captured during the meeting held on 7/13/2006. This hopefully will provide the "seed" to make this a part of our normal development processes. I suggest we not use it, though, as a wish list, but to try and focus on the top 3 or 4 things that are either a.) easiest to do, or b.) have the biggest impact (just like bugs :)

Feel free to use the "talk" page to discuss, express priorities, or you can even make notes here, if/when implemented, etc. Or, if you have new "brainstorming" ideas, feel free to add them. Occasionally even this "main" page may undergo big revisions, such as after some discussion and prioritization, the items may be categorized or re-arranged, so, be sure to add yourself to the watch list and check back occasionally.

Seed list from 7/13/2006 discussion

• Would be nice to have 4 or 5 line weekly email status from each component -- just "activity that week" to help us all stay aware of what's going on, and where our efforts go.

• Should have more emphasis on verification of defects - through out each milestone, don't wait till end of release.

• Every team should document something new, each milestone, to generate excitement so to users and adopters will be motivated to move to that new milestone, and provide more timely feedback.

• Need more test coverage, avoid regressions. "new tests, before new function".

• Need better planning and prioritizing ... especially more rigor around early planning

• A possible mechanism to improve planning and requirements: its easier to edit than to author, so need more straw-man proposals (of requirements and plans) to get better feedback.

• Need to better distinguish requirements wish list, from committed milestone plans. This would be a good way to highlight "help wanted"

• Good to set expectations, and publish what WON'T get done, at least without more contributions.

• Could better measure quality, besides "pass/fail" ... number of tests ran, percentage of coverage. This coverage should include function and OS platforms and JRE versions.

• Translation and accessibility tests could be more open and public. For example, TVT tests should be on web or in repository where anyone can get them (and provide feedback!).

• Would be nice to have more specific build notifications. For example: RSS for normal builds. Mailing lists for failures, Notify contributors-to-a-build with a note to their email address. (152277)

• Should do better job of triaging bugs on a week by week basis. Some components leave in in-box for a long time. We should write down our process of triaging, what the different "states" mean.

• Would be nice to have a plan of when something is planned to be fixed. (Which milestone, or release). This might even be useful as another indicator of "project health" ... how many items are moved from milestone to milestone (indicating over optimistic planning, or too few contributors ... or both!). [revisit Kosta's idea he posted to mailing list]

• Maybe it would help to have a wiki or blog of "higher level" activity (higher than just bugs, lower than new and noteworthy), kept up-to-date (through out or per) milestone so users and adopters could stay better aware of what to expect.

• We should better published plans (especially dates) of releases, fix packs, etc. This is both intra-team communication (such as PMC communicating to committers), as well as us communicating to community and adopters.

• Better to plan so that we don't have to smoke test more than one build a week. Helps avoid "testing fatigue".