Guidelines for Notifying the Membership of Major New Features

Each Project's leadership is required to ... notify the membership-at-large of all major new features and new code contributions via the defined membership notification mechanism (e.g., specific mailing list). ... It is a clear requirement of this document that members who are monitoring the appropriate media channels (e.g., mailing lists or RSS feeds) not be surprised by the post-facto actions of the Projects.

(1) How Do I Notify The Membership?

R To notify the Eclipse membership-at-large of a major new feature or code contribution containing new features, send an email with a short description to emo@eclipse.org.

The EMO will forward your notification to the membership via an addendum to the "upcoming reviews" announcement at the next two week review cycle. (This mechanism batches notifications to avoid overwhelming our members' inboxes.) Your Eclipse Development Process notification requirement is complete once you've notified the EMO.

The notification email has the following form:

The XYZ Project is working on new feature MNO for its next major release. An MNO is a powerful new way to blah blah blah...  For more information about MNO, contact the project team on the XYZ-dev@eclipse.org mailing list.

or, for code contributions:

The XYZ Project is accepting a large code contribution from ABC to implement new feature MNO for its next major release. An MNO is a powerful new way to blah blah blah...  For more information about MNO, contact the project team on the XYZ-dev@eclipse.org mailing list.

(2) What is A Major New Feature?

GUnfortunately, "major new feature" is a qualitative assessment rather than an easily computable quantitative one. The basic rule here is that the Eclipse membership-at-large must be sufficiently informed that they are not surprised by new features during a Release Review (assuming that the membership has been staying current with the announcement from the Foundation; this "no surprises" rule does not apply if the members cannot be bothered to pay attention).

Some examples that could apply as major new features include:

• a new language supported by CDT, e.g., C#
• a new update manager integration with Windows MSI installer
• new combined single-session debugging support for AJAX on a client and JSF on a server
• new look and feel for the entire Platform
• etc.

As a sizing rule of thumb, we anticipate that an active major Eclipse Project would send out about three or four of these announcements per year.

The intent of this requirement is not to prevent or discourage major new features, but rather to inform the membership that these new features are upcoming.

(3) Are There Alternative Ways To Make Announcements?

GThere is another way to announce major new features without sending an announcement email to the membership:

• The major new feature is described in the docuware of any Review. This means that if the project is releasing version 2.0 and, at the end of that review, talks about its plans for version 3.0 the following year, that plan announcement qualifies. In fact, announcing major new efforts at the Release Review is the easiest way to make these announcements.

(4) What About New Committers?

R If the major new contribution includes adding new committers to the project, the announcement must include (or have a link to a public document or email archive that includes) the names, affiliations, short bios, and justifications for the new committers. This information about the new committers is identical to what would be provided in their nomination message if they were to be elected rather than arriving with new code.

 

Report flaws and request clarifications through bugzilla