anchor.diff:  JIRA member account. You can create a member account using the https://hibernate.atlassian.net/secure/Signup!default.jspa[on-line
   registration].
   
  -If you wish to make a private challenge, you should follow the above
  -procedure, setting the Security Level to Private. Only the issue reporter,
  -TCK Project Lead and designates will be able to view the issue. Should
  -there be need for clarification or discussions before actually entering a
  -bug into the issue tracker, an email can be sent to mailto:beanvalidation-tck@redhat.com[beanvalidation-tck@redhat.com].
  -
   === 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 Specification Lead, Red Hat,
  -Inc. or his/her designate. The appellant can also monitor the process by
  +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://hibernate.atlassian.net/browse/BVTCK[BVTCK
  -Project Summary Page].
  +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?
   
  -Accepted challenges will be acknowledged via the filed issue's
  -comment section. Communication between the Jakarta Bean Validation TCK Project
  -Lead and the appellant will take place via the issue comments. The issue's
  -status will be set to "Resolved" when the TCK project lead believes the
  -issue to be resolved. The appellant should, within 30 days, either close
  -the issue if they agree, or reopen the issue if they do not believe the
  -issue to be resolved.
  +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].
   
  -Resolved issue not addressed for 30 days will be closed by the TCK
  -Project Lead. If the TCK Project Lead and appellant are unable to agree on
  -the issue resolution, it will be referred to the Jakarta Bean Validation
  -specification lead or his/her designate.
  +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.
  
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: [[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.
  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?
  
  