Eclipse 2.0 Retrospective Actions
August 29, 2002
In August 2002 retrospective sessions were held with the various component
teams to discuss what worked (and didn't work) with the 2.0 release. Based on
the feedback collected during these sessions, we agreed on the following actions
for the 2.1 effort.
- We will actively and visibly track issues.
- We will publish a top ten issues list and track it on the Eclipse web.
- Many issues span components; these issues will be addressed by dynamic
teams with members from different components. Dynamic teams will have
team leads that are responsible for delivering the resolution to an issue.
- We will continue to work in monthly time boxes.
- There will be a milestone defined for each time box.
- Teams make their milestone plans accessible on the Eclipse web.
- We will do a an "everybody tests" day at the end of
- We will reserve time for writing tests in each time box.
- Each team will develop on their latest code (daily plug-in export).
- We will improve bug handling.
- First line bug triage will be off-loaded from the component owners.
- We will document and follow the same bug work flow in all components.
- We will make the current bug situation visible on the Web in the form
of a chart that is updated automatically.
- We will investigate Bugzilla UI improvements.
- We will make the planning process more visible.
- We will make a proto 2.1 plan available early in the release
- We will have weekly planning update meetings.
- Each component lead will give a concise status about what has happened
last week and what is planned for next week.
- The meeting minutes will be made available on eclipse-dev developer
- We will provide an additional channel for quick interactions.
- Committers will be connected to instant messaging (need to decide about
- We will improve the Eclipse Web portal
- We will improve navigability.
- We will separate the user from the developer domain.
- We will provide support for contributing announcements.
- We will refactor the newsgroups (to separate users from developers).
- We will improve the way we do documentation.
- We will define a style guide and agree on tools.
- We plan and test documentation as part of the development process.
- We will invest in tools that make the checking less painful.
- We will provide content earlier.