Guidelines for Packaging AEC Submissions

Below we outline guidelines on how to package artifacts for
submission.  We are open to possibilities that we have not considered
below; however, in cases where systems ought to fit these options, we
suggest authors use them.  In all cases, the artifacts should be
accompanied by suitable documentation, to save committee members the
burden of reverse-engineering what the authors intended (e.g., a
dataset is useless without some explanation on how to browse the data;
a tool without a quick tutorial will be very hard to use).

----------------------------------------------------------------------

CODE ARTIFACTS PACKAGING

Authors should strongly consider one of the following methods to
package the software components of their artifacts (though the AEC is
open to other reasonable formats as well):

1. A VM (Virtualbox/VMWare) image containing software application
   already setup in the intended run-time environment (e.g., Mobile
   phone emulator, Real time OS). This is the preferred option: It
   avoids installation and compatibility problems, and provides the
   best guarantees for reproducibility of the results by the
   committee.  Authors using Linux might find the CDE tool to be
   useful for automatically creating a VM image from existing software
   without needing to manually re-install all dependencies within a
   VM (http://www.stanford.edu/~pgbovine/cde.html).

2. A binary installable package. We invite the authors to use CDE
   (Linux) or MSI Installer (Windows) to package the binary
   application.

3. A live instance running on the Web.  In this case, authors should
   make a genuine effort to not learn the identity of the reviewers
   through logs.  This may mean either turning off analytics or
   creating a fresh, analytics-free instance, or only referring to
   sites with high enough usage that AEC accesses will not stand out.

4. A detailed screen-cast of the tool along with the results,
   especially if one of the following special cases applies:

- the application needs proprietary/commercial software that is not
  easily available or cannot be distributed to the committee;

- the application requires significant computation resources (e.g., > 24
  hours of execution time to produce the results);

5. An installation or update repository for the tool. (e.g., Eclipse
   update site or a Debian APT repository). However, we urge the
   authors to test their repository on standard environments to avoid
   installation problems by the committee members.

----------------------------------------------------------------------

NON-CODE ARTIFACTS FORMAT

Non-code artifacts should preferably be in open document formats. For
documents and reports, we invite the authors to use PDF, ODF, or
RTF. We invite the authors to submit experimental data and results in
CSV (preferred option), JSON, or XML file formats.
In the special case that authors have to submit non-standard data
formats, they should also provide suitable readers.

----------------------------------------------------------------------

ARTIFACTS UPLOAD

Authors should place their artifact (if necessary, archived in a
tar.gz or zip file, to produce a single downloadable artifact) either
on a personal FTP/web server or on a commercial file upload service,
such as SendSpace. In the submission, authors should mention the URL
and any credentials required to access the files.

----------------------------------------------------------------------