Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Team thoughts on continuous improvement 32"
(→Things we've done well) |
(→Things we'd like to improve on) |
||
| Line 25: | Line 25: | ||
== 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) |
| − | + | ||
| − | + | 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 -- | + | 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 | ||
| − | + | We should focus more (and measure) not using non-API, discouraged access | |
build improvements (still needed) | 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. | |
| − | + | ||
| − | + | ||
Revision as of 02:43, 24 June 2010
Contents
WTP 3.2 Retrospective 06/17/2010
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.
Things we've done well
Maintained last year's "good" list!
JUnits have done better (even if not green often, there are fewer intermittent failures).
The graduation and integration of jaxws 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
ian mentioned good patch review and apply 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.
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.