I've added a few definitions to the document. They may be wrong; I put them in there because I get the feeling that my definition of what
means is different from yours.
In my email regarding goals, I started by defining what I thought are three different aspects of this process. In my mind, it was helpful to keep these separate.
- The development of the specifications themselves;
- The process of ratifying and promoting official specifications; and
- Certification of implementations of ratified specifications.
One big difference between the JCP and what we will do is, I believe, that we won't spin up an entirely new JSR/team for each version of the specification. In my mind, the Specification Project is an open source project in the sense that it is defined by the Eclipse Development Process (EDP). Team members come and go, but the project itself persists. That project is responsible for generating all releases of the specification.
Development of the Specification
The general process that Eclipse open source projects follows is this:
A project proposal defines a scope of work that (generally) persists for the lifetime of the project (the scope can be changed if there is good reason to do so). Each release cycle starts with planning. For some projects this planning is an informal list of issues; other projects are more rigorous (we can decide what level of rigour is required for a Specification Project). Milestone builds give the primary stakeholders an opportunity to review the work and provide feedback. The final release is what is delivered to the broad community.
The open source project team is responsible for generating the artifacts associated with the Specification as part of a release (as specified by the Eclipse Development Process. I believe that this minimally includes a document and API, along with pointers to an official reference implementation and TCK.
Concerns regarding IP flows notwithstanding, I believe that the EDP almost competely covers this part of the process. You can, for example, think of the notion of milestone builds as early draft releases in the JCP sense. We can decide how or if the Specification Committee reacts to milestone builds: we could add a formal approval process, or make it more organic (the primary purpose of milestone builds is to generate feedback from primary stakeholders; the Specification Committee and implementors are among the stakeholders who can provide feedback to incorporate into a subsequent milestone build).
Ratifying
The Specification Committee, then, is responsible for ratifying and promoting the output of the open source project's final release as an official specification. By the time we get to the point that a Specification Project makes an official release, the committee (and vendors) should have consumed milestone builds and provided feedback, so that final ratification step should be relatively straightforward.
So, I think that the spec creation and ratification process looks a little like this:
The project proposal includes a scope, so getting the Specification Committee's approval seems pretty natural.
Likewise, setting the plan at the beginning of a release cycle seems like something that the Specification Committee should get some say in. I tend to prefer a feedback loop model for milestone builds rather than formal approval (but am ready to be convinced otherwise).
Strictly speaking, the PMC approves releases, but we may decide to give the Specification Committee some say here. The main role of the PMC in the release process is to ensure that the process has been followed correctly and that the project is operating according to the open source rules of engagement.
Ultimately, the Specification Committee has to ratify (and promote) the specification.
In terms of coordinating the delivery of multiple specifications, our experience with the simultaneous release may provide some good answers. More on this later.
Certifying
The final part is the actual process of certifying implementations. For this, I mostly just have questions.
Thoughts?
I can provide an overview/primer of the EDP on the next call if there is interest.
Wayne
