Difference between revisions of "Team thoughts on continuous improvement 31"

From Eclipsepedia

Jump to: navigation, search
(Things we'd like to improve on)
(Purpose)
Line 2: Line 2:
  
 
== Purpose ==
 
== Purpose ==
Following our WTP 3.1 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. You can add things before the meeting (or after) just make clear when added.  
+
Following our WTP 3.1 release, we had short post mortem to discuss possible ways our project might improve. This starts with a list of things we like and don't like about how the release went, and will evolve into action items with people assigned to be responsible, where appropriate.  
  
 +
Below are the raw notes from our 7/9/2009 status meeting.
  
 
== Things we've done well ==
 
== Things we've done well ==

Revision as of 21:18, 9 July 2009

Contents

WTP 3.1 Debriefing 07/09/2009

Purpose

Following our WTP 3.1 release, we had short post mortem to discuss possible ways our project might improve. This starts with a list of things we like and don't like about how the release went, and will evolve into action items with people assigned to be responsible, where appropriate.

Below are the raw notes from our 7/9/2009 status meeting.

Things we've done well

Policy and practice of firm deadline for weekly I-build with same-day declare.

Regular, consistent weekly build good, even if actual delivery following Tuesday.

Some long standing performance bugs finally addressed (in XML Editing and related).

Plans (XML format and bugzilla entries) with dynamic, iterative updates.

Team discussion "broken out" so doesn't overwhelm WTP status call with detail.

Dates on Google calendar.

Frequent (weekly) but short status calls.

Things we'd like to improve on

Too many intermittent junit failures: especially in that there are too many long periods build failures. Failures (even compile errors) begin to be ignored since failures so common.

Builds take too long: especially in that it takes a long time to get notified if problem or not after checking in code.

Lack performance suite or benchmarks.

Lack of dependent project communication, such as emf or platform, both if and when "breaking" changes coming and once we learn of it, seems there's no central place to learn of all "breaking changes".

Hard for newcomers (even adopters) to get "acquainted" or integrated with WTP policies, practice, and rhythms so testing isn't done early enough and communication is awkward, hard and takes too long to get worked out. [The break-out meetings such as for JEE have helped.]

Lots of code checked in with no junit test (both new function and bug fixes).