I’ve been working on some updates to the Eclipse Development Process (EDP) that we’ll roll out in August 2011. The main driver behind these changes is some planned changes in the Eclipse Bylaws.
The Bylaw change that will most affect the EDP is the removal of the Requirements Council. The current edition of the Eclipse Bylaws–dated July 2008–define the Requirements Council as “responsible for reviewing and categorizing incoming requirements, and proposing a coherent set of themes and priorities that will drive the Roadmap (as defined in the then current Eclipse Development Process).” This sounds very good and useful, but has not functioned as designed for many years. The fact of the matter is that the many open source projects at Eclipse define their own plans and chart their own course and the Roadmap has become more of a reflection of reality rather than any kind of driver.
So most of the changes in the EDP 2011 are concerned with removing references to the Requirements Council and the Roadmap. But there’s more. We’ve also proposed changes to modify the description of the role of the Architecture Council (AC) to reflect current reality: “The Architecture Council is responsible for (i) monitoring, guiding, and influencing the software architectures used by Projects, (ii) new project mentoring, and (iii) maintaining and revising the Eclipse Development Process.” I particularly like the last part and look forward to more involvement by the AC in the next iteration of the EDP.
The last relatively significant change for this iteration is the removal of any hint that review documentation needs to be provided in a presentation format. All Eclipse projects are required to engage in various reviews; the most common is the Release Review. In the distant past, a release review required that the project attend a review call during which they were required to present their case. We have long-since removed that requirement in favour of a week-long public review period. The need for presentation-style materials has long passed, and so I took this opportunity to soften the wording a bit to permit other types of document. This will open the door for some automated review documentation generation that I have in mind. More on that later.
Most of the rest of the changes are relatively minor wording tweaks.
The proposed 2011 EDP is here; a version showing the differences between the 2010 and 2011 editions is here. Feel free to discuss your concerns in the comments, or–even better–open a bug.
