May 17-18, 2005, Portland, Oregon
| Present | Regrets | ||
John Duimovich, IBM Corporation |
Michael Scharf, Wind River Harm Sluiman, IBM Anurag Gupta, Intel Tim Wagner, BEA John Wiegand, IBM David Williams, IBM Alan Young, Computer Associates |
John Graham, Sybase |
|
(these notes are in logical rather than chronological order)
The council spent most of its time discussing Eclipse Quality and the Eclipse Development Process.
There is some concern that the quantity of new proposals has made it difficult to provide appropriate qualitative reviews, hence there is a risk that the quality of Eclipse projects could slip. Eclipse is known for its high quality frameworks and tools and projects, and thus it is important for us to take steps to retain that.
At the same time, we don't want to be too restrictive. We want to keep the hassle-factor low so that we encourage new ideas to come to Eclipse, but we want to raise the bar (or, perhaps the bar is already high enough, but just not documented) for making a release. We want Eclipse projects to have an open, transparent, inclusive, and welcoming process; we want Eclipse projects to have a wide community of tool users and framework users.
The key question we kept coming back to is "what is quality?"
We should have a low bar so that new ideas can experiment and flourish. The first bar is that the proposed project should match the Roadmap - if the project diverges from the Roadmap, then it's not an Eclipse project, no matter how good it is. The second bar is that the proposal should be clear and contain enough detail so that Eclipse members can decide whether it is interesting or not. The EMO should be responsible for filtering these two bars.
Proposals should discuss the IP concerns (patents, TCKs, licenses, third-party libraries, are their IP rights issues to the standards, etc). Having issues does not disqualify the proposal, but not looking into these issues does. Proposals should also discuss the resource commitments of the initial companies and individuals.
Proposers should be ready to answer questions at the Creation Review around: project overlaps, project dependencies, who's interested in this proposal, what is the end user's view of this project, how is it extensible, etc.
We need people to speak affirmatively about the project. For example, having two sponsors/advocates/champions. The advocates should be from the Architecture Council but from different companies. It is the proposer's responsibility to find the advocates. We want the advocates to be positively supporting the proposal, not just lending their name, thus they should be associated with the project somehow in the public mind. The advocate will say "I believe this proposal is well-formed" and their name will be on the proposal page.
If there are overlaps, the proposers has to ask the overlapee for an opinion. The opinions might range from: "we want to participate" to "we want this not to happen" to "we want to watch this". Overlap is not necessarily bad, but accidental/ignorant overlap is. If there is a plan to deal with the overlap and the Council monitor the situation, then it's ok.
All dependencies should be declared:
The Council acknowledges that this will make proposing new projects harder than before, however we see this an effort to understand new proposals rather than an attempt to exclude proposals.
This discussion went around and around, but the more-or-less consensus was that all projects start in Incubation and that the maturity necessary to pass a Release Review is what it takes to leave Incubation.
We are trying to establish a culture of Eclipse Quality. Release reviews are a way to try to encourage the projects to adopt good open source engineering practices. The encourage is because if the projects adopt these practices, the reviews will be easy to pass. If the projects are not open and transparent, the reviews will be a lot of work. The reviews are also a place to boast about the project's accomplishments.
The key question was what is Eclipse Quality? and secondarily, how can we ensure it? The Platform team brought up the point that it took the Platform two years (100 engineering person years) to get to version 1.0. "APIs are hard. Making things work is hard." We need to set realistic expectations that just being an open and transparent Eclipse project does not magically make good software easier to build.
We need a set of metrics that are run before a Release Review. Metrics can prove a negative (low quality) but cannot prove a positive (high quality). Thus failing the metrics fails the review. An example metric is 100% Javadoc coverage for all APIs.
There was a lot of discussion about whether new top-level projects start in Incubation or can start outside Incubation. One view was that having Incubation for top-level projects would make it hard to recruit new Strategic Developers. The other view was that without Incubation we will end up with un-open-source-experience PMCs setting strategic directions.
The best we could come up with was the acknowledgement that PMCs need to demonstrate:
There was general discussion of "project overlap" and general agreement that no project should (initially) declare API that is not in the scope of their charter or for which there is potential overlap with other projects. In general it was deemed desirable to do as much "peer-to-peer" coordination as possible and not feel Architecture council needs to review or get involved in routine matters. We did not get into any of the details of specific overlaps that currently exist.
There was discussion about provisional APIs and many different opinions. The opinions ranged from:
There was the question (unanswered) of whether it was better to defer release until API, or have well specified provisional API. Some also believed "provisional" would be used as "an easy out" and water-down Eclipse API quality. There was a general desire to have "provisional API" mean "well specified API that might change in future, which would have implied support at least in point releases, migration documentation, etc".
There was basic consensus that Bjorn's proposal of having the package name change between provisional and real API status was not a good thing.
To paraphrase one of the Council members who did a better job of writing up the notes than I did:
... there is a certain sense that defining "Eclipse Quality" (and defining what it means to be "part of Eclipse") is a moving, increasingly high target that everyone in Eclipse is struggling to clarify (the Councils and Board, add-on-providers, as well as us Projects) -- no one wants a "no rules" approach as in some open source communities, nor a "one product" approach either, but finding the right balance, how to specify and gauge achievement and success is an ongoing effort (and probably will be for some time, in my humble opinion).
I couldn't have said it better myself.
Notes taken and posted by Bjorn Freeman-Benson