As a part of the tool paper evaluation, authors are also required to submit a tool artefact.

The tool artefact submissions must comply with the following guidelines:

  • Authors submit a single web link which should either point to a tool website or an archive where all required information (see below) is provided.
    • Please include the link in the Abstract submission field on EasyChair (it is not required to be included in the tool paper itself).
    • Confidentiality and privacy: The submitted materials are considered confidential. If you do not want to make the materials accessible via a public link, you can submit a link to an encrypted archive and provide the password as a part of the confidential submission.
  • The tool artefact at the provided web link must contain the following parts:
    • The tool itself, represented in one of the following formats:
      • an executable compiled for latest versions of major operating systems (Windows, macOS and Ubuntu Linux),
      • a compilable source code (with clear build instructions),
      • a preconfigured virtual machine (in the Open Virtualisation Format),
      • a link to an online service or a website (Make sure the service/website is accessible worldwide. Alternatively, provide an instance of the service that can be run locally, possibly with limited functionality (in that case, please clearly state the limitations)).
    • A plain-text file containing minimal requirements, list of dependencies (if any) and installation instructions (if any).
      • Please state some minimal expected hardware configuration and supported operating systems. This does not apply to online services/websites, in that case, please include the list of supported browsers.
    • Tool documentation.
      • The exact contents and structure are not given, but it should reflect the use cases of the tool (e.g., input/output formats for command line tools, public API description for libraries, etc.). The documentation can be also part of the tool itself (help page, hints or tutorials, etc.).
      • The documentation definitely does not have to be self-contained.
    • A plain-text file with notes for the reviewer.
      • Quick tutorial or introduction for users with minimal expertise.
      • A simple example of usage with a step-by-step guide on how to work with the example, including the expected outcome of these steps.
      • Any notes, remarks or disclaimers the reviewers might find useful.

If you have any questions or your tool does not comply with these guidelines, please do not hesitate to contact the PC co-chairs before submission.