Change the requirement for progress reviews

[waynebeaton]

Requiring that every development cycle have at least one progress review and finish with a release review adds a significant amount of time to the process that makes it difficult to evolve a specification rapidly. Rather than require a minimum number of progress reviews, let's consider making it more time based.

e.g., a specification project must engage in a Progress Review at least every six months while engaged in active development (after the completion of a Creation Review or Plan Review; and before the Release Review). This needs to be worded better.

[bshannon]

I would suggest:
A specification project must engage in at least one Check Point Review every 12 months.

[waynebeaton]

Some specification projects will be dormant for extended periods of time. If a specification project is not actively developing, is there any value in a review at all?

We used to have a notion of Continuation Review in the EDP. The idea was that you had to engage in a review at least once per year and--if a project is dormant--prove that the project deserves to continue to exist. In practice, making project teams actually engage in these required a lot of work that just upset folks.

We have a requirement that a specification project engage in a Plan Review at the beginning of each development cycle (or a Creation Review when they're just getting started). I'm thinking that successful completion of that Creation or Plan Review indicates that the project is active and sets the count-down for the first Progress Review. Successful completion of the Progress Review resets the count-down for the next Progress Review (recursive). The process is halted by a successful Release Review.

Theoretically, the period could be tuned by a Working Group. 12 months is the default, but a Working Group could make the period shorter.

[bshannon]

I'm not sure "while engaged in active development" is well defined. It's not mentioned in the EDP.
I guess it's the period between a Plan Review and a Release Review? (Although there's no Plan
Review in the EDP either.) I just wouldn't want a spec project to delay the Plan Review until they
were almost ready for release just to avoid the need for Progress Reviews.

How about:
After a successful Plan Review, and until a successful Release Review, a specification project must
engage in at least one Check Point Review every 12 months.

Maybe we need to defined what's allowed or expected to happen or not happen between a Release
Review and a Plan Review? Is no development allowed? Is maintenance allowed? (And how do
you define "maintenance" for a spec?) Is research and experimentation for the next version of the
spec allowed?

And yes, we need to be explicit about whether a Working Group can change "12 months" to
something else, whether there's any limits on what they can change it to, and whether they can
remove the requirement entirely.

[waynebeaton]

I agree that "active development" is not defined. This is why I'm trying to work in the Plan and Release Reviews as bookends. We could also make the first commit after a successful Release Review start the count-down, but this feels cumbersome.

After a successful Plan Review, and until a successful Release Review, a specification project must
engage in at least one Check Point Review every 12 months.

I believe that this captures the gist of what I'm thinking. Thanks.

Maintenance would result in a Service Release. The EFDP states this:

A Service Release includes only minor changes and/or clarifications over a Major or Minor Release. Specifically, a Service Release must not include any significant new features and/or breaking changes. A Specification Team may consult with their PMC and Specification Committee to determine precisely what constitutes a minor change and/or clarification.

Anything more than "minor changes and/or clarifications" requires a full cycle of development starting with a Plan Review.