Clarify if plan is needed for Creation Review

[edbratt]

Looking at the diagram under "Specification Version Lifecycle," it seems odd that a specification project may be created, but it doesn't need a formal plan until it's been released, once. Perhaps a Plan is assumed as part of the Creation Review materials. Even if this is actually spelled out in the EDP, I'd like to see the text here, make that explicit if so.

[edbratt]

Just to make sure I state: I would prefer that there just be a creation review -- The material/documentation should include whatever details would be included by a Plan review. Why have creation review vote, followed by a plan review vote? Just seems like needless additional steps.

[waynebeaton]

In the Release Plans section, the EFSP states:

The Project Proposal serves as the Release Plan for the first release of a Specification Project.

Rolling the plan review into the creation review was, as I recall, intentional, to avoid the scenario that you're describing. We likewise have the project proposal serve as committer elections rather than run them separately.

Neither the EDP nor the EFSP make any requirement of the form of planning aspects of the project proposal (or plans). The project proposal form, has a few sections, however, that are useful in this regard.

The Project Scheduling section of the project proposal form has this description:

Describe, in rough terms, what the basic scheduling of the project will be. You might, for example, include an indication of when an initial contribution should be expected, when your first build will be ready, etc. Exact dates are not required.

My expectation is that a project team provides plan information here. In practice, however, we have not made that requirement; that's something that I'll have EMO focus more attention on. The specification committee can provide specific guidance if they'd like to see specific information provided.

It also has a section for description Future Work (strictly speaking, though, this is probably not where I'd expect to see plans for a first release).

[edbratt]

So it would be fair to suggest that Creation review is all that is needed to start a project is the creation ballot -- as illustrated in the diagrams.

[waynebeaton]

So it would be fair to suggest that Creation review is all that is needed to start a project is the creation ballot -- as illustrated in the diagrams.

The intention is that the creation review serves as the plan review. For the creation review to be considered successful, we need an affirmative result from a specification committee ballot. So... the specification committee members, when deciding how they intend to vote on a creation review, need to keep this mind.

This is one of the reasons why we have a community review: to give an opportunity to socialize and modify a proposal before we commit to creating the project. It is, IMHO, bad form to just show up with the specification committee and say "vote on this" without first giving them a chance to review the proposal, ask questions, request modifications, etc.

[dblevins]

I personally do not feel comfortable with a brand new spec that has never before delivered anything going from "hey we have an idea" straight to "we'd like approval for final release." There is no realistic opportunity for the specification committee to give guidance which is likely to be necessary more often from a new group of people.

Our mission statement for the various reviews has always been to create the most sure path to a successful Release Review.

I'd be ok to skip doing a separate Plan Review if we instead trade that for a requirement that as a new specification project you need to do at least one Progress Review before you're eligible for a Release Review.

I'd like to point out history where this has been a problem. CDI (JSR-299 Web Beans) came in with one set of promises in the description of the JSR. By the time it got near the end what had actually been developed was very different to what many felt they approved at creation. The requests for approval did not come in till very near the expected delivery date of Java EE 6. It ended up taking several months longer to get everyone on the same page so that a positive release vote by the JCP EC could occur. Because CDI 1.0 was planned to be included in Java EE 6 and hit delays at the finish line, Java EE 6 was itself delayed and missed its JavaOne 2009 deadline of June and was instead delivered in December 2009.

New specifications by definition are unproven, have a lot of hopes and dreams attached to them and new teams not necessarily on the same page. There has to be some review after Creation Review and before Release Review. If we do not we're setting ourselves up for repeat failure and discord at the Release Review and it will impact timelines overall.

I think it's fine to skip a Plan Review, but then some mandatory review like a Progress Review about half-way in should be required.

[waynebeaton]

The line that I quoted has been in the EFSP since version 1.0:

The Project Proposal serves as the Release Plan for the first release of a Specification Project.

That is, the notion is not something that I'm trying to introduce with this new version; it's how we've been doing things all along.

I tend to think of the plan review as the project team telling the specification committee what they intend to do so that the specification committee members can decide whether or not they're likely to approve of the implementation of that plan (and, of course provide feedback). If the project team changes their plans, then it makes sense that they should have to engage in a new plan (or progress) review as a formal check-in with the specification committee to ensure that they're on a path that is likely to result in success. While I think that this is strongly implied, it's not explicitly stated; this feels like a good and useful addition.

If a specification project decides to change their scope, then they need to engage in a restructuring review (which requires a successful ballot of the specification committee). The requirement for a specification committee ballot is explicit in the current EFSP; the requirement for a restructuring review is explicit in the current EDP. It's probably worth bringing the two together in the EFSP.

I think it's fine to skip a Plan Review, but then some mandatory review like a Progress Review about half-way in should be required.

Extra progress reviews can be mandated explicitly in a working groups derivative process (e.g., the JESP) or, just randomly decide that a progress review is required. The EFSP already states:

The Specification Committee may, at their discretion, demand that the project team engage in additional Progress Reviews.