Eclipse Requirements Council Minutes

["Tim Wagner" <twagner@xxxxxxx>]

Since we were discussing the requirements council this morning, I thought I’d post minutes:

 

Planning Council:

http://www.eclipse.org/org/councils/20050823PCMinutes.html

 

Requirements Council:

See attachment.

 

Neither spell out the resolution from the plenary session to use Bugzilla; I don’t have any minutes from that. (David, do you remember if anyone was taking them?)

 

Title: Eclipse Requirements Council Minutes

Eclipse Requirements Council Minutes

May 17, 2005, Portland, Oregon

Present			Regrets
Paul Clenahan, Actuate John Kellerman, IBM Corporation    Bjorn Freeman-Benson, Eclipse Martin Klaus, Wind River James Saliba, Computer Associates Melissa Traynor, MontaVista	Georg Lenz, SAP Mike Milinkovich, Eclipse Mike Norman, Scapa Technology Anurag Gupta, Intel Shane Pearson, BEA		Boris Kapitanski, Serena Philip Ma, HP Mike Norman, Scapa Karl Reti, Sybase

Minutes / Discussion Items

(these notes are in chronological order)

Overiew

Since there were many new members of the Requirements Council, Mike Milinkovich provided a brief overview of the Roadmap process and how the Councils had operated in the past. A copy of the presentation materials can be found here (.pdf).

Incubation

The Requirements Council had a lengthy discussion on the whether the Eclipse Development Process needed to implement an incubation stage as part of the process. The general consensus was that incubation was a good idea, and that the primary focus for incubation was to focus the early project start up on community building. Some thoughts on what incubation does and does not mean include:

• The goal is to have each project foster a demonstrated community of users.
• Each project must demonstrate that they are operating using an open and transparent process.
• Incubation is not a statement of quality. In other words, exiting incubation does not guarantee that the project can or will ship.
• Incubation is a state, not a place. In other words, Eclipse projects can be incubated within any top-level project. Proposed projects which have no obvious homes, will be created in the Technology PMC. A project's decision to be in the Technology PMC or some other top-level must be PMC open and transparent.
• It is important that the entry and exit criteria be explicitly defined and that the guidelines be community-based.
• It is recommended that the existing Checkpoint Review in the Eclipse Development Process be redefined to be the stage at which projects exit incubation. This will require that the exit criteria include (amongst others) specific goals for community building.
• Re-organization of existing projects is allowed without incubation. This is because incubation is really about the skills of the development team and their experience in community-building.
• It is important that these criteria be enforced, which means that it is possible that projects can fail incubation.

The Eclipse Foundation needs to define the branding for the state of "incubation", so that consumers have a clear view of the maturity level of the project they are using.

For projects which do incubate within the Technology PMC, migrating to another top-level project would normally be part of exiting incubation.

two axes: incubation  X  affiliated
cannot be 1.0 in not affiliated and not incubation

Release Numbering and Synchronization

The Requirements Council discussed whether projects need to use a common version numbering scheme. E.g. if a project is based upon Eclipse 3.1 platform release, then it would use "3.1" as its version number. The consensus was that project version numbers contain useful information. For example, they imply a certain level of maturity for the project. As a result, synchronized numbers are not required (nor even desirable).

That said, there is a strong desire to help users more easily discover which project releases work together.

There is a strong interest in having the projects synchronize their releases. The Requirements Council would like to recommend that the projects define an "opt in" list of projects which ship together. The current list of such projects includes: Platform, CDT, VE, GEF, EMF, BIRT, TPTP, WTP. By "synchronized", we literally mean "same day". It is recognized that for this to happen, some projects (e.g. Platform) may need to lengthen their end-game in order to get everyone synchronized.

For there to be a realistic attempt at synchronized release dates, three will need to be a config control committee for the synchronized release - perhaps this is the Planning Council?

Most projects are expected to ship a major release per year, with patch releases roughly quarterly. Projects can elect to ship more releases per year if they so desire. This is typically required for newer projects which are focused on quickly expanding their functionality. If projects do make several major release per year, there is a strong desire that one of those releases sync up with the major synchronized platform release.

