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

From Eclipsepedia

Jump to: navigation, search
(Things we've done well)
(WTP 3.2 Retrospective 06/17/2010)
 
(4 intermediate revisions by one user not shown)
Line 9: Line 9:
 
== Things we've done well  ==
 
== Things we've done well  ==
  
Maintained last year's "good" list!
+
Maintained last year's "good" list! (esp. such as, keeping up specialty break out meetings, e.g. for Java EE work)
  
JUnits have done better (even if not green often, there are fewer intermittent failures).  
+
JUnits have done better (even if not green often, there are fewer numbers of intermittent failures).  
  
The graduation and integration of jaxws code went smoothly (thanks to shane and daniel)
+
The graduation and integration of JAX-WS code went smoothly (thanks to Shane and Daniel)
  
jsdt creation went well, good to be "own project", has been getting more visibility, interest, help
+
JSDT creation went well, good to be "own project", has been getting more visibility, interest, help
  
WTP is good at meeting deadlines
+
WTP is good at meeting deadlines (less stress, less run over into weekends, etc.)
  
ian mentioned good patch review and apply responsiveness from source editing team
+
Good, timely patch review and application responsiveness from source editing team
  
 
weekly bug focus quality area ... less "home work" to do week to week. Teams kept up and/or had less backlog to start with.
 
weekly bug focus quality area ... less "home work" to do week to week. Teams kept up and/or had less backlog to start with.
 +
 +
welcomed more contribution in source editing
 +
improved diversity in source editing
  
 
== Things we'd like to improve on  ==
 
== Things we'd like to improve on  ==
  
fix more old bugs?
+
weekly quality focus: would be nice to raise the bar ... actually ''fix'' more old bugs (not just triage)
track fix rates
+
  
junits, more passing builds, less intermittent failures (hard to focus)
+
weekly quality focus: add metrics, such as track fix rates
  
performance testing and focus and fixes
+
JUnits: we need more passing (green) builds, less intermittent failures, so its easier to focus when there is a problem.
  
[good] welcomed contribution in source editing
+
We really should do some performance testing and have focused performance milestone where we focus on improving performance
[good]        improved diversity
+
  
could do more explicit verification and closing of fixed bugs
+
should do more explicit verification and closing of fixed bugs
  
documentation -- long planing from everyone would help doc. teams plan what they need.  
+
documentation -- longer term planing from everyone would help doc. teams plan what they need (as is, sort of milestone by milestone).  
  
 
keep up better with base prereqs more timely
 
keep up better with base prereqs more timely
  
do we care or measure use of non-API use, discouraged access
+
We should focus more (and measure) not using non-API, discouraged access
  
 
build improvements (still needed)  
 
build improvements (still needed)  
  
[good] breakout meetings still good .. jee team
+
while some backlogs were reduced/categorized, old, unimportant bugs closed, we need a system to not let backlog build up or grow.  
 +
 
 +
Listing/engaging adopters (e.g. we left out Spring IDE from release materials? RIM?)
  
ian, keeping up with large bug backlogs ... need a system to not let backlog build up or grow.  
+
Publicly listing and acknowledging new contributors? special events? (i.e. we have "new and noteworthy" for function ... but many other "cool activities".  
  
 +
Should we have more tutorials? or webinars? cheat sheets? Special tips? (JSF and Dali do some of this, there is an XML Example). Need more? Encourage community to contribute?
  
 +
Could we engage/encourage earlier testing from users/adopters?
 +
 
 +
Do we need more design documents?
  
 +
Do we need more/better SDK Documents?
  
  
<!--
+
= Links from Other Projects =
=== Note from Other Projects===
+
  
 
Other projects also have their own "retrospectives". Some are linked here, to cross-reference others observations and findings.  
 
Other projects also have their own "retrospectives". Some are linked here, to cross-reference others observations and findings.  
  
* [[Eclipse/Galileo/Retrospective| Eclipse Project]]
+
<!-- * [[Eclipse/Galileo/Retrospective| Eclipse Project]] -->
 +
* [[PDE/Retrospective]]
  
-->
 
  
 
[[Category:WTP_Continuous_Improvement| WTP_Continuous_Improvement]]
 
[[Category:WTP_Continuous_Improvement| WTP_Continuous_Improvement]]

Latest revision as of 03:03, 24 June 2010

Contents

[edit] WTP 3.2 Retrospective 06/17/2010

[edit] Purpose

Following every release, we have short retrospective 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 initially notes from our 6/17/2010 status meeting. Overtime the notes will be categorized, organized, collapsed, etc., to make correspondence to actions clear.

[edit] Things we've done well

Maintained last year's "good" list! (esp. such as, keeping up specialty break out meetings, e.g. for Java EE work)

JUnits have done better (even if not green often, there are fewer numbers of intermittent failures).

The graduation and integration of JAX-WS code went smoothly (thanks to Shane and Daniel)

JSDT creation went well, good to be "own project", has been getting more visibility, interest, help

WTP is good at meeting deadlines (less stress, less run over into weekends, etc.)

Good, timely patch review and application responsiveness from source editing team

weekly bug focus quality area ... less "home work" to do week to week. Teams kept up and/or had less backlog to start with.

welcomed more contribution in source editing improved diversity in source editing

[edit] Things we'd like to improve on

weekly quality focus: would be nice to raise the bar ... actually fix more old bugs (not just triage)

weekly quality focus: add metrics, such as track fix rates

JUnits: we need more passing (green) builds, less intermittent failures, so its easier to focus when there is a problem.

We really should do some performance testing and have focused performance milestone where we focus on improving performance

should do more explicit verification and closing of fixed bugs

documentation -- longer term planing from everyone would help doc. teams plan what they need (as is, sort of milestone by milestone).

keep up better with base prereqs more timely

We should focus more (and measure) not using non-API, discouraged access

build improvements (still needed)

while some backlogs were reduced/categorized, old, unimportant bugs closed, we need a system to not let backlog build up or grow.

Listing/engaging adopters (e.g. we left out Spring IDE from release materials? RIM?)

Publicly listing and acknowledging new contributors? special events? (i.e. we have "new and noteworthy" for function ... but many other "cool activities".

Should we have more tutorials? or webinars? cheat sheets? Special tips? (JSF and Dali do some of this, there is an XML Example). Need more? Encourage community to contribute?

Could we engage/encourage earlier testing from users/adopters?

Do we need more design documents?

Do we need more/better SDK Documents?


[edit] Links from Other Projects

Other projects also have their own "retrospectives". Some are linked here, to cross-reference others observations and findings.