In order to participate in the competition, all teams need to submit the following artifacts:

1. Express your interest to participate here
2. Submit a pull request (PR) by forking Cerberus and submitting a PR. The PR must be accepted at Cerberus by the deadline (see Important Dates). Your PR should consist of the following:
   1. driver for the repair tool (see example)
   2. the driver should specify the docker image name (including the tag) to a docker image hosted at DockerHub and the hash of the image
   3. please ensure the tool follows the rules of the competition (see rules)
3. Submit a short “tool paper” via the APR-Comp submission site on EasyChair (up to 2 pages in IEEE conference format; \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf options) with following information:
   1. describing the tool, including an outline of the concepts, technology, libraries, and tool infrastructure used in the competition
   2. contact info (web page of the project, people involved in the project)
   3. information about the software project, licensing, development model, institution that hosts the software project, acknowledgement of contributors
   4. publish your tool and archive in Zenodo and reference it here (via DOI) to ensure reproducibility, also provide the URL of the project web site and repository for the source code including the build instructions for the docker image
   5. include the link to a pre-built docker image hosted at DockerHub and hash of the tool image
   6. the integration of the repair tool (i.e., the competition candidate) into the competition platform, the link to the submitted Pull Request to Cerberus
   7. the selection of competition tracks for which the submitted repair tool will compete for
   8. the denomination of a team member who will serve in the Jury Committee
   9. [if the team members are not the original authors of the tool] the clarification of why the team is participating with the tool from someone else. This clarification should include the agreement by the original author or (if the tool represents an extension of another tool) the explanation of the extension
   10. bibliographic references to more in-depth papers about the approaches used in the tool

Rebuttal Phase

At this stage results for all tools have been computed and will be made available by anonymizing participating team information. Competing teams will be given the opportunity to submit additional test cases that can prove a patch of a given tool is incorrect. Each test-case should be accompanied by an explanation, justifying the reason to add the provided test case to the validation test suite. More details of the test-case submission, will be made available during the rebuttal phase.