Team thoughts on continuous improvement 20

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)

• Agree with Nitin. We need to start functional planning earlier. In the beginning of a new release, there is too much emphasis on the previous release's maintenance stream. We need to work on feature work and planning, but not just that, we also need to start development wise. (Konstantin)

• We need to focus on requirements immediately and engage more component and community feedback. This should happen before the bulk of maintenance stream bugs are worked on. Criticals and blockers are fine to fix, but in general, we should focus on 3.0 requirements right away. (Raghu)

• We need a common consistent coordinated branching strategy for maintenance streams. There are many benefits and it offers good transparency and limits confusion. (Kosta)

• The new PMC approval flag system is working well. (Kathy)

• We should have a coordinated plan for triaging/closing/fixing the ever growing backlog of over 3000 bugs. We might not want to blindly close, especially enhancements as we may see community frustration, but we could flag all no plan to fix bugs with help wanted and triage accordingly for our numbers. (Chuck B)

• Newsgroups - Are we giving the proper attention? Should we have a rotation for newsgroup monitoring? There is a great deal of value we may be missing in keeping track of the kinds of problems real users are having. The consensus seems to be to leave it up to each component to ensure there is one team member watching the newsgroups ever week. Everyone should be more diligent about seeing queries without responses and forwarding them to the mailing list for help from the general committer community. (David)

• Perhaps we should do the debriefing more than once a year, maybe twice? (David)