Wayne Beaton wrote on 4/18/19 1:28 PM:
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.
Just so I'm clear... The PMC and the Spec Committee will be casting
their votes during that one week review period, and at the end of
that period the votes will be tallied and the approval/rejection of
the review will be assessed, right?
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.
Will the EMO assess whether there are sufficient members of the
project who meet this criterion, including a Project Lead, before
allowing the review to start? I wouldn't want to start a review
that might fail at the end for this reason.
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.
I'm assuming the "specification" will be delivered similarly to how
we've done it with the JCP - a zip file containing the html files
for the javadocs, and an (optional?) specification document in html
or pdf format.
We'll ask the Webmaster to create separate Git
repositories in each Specification Project specifically
for the Specification Document.
Good!
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.
Does the one week of community review overlap the end of the 30
ballot?
I assume these reviews again need to be scheduled so that the end
aligns on a first or third Wednesday, right?
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.
How are we going to pick which projects are reviewed when, and cause
the Project Leads to prepare their materials at that time? Aren't
we pretty much at the mercy of the Project Leads as to when they're
ready for review?
I forget, do we have criteria somewhere for what we'd like to see
for a Progress 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).
They don't share a TCK. They share a TCK source code repository.
Most of the TCKs are independent.
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.
Which brings us back to the meta-question...
Which parts of the JESP are rules for which there can be no
exceptions, and which parts are guidelines for which there can be
exceptions?
|
