Finally, this year’s rev of the development process is here. Every year Bjorn and the community at large review the development process as it is practiced in the projects and as it is required to be practiced by the Foundation structure. Great care is taken to update the process document, clarifying, simplifying, detailing. These changes are done in the open way with lots of interaction. Regular readers of PlanetEclipse will have seen Bjorn’s posts (1, 2, 3, 4, 5, 6) about the revisions as far back as March.

Well, after a couple delays, the Eclipse Board of Directors ratified the process in the August meeting. It goes into effect immediately.

What does this mean to you? There are numerous changes but here are the highlights:

Hierarchical Projects
No more special “components” – everything is sub-project (or a sub-sub-project, or a sub-sub-sub-project, etc). This closes some loopholes where community reviews were not being done as components were being created but it also means that you can incubate at any level in the project structure. Remember that incubating projects are able to use the parallel IP process to speed the initial introduction of work and the use of third party libraries. A real bonus.

Streamlined Reviews
Reviews are an important part of the community. They encourage openness and cross fertilization. Unfortunately they are one of the more underrated and more maligned elements of the process. People see them as a hurdle to be jumped rather than an opportunity to checkpoint/cleanup, market and gain interest. People outside projects more often than not ignore reviews and thus miss out on the chance to get the quick overview and ask questions about the future. In trying to keep the dev process lined up with current reality, the review process has been simplified to eliminate the requirement for a vote or a conf call since in practice, few people voted or showed up. Instead, members can request a call if they have issues they would like to raise. This seems like a good balance between openness and expediency.

Clarifying “Release”
Projects often say “we released X.Y” when they mean, “we made X.Y [ is available | has been built | can be downloaded | ...]“. For better or worse, the word “release” has some meaning in the formal structure of Eclipse. It implies IP reviews have been completed, code has been tested etc etc. This mismatch in terminology can lead to mismatched expectations between the teams and the consuming community.

The new development process clarifies the terminology and sets out the numbering schemes for releases and milestones (not releases).

Summary

All in all this is a great update to an already great document. No doubt there will be more revisions next year. The Eclipse community is dynamic and the projects come up with new scenarios and requirements all the time. Evolving this document is key to developing and maintaining a coherent community. Thanks Bjorn et al for making this happen.

Tags: eclipse, syndicate