Re: [jakarta.ee-spec.committee] The process to create the first set of F

[Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Apr 19, 2019 at 2:33 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

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?

Yes.

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.

Short answer: yes.

Longer answer: The specification committee and PMC can have a say in this and I will seek their advice. FWIW, assuming that we get the rest of the member paperwork, I don't think that we're going to end up having to drop very many committers.

I always try very hard to set up reviews for success. 

 

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.

That seems reasonable to me. But, it's really up to the specification committee. We need to make sure that this is in our list of topics that need to be addressed.

 

Does the one week of community review overlap the end of the 30 ballot?

Short version: yes.

Longer version: This is my strong preference. Serializing them will add even more time to the process. If the specification committee feels strongly that they should be serialized, then we can explore that...

 

I assume these reviews again need to be scheduled so that the end aligns on a first or third Wednesday, right?

Short version: yes.

Longer version: That is the pattern that we've established. The actual rule that I am compelled to follow is that we run two review periods each month. After being very dynamic about scheduling for a while, we zeroed on a very predictable "first and third Wednesday" model. If there's some reason to reconsider this model, we can engage in that discussion. If we have to do a review out of cycle, we can make it work, but that has to be an exception and not the rule.

 

How are we going to pick which projects are reviewed when, and cause the Project Leads to prepare their materials at that time? 

My recommendation is that we ask the project leads do the work and jump when the first five are ready. The PMC has taken ownership of facilitating the process.

 

Aren't we pretty much at the mercy of the Project Leads as to when they're ready for review?

Yup. Mostly. There's a lot of cat herding in open source.

 

I forget, do we have criteria somewhere for what we'd like to see for a Progress Review?

The EMO's minimum criteria for a review is a coherent executive summary and clean IP check. It's up to the PMC and specification committee to determine what more they need to see in order to cast a positive vote. 

 

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.

Does this fact change anything about my assertion?

 

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?

The IP Policy, terms of licenses, and fundamental principles of the process must be preserved. As a general rule, it is IMHO reasonable to consider an exception for anything that is "process for the sake of process". The more that I think about it, I'm inclined to also ask the specification committee to approve the exception.

HTH,

Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.