Team thoughts on continuous improvement 30

WTP 3.0 Debriefing 07/10/2008

Purpose

Following our WTP 3.0 release, we'd like to have a short meeting with committers and contributors to discuss possible ways our project might improve.. These include things that you think we did well in this release and things that you think should be changed or improvements that can be made, process changes, etc. This feedback will become critical to our success for our next major release

Please use this page to express priorities, make notes, and brainstorm as many ideas as possible. This will serve as a seed list for the meeting on July 10th, 2008.

Things we've done well

• WTP 3.0 and Ganymede EPP package delivered successfully.
• Quick response time on critical questions from all teams
• Great number of bugs resolved
• Completing smoketest online and declaration of drivers
• Much better better experience from here than past release
• RAMP down was more smooth this time, less pushing of the envelop
• late last minute additions
• exception process, less drastic
• WTP is more mature in 3.0 than 2.0
• Planning process, keeping planning up to date, Raghu, kept on updating the plan throughout the release, keeping the plan up to date, Great job Raghu!

Things we'd like to improve on

• More educational material for users: articles, tutorials, documentation, etc.

Action: Naci ...?

• Education: more material

JavaDoc internal API, in depth comments, SSE, artical or user docs. user guidelines are up to date

Programmers and committers themselves

Some portions, private and protected method/classes with no doc, and hard to understand

with patch creation, no internal javadoc, then harder to get up to speed for new ppl

Some portions of WTP, standard compliance to the specs, false positives

may break adoptors if changing these

• Eliminate build issues, JUnit failures, build breakages WTP Build Break Board
• Build breakage board => Keeps it going for next release

Unit test pass before releasing code

where the test are located, make it better and easier to run the test

easier it is to run test setup

JUnit test with each bug, UI might be harder and content consistent

integration, and variation of the environment, where the test is running, synchronizing the code

Team project with just the test themselves, Team -> export project set

• Improve collaboration:
  • in resolving WTP-wide issues: infrastructure, architectural, etc.
  • in organizing subproject teamwork when team members are spread across the world.

Action: encourage more team meetings, investigate collaboration tools, such as ECF, IRC, semi-standard IRC clents

• Collaboration

Doing well

subproject level - formulate planning, more interaction, not always up to date with the entire sub-project team, more ideas about planning

using mailinglist instead of mailing list

instant messaging

ECF client

long standing request for foundation to start running SMP, a messaging server

IRC channels, Nitin and Dave C are on this, web interfact for IRC chat as well

publishing yahoo and IRC accounts

better communication for everyone

• release candidate, 4 RC, weekly, too stiffling, less RC and more time in between them

2 RC instead of 4?

estimate the # of bugs complete

too many bugs in RC1, always a rush, overestimate

start development earlier, eliminate scope of our features

only critical bugs in the RCs