Spec Committee 74: TCK Challenge Acceptance#726
Conversation
Signed-off-by: Andrew Pielage <andrew.pielage@azul.com>
|
|
||
| This specification allows for lazy consensus as a resolution path for TCK test challenges as described in the Jakarta EE TCK Process Guide. For this specification, test challenges will be deemed accepted 14 days from the date the test challenge issue is last commented on by a specification team committer, or 14 days from the date of filing if no comments are made by a specification team committer. | ||
|
|
||
| If any specification team member determines that the challenge requires review it should be marked with the tag <challenge-review> and it will be resolved under the 'Active Resolution' process as described in the Jakarta EE TCK Process guide. Generally, once a conversation occurs with a member of the committer team, the filer should consider that the challenge will follow the Active Resolution process. |
There was a problem hiding this comment.
Lazy consensus makes sense to me, but this particular paragraph doesn't. The first sentence suggests using the challenge-review label, but the second sentence says that if a conversation occurs with a commiter, active resolution should be expected. Which further contradicts the previous paragraph, which says that lazy consensus "activates" 14 days after last comment by a committer. How about we just drop this paragraph entirely?
There was a problem hiding this comment.
I was taking this from the drafted "templates" that should've been sent out to the spec leads ages ago.
Feel free to adjust!
Original proposal email from the spec committee mailing list: https://www.eclipse.org/lists/jakarta.ee-spec.committee/msg03564.html
There was a problem hiding this comment.
The text also talks about committer members commenting, but the original appeals process specifically mentioned the TCK Lead handling challenges - I don't know which way you want it
|
As an aside, this appeals page specifies TCK Process 1.0, but links to the most recent 1.4.2. |
As per jakartaee/specification-committee#74 and jakartaee/platform#1057.
Specifications should list whether or not they are only using Active Resolution or also allowing Lazy Consensus.
Here is a draft for adding lazy consensus.