ACM SIGCOMM 2023 Call for Artifacts
The SIGCOMM 2023 conference’s artifact evaluation process is open to accepted papers at the SIGCOMM 2023 conference. Artifact evaluation intends to publicly recognize authors’ efforts to make the data, hardware, software, survey results, proofs, models, test suites, benchmarks, and other artifacts associated with a paper available for other researchers’ use, as well as to help improve those artifacts before their broader distribution.
July 13, 2023
Announcement of Call for Artifact
August 11, 2023August 18, 2023
Artifact submission deadline
August 25, 2023
Decisions notification of the “artifacts available” award
September 10-14, 2023
SIGCOMM 2023 conference
October 10 - November 10, 2023
Authors answering AEC evaluation committee questions
December 5-8, 2023
Announce the full artifact evaluation results during the CoNEXT 2023 conference
Artifact Evaluation Committee
- Committee Co-Chairs
Massachusetts Institute of Technology
University of Southern California
Anny Xijia Zheng
Cesar A. Stuardo
Cha Hwan Song
National university of Singapore
Beijing University of Posts and Telecommunications
Ish Kumar Jain
University of California San Diego
City University of Hong Kong
University of Pennsylvania
Institut for Internet Security
University of Southern California
City University of Hong Kong
Technical University of Munich
Carnegie Mellon University
Hewlett Packard Labs
Federal University of Paraná
Nanyang Technological University
Renmin University of China
The Ohio State University
University of Michigan
Artifact Review and Badging
At artifact submission time, the authors will choose the criteria by which their artifacts will be evaluated. Based on ACM’s guidelines (https://www.acm.org/publications/policies/artifact-review-and-badging-current), the SIGCOMM 2023 conference will award two separate badges to a paper. An artifact can meet the criteria of one or both of the following badges:
- Artifacts Available: To earn this badge, the AEC must judge that the artifacts associated with the paper have been made available for retrieval, permanently and publicly. Valid hosting options include publisher repositories (ACM Digital Library), institutional repositories or open commercial repositories (e.g., GitHub, GitLab, FigShare, Dryad), not personal webpages. Other than making the artifacts available, this badge does not mandate any further requirements on functionality, correctness, or documentation.
- Artifacts Evaluated - Functional: To earn this badge, the AEC must judge that the artifacts conform to the expectations set by the paper in terms of functionality, usability, and relevance. The AEC will consider four aspects of the artifacts.
- Documented: are the artifacts sufficiently documented to enable them to be exercised by readers of the paper?
- Consistent: are the artifacts relevant to the associated paper?
- Complete: do the submitted artifacts include all of the key components described in the paper?
- Exercisable: do the submitted artifacts include the scripts and data needed to run the experiments described in the paper, and can the software be successfully executed?
When the AEC judges that an artifact meets the criteria for one or both of the badges listed above, those badges will appear on the final version of the associated paper. In addition, the authors of the paper will be encouraged to add an Artifact Appendix of up to two pages to their publication. The goal of the appendix is to describe and document the artifact in a standard format.
Review and Anonymity
Artifact evaluation is "single-blind." The identities of artifact authors will be known to members of the AEC, but authors will not know which members of the AEC have reviewed their artifacts.
To maintain the anonymity of artifact evaluators, the authors of artifacts should not embed any analytics or other tracking in the websites for their artifacts for the duration of the artifact-evaluation period. This is important to maintain the confidentiality of the evaluators. In cases where tracing is unavoidable, authors should notify the AEC chairs in advance so that AEC members can take adequate safeguards.
At the same time, though the authors are visible to AEC, the submission of an artifact does not give the AEC permission to make its content public. AEC members may not publicize any part of your artifact during or after completing the evaluation, nor may they retain any part of it after evaluation. Thus, you are free to include models, data files, proprietary binaries, etc. in your artifact. Participating in artifact evaluation does not require you to later publish your artifacts (although it is encouraged).
The SIGCOMM 2023 conference’s artifact evaluation welcomes submissions from all accepted papers. Authors of the accepted paper can submit their artifact via the artifact SIGCOMM23AE submission site https://sigcomm23ae.hotcrp.com/.
The AEC will accept any kind of digital artifact that authors wish to submit: software, data sets, survey results, test suites, mechanized proofs, etc. Physical objects, e.g., computer hardware, cannot be accepted due to the difficulty of making the objects available to members of the AEC. (If your artifact requires special hardware, consider if/how you can make it available to evaluators online.)
A complete artifact package must contain:
- the accepted version of your SIGCOMM paper,
- the artifact itself, and
- a "README" or documentation that describes how the submitted artifact can be exercised.
For the submitted artifact, we recommend the authors to consider (one, or multiple, but not limited to) the following methods to package their artifacts:
- Source code: If your artifact has few dependencies and can be installed easily on several operating systems, you may submit source code and build scripts. However, if your artifact has a long list of dependencies, please use one of the other formats below.
Virtual machine/container: A virtual machine or Docker
image containing the software application already set up with the right
toolchain and intended runtime environment. For example:
- For raw data, the VM would contain the data and the scripts used to analyze it.
- For a mobile phone application, the VM would have a phone emulator installed.
- For mechanized proofs, the VM would contain the right version of the relevant theorem prover. We recommend using a format that is easy for AEC members to work with, such as OVF or Docker images..
- Binary installer: Indicate exactly which platform and other run-time dependencies your artifact requires.
- Live instance on the web: Ensure that it is available for the duration of the artifact evaluation process.
- Internet-accessible hardware: If your artifact requires special hardware, or if your artifact is actually a piece of hardware, please make sure that AEC members can somehow access the device. VPN-based access to the device might be an option.
Screencast: A detailed screencast of the tool along with
the results, especially if one of the following special cases applies:
- The artifact needs proprietary/commercial software or proprietary data that is not easily available or cannot be distributed to the AEC.
- The artifact requires significant computation resources (e.g., more than 24 hours of execution time to produce the results) or requires huge data sets.
- The artifact requires specific hardware or software that is not generally available in a typical lab and where no access can be provided in a reasonable way.
Artifact Metadata and Conflicts
We define conflict of interest with an AEC member using the following principles:
- You are currently employed at the same institution, have been previously employed at the same institution within the last 12 months, or are going to begin employment at the same institution.
You have a professional partnership as follows:
- Past or present association as thesis advisor or advisee.
- Collaboration on a project, publication, or grant proposal within the past 2 years (i.e., 2021 or later).
The AEC chairs and members will review conflicts to ensure the integrity of the reviewing process, adding or removing conflicts where necessary and sanity-checking cases where conflicts do not appear justified. Improperly identifying AEC members as a conflict to avoid individual reviewers may lead to your artifact submission being rejected. If you have concerns, please contact the AEC chairs.
Artifact with Malicious Operations
Some artifacts may attempt to perform malicious or destructive operations by design. These cases should be boldly and explicitly flagged in detail in the README so the AEC can take appropriate precautions before installing and running these artifacts. Please contact AEC co-chairs if you believe that your artifacts fall into this category.
There are several sources of good advice about preparing artifacts for evaluation. These two are particularly noteworthy:
- HOWTO for AEC Submitters, by Dan Borowy, Charlie Cursinger, Emma Tosch, John Vilk, and Emery Berger
- Artifact Evaluation: Tips for Authors, by Rohan Padhye
If you have any questions about how best to package your artifact, contact the artifact evaluation committee co-chairs.