Update Manager Sites

There is a requirement that each PMC ensure that there is an update site for use by the Eclipse update manager.

Requirements Management

There is a need for the Requirements Council to track requirements which are brought to the RC through to the final deliverables. This is needed to track the effectiveness of the Requirements Council process.

• Implement a process that tracks the feature requests that the RC cares about
• Each feature request needs to map to one or more bugs (as tracked by Bugzilla)
• The status tracking will be based on the Bugzilla status
• Perhaps we need to push for an open source Requirements Management project at Eclipse?
• Perhaps implement a simple MySQL database that accesses Bugzilla’s for status reporting? Login credentials for write access would be given only to RC members.
• Alternative implementation --- perhaps create a product in Bugzilla for “Requirements Council”?
  

ACTION: Bjorn is to propose a requirements tracking process for Requirements Council. How will the data be tracked and reported?

Eclipse Quality and Branding

The Requirements Council discussed a number of items related to what it means for Eclipse projects to ship releases under the Eclipse "brand". Some of the questions discussed included:

• What should it mean to have the Eclipse brand attached to a project?
• What are the quality requirements?
• How proactive should we be?
• How can we enforce this in an open-source project?
• What role does the RC have in establishing quality objectives for Eclipse projects?

Below are notes taken during the discussion:

• What role does the Requirements Council have?
  • The RC should identity what quality goals the open source projects should define and implement.
  • The RC represent the consumers, so they care deeply about the quality statements from the projects
  • RC would like to see defined policies for:
    • APIs are key --- extensibility for product builders is key for definition of success
      • Maturity states: Low, Medium, High, Platform
      • Classification: API (Platform maturity), provisional (Low, Medium, High maturity), internal
    • Exemplary tools good enough to attract a large number of adopters is also key
    • Release-to-release migration policies
    • Documentation standards
    • API and backwards compatibility
    • Project maturity model
    • What has the project done to leverage automated test, community feedback to ensure quality? Each project should make a statement on what they have done to ensure quality. There is a clear feeling that having each project ship an automated test suite is a high value add for consumers. In fact, the RC would like to make an automated test suite an exit criteria for release reviews.
• The RC would like to request that a number of documents which are Eclipse project only be updated and made applicable to the entire community (e.g. Eclipse Quality APIs)
• What should it mean to have the Eclipse brand attached to a project?
  • This applies to every project shipment of release 1.0 or greater
  • Production quality
    • Usability (compelling UI quality). The exemplary tools really need to be good.
    • Performance and scalability
      • Current cross-platform performance and scalability (e.g. Solaris/Motif, Linux/GTK) need to improve.
    • Automated tests and/or quality plan
    • Release to release migration, with statements on source and/or binary compatibility and tools to assist migration as/where appropriate. This applies not only to plug-ins, but also the artifacts created by previous plug-in versions (e.g. models, report descriptions, etc.)
  • API stability (long term!)
  • IP due diligence
    • Predictability
  • Features, plans and dates were met by the project
    • Demonstrable community involvement and participation
  • Open and transparent development processes in place
    • The RC would like explicit coverage of each of these items in project release review

Requirements for New Projects

The Requirements Council discussed a number of items related to starting new projects and what set of expectations are appropriate for them. Some of the questions discussed included:

• Projects should be:
  • Easy to propose
  • Fairly easy to create
  • Kinda hard to validate (e.g. exit incubation)
  • Pretty tough to ship
  • In other words, the process we have is more-or-less right
• We need to do something with top-level as well. We need PMC training wheels.
  • Top-level projects do need to be in an incubation state for some period of time
  • They exit incubation via a checkpoint review, with the exit criteria being similar to a sub-project review but with a few extra ones to check on conformance with the project charter and governance.
  • We need to be a better definition of mentoring PMCs and documenting what they need to do.
  • When doing reviews (creation, checkpoint, release) we need to explicitly split what is being reviewed that is part of the top-level project, and what part is made up of the content of the sub-projects.
    

ACTION: Bjorn and Mike are to define the exit criteria for a checkpoint review.

Notes taken and posted by Bjorn Freeman-Benson and Mike Milinkovich