Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Team thoughts on continuous improvement 30

WTP 3.0 Debriefing 07/10/2008


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

Back to the top