Re: [jakarta.ee-spec.committee] Point before proceeding with changes

[David Blevins <dblevins@xxxxxxxxxxxxx>]

Agree on all points.  Specifically:

 - The vote period is not the specification project's window to finish their work
 - The "pre-review" or draft PRs should be codified as "the way" going forward


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Jul 24, 2019, at 12:35 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
> 
> And that's exactly the reason we proposed this "pre-review" process
> where the spec committee would have a chance to look at things that
> might not be completely done and give feedback to the project team
> on what was wrong, missing, etc.  Honestly, I think that's going to
> be needed for *any* spec submission, now and in the future, and so
> we ought to update our process to include that.  It seems that we've
> come to the conclusion that the spec committee should *not* be doing
> this level of review during the ballot period, and that the spec committee
> should be sure that the spec PR is complete and correct before the
> ballot even starts.
> 
> David Blevins wrote on 7/24/19 12:25 PM:
>> I don't believe we validly obtained any TCK results because they were run with non-final TCK binaries that are not the ones we will eventually vote on.
>> 
>> One of our bottlenecks is that we need to get proposed final TCK binaries that will receive no further tweaks.
>> 
>> I understand we are all thinking "finish line", but we also need to think about what example we're setting.  If NoSQL came to us and asked us to vote on their final spec and the status quo they brought to us was a TCK still being tweaked, test results from a snapshot, and thin details on their first compatible implementation, then we should tell them they haven't met the minimum requirements and are not eligible for a vote.
>> 
>> We can't do that if we ourselves break the rules.
>> 
>>