anchor.diff:  [[appeals-process]]
   == Appeals Process
   
  -While the Jakarta Bean Validation TCK is rigorous about enforcing an
  -implementation's conformance to the Jakarta Bean Validation specification, it's
  -reasonable to assume that an implementor may discover new and/or better ways
  -to validate the assertions. This chapter covers the appeals process, defined
  -by the Specification Lead, Red Hat, Inc., which allows implementors of the
  -Jakarta Bean Validation specification to challenge one or more tests defined by the
  -Jakarta Bean Validation TCK.
  -
  -The appeals process identifies who can make challenges to the TCK,
  -what challenges to the TCK may be submitted, how these challenges are
  -submitted, how and by whom challenges are addressed and how accepted
  -challenges to the TCK are managed.
  -
  -Following the recent adoption of transparency in the JCP, implementors
  -are encouraged to make their appeals public, which this process facilitates.
  -The JCP community should recognize that issue reports are a central aspect
  -of any good software and it's only natural to point out shortcomings and
  -strive to make improvements. Despite this good faith, not all implementors
  -will be comfortable with a public appeals process. Instructions about how to
  -make a private appeal are therefore provided.
  -
  -=== Who can make challenges to the TCK?
  -
  -Any implementor may submit an appeal to challenge one or more tests
  -in the Jakarta Bean Validation TCK. In fact, members of the Jakarta Bean Validation
  -Expert Group (EG) encourage this level of participation.
  +While the Jakarta Bean Validation TCK is rigorous about enforcing an implementation's conformance to the Jakarta Bean Validation specification,
  +it's reasonable to assume that an implementor may discover new and/or better ways to validate the assertions.
  +The appeals process is defined by the Jakarta EE https://github.com/jakartaee/specification-committee/blob/master/process.adoc[Jakarta EE TCK Process 1.0].
   
   === What challenges to the TCK may be submitted?
   
  
positive.code: What is generally not challengeable are the assertions made by the
  specification. The specification document is controlled by a separate
  process and challenges to it should be handled through the Jakarta Bean Validation EG
  by sending an e-mail to mailto:beanvalidation-tck@redhat.com[beanvalidation-tck@redhat.com].
  
  === How these challenges are submitted?
  
  
negative.code: JIRA member account. You can create a member account using the https://hibernate.atlassian.net/secure/Signup!default.jspa[on-line
  registration].
  
  === How and by whom challenges are addressed?
  
  The challenges will be addressed in a timely fashion by the Bean Validation TCK Project Lead,
  as designated by the Specification Lead, Red Hat Inc., or his/her designate.
  The appellant can also monitor the process by
  watching the issue filed against https://hibernate.atlassian.net/browse/BVTCK[BVTCK].
  
  The current TCK Project Lead is listed on the https://jakarta.ee/specifications/bean-validation[Bean Validation Project Summary Page] on Jakarta EE.
  
  === How accepted challenges to the TCK are managed?
  
  The workflow for TCK challenges is outlined in the https://github.com/jakartaee/specification-committee/blob/master/process.adoc[Jakarta EE TCK Process 1.0].
  
  Periodically, an updated TCK will be released, containing tests altered due to challenges - no new tests will be added.
  Implementations are required to pass the updated TCK.
  This release stream is named 2.0.x, where x will be incremented.
  
  Additionally, new tests will be added to the TCK improving coverage of the specification.
  We encourage implementations to pass this TCK, however it is not required. This release stream is named 2.y.z where y &gt;= 1.
  