Revision as of 14:08, 12 July 2007

WTP 2.0 Debriefing

Purpose

Following our WTP 2.0 release, we want to have a short meeting with committers and contributors to discuss possible ways our project might improve. This can be things you don't like, things you like, things you want changed, improvements you think need to be made, process changes, etc. This feedback will become critical to our success and your happiness during WTP 3.0.  :-)

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 12th, 2007.

Seed list for 07/12/2007 discussion

• The bug approval process seemed to work well this time around - not that it hasn't worked before, but I think the approach of raising the number of required PMC votes gradually as we approached end of release was a very effective way of measuring and enforcing stabilization of the release without making it too difficult for components to fix key issues. (Chris Brealey)

• Strategically, the migration, re-versioning, re-packaging, re-factoring of several third-party bundles from WTP to Orbit was the right thing to do, however, I think we seriously underestimated the impact of the changes and made them far too late in WTP 2.0. For WTP 3.0, any further desired changes to third-party bundles should be raised as RFEs and completed before the penultimate milestone - not in the last milestone or during the Release Candidate cycle that follows. (Chris Brealey)

• It would be nice if there is a specification document for each UI feature in WTP. This would help users and new developers to see if some component in WTP behaves as designed or there is some problem. The specification will be also the base ground for UI testing and future enhancements. For example, the specification of the Servlet wizard should describe what the purpose of each checkbox or text box is, how they influence the creation operation of the servlet, what error messages should be displayed, etc. The wiki would be the best place for these docs. (Kaloyan Raev)

• The maintenance burden for 1.5.0 meant that most committers didn't have the chance to work on or plan items for 2.0's first two or three milestones. Except for defining the release's requirements, our planning process fell apart. Publishing milestone plans is an essential part in getting early feedback from our adopters and the larger community. Should we at least expand on the "Teams Status and Focus for Coming Week" section of our weekly meetings to hit on our milestone line items? (Nitin Dahyabhai)

Back to Team Improvement Home

Back to Web Tools Wiki Home