We can engage in a Restructuring Review for a project when we have the necessary information: new name and scope, and a reasonable subset of committers who are covered by the necessary agreements. I recommend that we batch these reviews in small groups as the information becomes available, starting with a smallish batch of three to five projects.
I will initiate the ballot for Specification Committee approval as soon as we decide to move forward on each batch of projects.
To declare success on the Restructuring Review, we'll need:
- One week of community review;
- Approval from the PMC; and
- Super-majority approval from the Specification Committee.
Note that we schedule all reviews to conclude on the first and third Wednesday of each month; the one week of community review will be scheduled to start one week ahead of a first or third Wednesday.
Note that all committers on a Specification Project must be covered by an updated committer agreement and WGPA. Those committers who do not have the necessary paperwork will be retired when we convert existing projects into Specification Projects.
The EMO will declare success on the review when all of these requirements have been met and will then apply the changes.
Create Specification Documents. Project teams will need to create Specification Documents following the template that we provide. I believe that Arjan is creating an example that includes the name, scope, and generated JavaDoc that we intend to present as the example.
We'll ask the Webmaster to create separate Git repositories in each Specification Project specifically for the Specification Document.
Engage in a Progress Review. Per the EFSP, at least one Progress Review is required. If we are to strictly follow the process, then we need to engage in a Progress review that requires a 30 day ballot of the Specification Committee after the project team presents the Specification Committee with complete Specification Document. For a Progress Review, we'll need the project teams to demonstrate that the work that they've done is in scope, that they're following the process, and that they're otherwise on track for a successful Release Review.
Again, these Progress Reviews can be run in small batches as project teams complete the work.
To declare success on the Progress Review, we'll need:
- One week of community review;
- Approval from the PMC; and
- Super-majority approval from the Specification Committee.
Note that I'm assuming that doing reviews in small batches will be easier on Specification Committee members than doing them one-at-a-time. I'm also assuming that showing progress by doing them in small batches is better than waiting for everything to be done before we start any review.
Engage in a Release Review. Again, the JESP requires 30 days for the Specification Committee ballot.
To declare success on the Release Review, we'll need:
- One week of community review;
- Approval from the PMC; and
- Super-majority approval from the Specification Committee.
Since most of the specifications share a TCK, these reviews will likely be done in larger batches, with the TCK release version finalized for all specifications before we engage in the process for the first batch (or we can wait and batch them all together, which probably makes more sense).
Request a process exception. Engaging in both a Progress Review and a Release Review seems excessive. Especially so in light of the 30 day ballot requirement for each.
I recommend that we ask the PMC to grant an exception to the process and skip the Progress Review in this exceptional case. We can probably explore some trickery to run the Progress Review concurrently with some other part of the process, but doing so would only be implementing process for process sake and--I believe--of little real value. A formal exception grant from the PMC is, I think, more respectful of the process.
Promote the Final Specifications. After we've successfully concluded the Release Reviews, we can promote the Final Specifications. We need to start a separate discussion on how this will actually manifest.
Theoretically, some of these reviews may fail. Traditionally, we don't generally put much thought into the failure condition and instead put energy into setting project teams up for success. The Specification Committee should, for example, plan to start reviewing and talking about project scope statements before we start the Restructuring Review to ensure that there are no surprises.
Discussion invited.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
