Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

(Proposed list)
(Proposed list)
(One intermediate revision by one other user not shown)
Line 15: Line 15:
 
3) Engaging our "silent" adopters in other ways?  Provoke feedback from the entire community?
 
3) Engaging our "silent" adopters in other ways?  Provoke feedback from the entire community?
  
4) Modernize out infrastructure: CVS -> Git, PDE Build -> Maven/Tycho, CruiseControl -> Hudson.  
+
4) Modernize our infrastructure: CVS -> Git, PDE Build -> Maven/Tycho, CruiseControl -> Hudson. Start with education, prototyping.
  
5) ....
+
5) Focus on quality of build - how do we ensure consistent green builds? Faster notification of failures? Should releng problems have different severity depending on phase in release? Can we work on separating normal build from junit execution?
 +
 
 +
6) Improve participation on forums, newsgroups - Could address in status meetings? All committers should subscribe for notification.
 +
 
 +
7) Improve communication with community - advertising all contributions and improvements via Blogging, announcements, papers etc.
 +
 
 +
8) Improve build breakage reporting to show trends over time.... 
 +
 
 +
9) Provide automated scripting for downloading smoke builds
  
 
== Purpose  ==
 
== Purpose  ==

Revision as of 16:48, 25 August 2011

WTP 3.3 Retrospective 08/4/2011

Action plan

Proposing a short list of improvements that results from the discussion list below. The proposal list can be made by individuals "voting" for a specific improvement. (details to be worked out) Starting August 18th - the "top 10 list" will start to be formed. (Encouraging all committer/adopter to add proposals) Also - forming and voting on a list should also include a commitment from individuals to work on each area of improvement.

Proposed list

1) Improve WTP documentation and samples

2) At least yearly "State of WTP" to communicate recent and future improvements

3) Engaging our "silent" adopters in other ways? Provoke feedback from the entire community?

4) Modernize our infrastructure: CVS -> Git, PDE Build -> Maven/Tycho, CruiseControl -> Hudson. Start with education, prototyping.

5) Focus on quality of build - how do we ensure consistent green builds? Faster notification of failures? Should releng problems have different severity depending on phase in release? Can we work on separating normal build from junit execution?

6) Improve participation on forums, newsgroups - Could address in status meetings? All committers should subscribe for notification.

7) Improve communication with community - advertising all contributions and improvements via Blogging, announcements, papers etc.

8) Improve build breakage reporting to show trends over time....

9) Provide automated scripting for downloading smoke builds

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 some initial topics(some from last year) to help start the discussion in our status meeting. Notes will be collected, and will be categorized, organized, collapsed, etc., to make correspondence to actions clear.

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).

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

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).

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?

Could we engage our "silent" adopters in other ways? What problems adopters have or "had" with WTP?

Better/more frequent engagement with our users in the newsgroups/forums.

At least yearly "State of WTP" - All WTP subprojects could provide a short summary of recent achievements, and future plans. (Similar to Eclipsecon ending panel, but for only WTP).

Links from Other Projects

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

Back to the top