The Dagstuhl Artifacts Series (DARTS) publishes evaluated research data and artifacts in all areas of computer science. An artifact can be any kind of content related to computer science research, e.g., experimental data, source code, virtual machines containing a complete setup, test suites, or tools. In contrast to existing repositories for research data and artifacts like Zenodo or figshare, DARTS focuses on artifacts that underwent an evaluation process before their publication.

An artifact should be related to a research paper (which does not necessarily have to be published within a series of Dagstuhl Publishing but which should be clearly citable, e.g., by a DOI) and should help to verify the repeatability and correctness of the experiments/implementations described in the related paper.

The series is organized as a periodical consisting of one volume per year. Each volume can consist of several issues. Thereby, DARTS currently focuses on special issues that are related to a conference.

Publications
All documents published in this journal are available open access on DROPS: Browse DARTS on DROPS
 


Moreover, all papers are indexed in dblp: DARTS @ dblp

Aims and Scope

The DARTS series aims at the provision of a publication venue for evaluated research data and artifacts. An artifact can be any kind of content related to computer science research, e.g., experimental data, source code, virtual machines containing a complete setup, test suites, or tools. In contrast to existing repositories for research data and artifacts, DARTS focuses on artifacts that underwent an evaluation process before their publication.

The scope of DARTS covers all areas of computer science.


Open Access Policy
Artifacts in DARTS are peer-reviewed and are published electronically according to the principles of open access, i.e., they are available online and free of charge. Preprints (pre-review manuscripts), post prints (authors accepted manuscripts, AAM), and the version of record (VoR) can be deposited without restrictions.
License
Each artifact description is published under a Creative Commons CC BY license (http://creativecommons.org/licenses/by/4.0/).
The actual artifact is published under a Open Source license to be found in the artifact description.
The metadata provided by Dagstuhl Publishing on its webpages, as well as their export formats (such as XML or BibTeX) available at our website, is released under the CC0 1.0 Public Domain Dedication license (https://creativecommons.org/publicdomain/zero/1.0/legalcode).

Processing Charge
For DARTS, no fee is charged.

ISSN
2509-8195
Identifier
Each issue is assigned a DOI and a URN.
Each article is assigned a DOI and a URN.
To facilitate author identification, the Open Researcher and Contributor ID (ORCID) is optionally included during upload so that authors can be uniquely linked to their ORCID iD.

Longterm Preservation

Publication Ethics
Dagstuhl Publishing as a division of Schloss Dagstuhl – Leibniz-Zentrum für Informatik GmbH (LZI, or Schloss Dagstuhl for short) and its series and journals adhere to CORE practices guidance laid by COPE (Committee on Publication Ethics) and are committed to the rules of good scientific practice in accordance with the guidelines of the Leibniz Association and the German Research Foundation (DFG). We expect all parties (so authors, editors, and reviewers) involved in the publication and review process of contributions to be published in the series to follow these core practises and the guidelines. Allegations of misconduct will be investigated in accordance with the COPE Best Practice Guidelines as far as is practicable. If notified of a potential breach of publication ethics, we encourage editors and authors to inform Dagstuhl Publishing contact as soon as possible. Detailed information can be found on the Publication Ethics website.
Editorial Board

Constitution

The editorial board oversees the selection of issues to be included in DARTS. The board is monitored by the Scientific Advisory Board of Schloss Dagstuhl. In its initial configuration, the board consists of at least 2 members with a background of artifact evaluation in computer science and the scientific director of Schloss Dagstuhl or his/her representative. The editorial board may give itself rules of internal procedures.

Editorial Policy

To publish an issue in the Dagstuhl Artifacts Series (DARTS), the organizers of a conference must submit a proposal covering the following issues:

  • Information about the conference
    • Content: Topics, size of the articles, number of articles, ...
    • Peer Review: How is the peer review process organized?
    • Timeline: Coarse schedule regarding the deadline for submission, duration of the peer review process or notification deadline, respectively, deadline for submission of camera-ready documents for both research papers as well as research artifacts.
    • Proceedings: Where are the proceedings published?
  • Artifact Evaluation Process:
    • Description of the artifact evaluation process: Which parties are involved? How is the relation of the artifact evaluation committee and the regular program committee of the conference and how/when are decisions synchronized?
    • List of the artifact evaluation committee members.

The proposal will be processed by Dagstuhl's editorial office and then forwarded to the DARTS Editorial Board for a timely decision. The following decisions are possible: (1) acceptance, (2) request for revised re-submission, or (3) rejection.


Artifact Evaluation

All artifacts to be published within DARTS need to undergo some sort of systematic evaluation process, typically administered by an evaluation committee. Thereby, it should be ensured that the artifact is well documented, easy to reuse, consistent, and complete with respect to the claims made in the related research paper.
It is up to the editors of a special issue to organize the evaluation process and to provide the methodology for the evaluation. As a suggestion, the guidelines for Artifact Evaluation for Software Conferences can serve as basis. The description of the artifact evaluation process has to be publicly available and is part of the preface of the issue and of the proposal.


Templates and Example Files

Please download the current version of the DARTS style along with an example file and detailed author instructions:

darts-v2021 v2021.1.3

For older releases and an issue tracker, see our GitHub archive.


Artifact Description

Each artifact is published with a separate description which should

  • contain information of the scope of the artifact,
  • list the content of the artifact,
  • provide information about the origin of the artifact (e.g., reference to version control platforms like GitHub including a version number (if applicable)),
  • specify the platform on which the artifact has been tested (if applicable),
  • provide a reference to the license of the artifact (DARTS requires the usage of free and open source software licenses. The license of the artifact can be different from the license of the artifact description. The description is released under a Creative Commons Attribution 4.0 International license (CC BY 4.0), i.e., the authors retain their copyright. For a incomplete list of free licenses, please visit http://www.gnu.org/licenses/license-list.en.html and https://opensource.org/licenses/.),
  • provide the MD5 sum of the artifact,
  • contain the size of the artifact,
  • specify keywords,
  • provide the DOI, as well as
  • provide a reference to the related research paper.

Metadata

Each artifact is published with machine-readable metadata including the following information according to the DataCite Metadata Schema:

  • title
  • authors (The list of authors of the artifact may include people who are not authors of the related paper, but contributed to creating the artifact.)
  • keywords \ subjects
  • publisher
  • publication date
  • type (e.g., DataCite properties resourceTypeGeneral and resourceType)
  • DOI
  • identifier (e.g., DOI) of the related research paper
  • size
  • version (if applicable)
  • license

File formats

DARTS accepts any kind of data file formats for the artifacts. However, it can not guarantee continued access and preservation of obsolete or obscure formats. For that reason, open, non-proprietary and well-documented formats are highly recommended wherever possible.


FAQ
Submission

In order to satisfy the standards of our series, please note that we expect an affiliation at least to contain a city and country (for locations in the United States also the state), so we usually don't support requests asking for removing this kind of information from an affiliation.

For organizations with multiple locations please choose the location where you have been most of the time physically when carrying out this work.

We hope that our completion of affiliations according to the above criteria facilitates the contacting of authors as well as the assignment of a work to individual locations, and - last but not least - serves the harmonization of affiliations across the entire volume.

An authorized user is any person (not necessarily an author) that has the permission to edit the paper. (Mostly, the list of authorized users is similar to the list of corresponding authors.) Please note:
  • Authorized users only appear within the Submission Server as far as the processing of the paper (submission, approval) is concerned.
  • They won't appear in the metadata of the published article! (The metadata will be read from the submitted LaTeX code instead.)
  • Authorized users marked with the symbol are already registered to the system. Users without this symbol have been invited to the system but have not created a user account yet.
  • Given the above, it is not necessary to synchronize name and email of authorized users in any way with the data of actual authors. (They rather synchronize automatically with the user accounts on the Submission Server).

At the beginning of the submission process, the submission system has only limited information about the actual authors of the article. But on each upload, the metadata of the paper (including authors) are updated. Before the publication, the authorized users are asked to confirm (or revise, if necessary) the metadata. In more detail:

  • Before the first successful upload of the LaTeX sources of an article, the list of authors shows the authorized users or corresponding authors (if available).
  • After each upload, the list of authors is temporarily extracted from the LaTeX sources. Since this automatic extraction could fail or be faulty, the final authors' information is only extracted by the Dagstuhl Publishing Team during the final typesetting and imported before Author Approval. During Author Approval, you can request corrections on these data.
  • Finally (usually 3 weeks before the publication), the authors are explicitly asked to approve the extracted metadata. At this stage, minor modifications or necessary corrections are still possible.
  • No LaTeX source submitted yet? Don't worry about any errors here. Every time you upload a LaTeX source, the list will automatically be updated according to the \author macros in your file.
  • Otherwise: Simply correct the \author macros in your LaTeX file and do a re-upload. If the error persists, please make sure that the \author macros are contained in the top level of your main LaTeX file (outside \if conditionals) and contain plain data (i.e. preferably no self-defined macros).
  • Note: In any case, Dagstuhl Publishing asks you to confirm/correct the metadata before the work is officially published.

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

Please note that in the metadata form there are funding fields at the bottom of each author block as well as a general funding field at the very bottom of the form (see "Additional Metadata").

In the PDF, all of these funding fields are merged to one funding block on the title page, where the author-specific funding fields are automatically preceded by the author's name.

Important! Please do not double funding information by repeating in the general field what is already contained in the author specific ones and vice versa.

As general rule of how to distribute funding information on the different fields consider the following: If a funding is clearly assigned to an author, please use the author-specific funding block. You should only deviate from this rule if the funding block on the title page of the PDF becomes unnecessarily long due to the fact that several authors have the same funding information.

Note that there is an automatic extraction of (most of the) metadata on every upload. On editing these metadata you have to distinguish two cases:
  • The values of the grey (disabled) input fields can only be modified by editing the LaTeX source code and performing a re-upload of the paper afterwards.
  • For your convenience, the values of the white input fields (if any) can be edited directly in the corresponding web-form (no re-upload needed). We will process these changes later during the final typesetting.

Since the automatic extraction could fail or be faulty, the final version of metadata will be extracted by the Dagstuhl Publishing Team after the typesetting is done.

In any case we ask you to confirm/correct the metadata before the work is officially published!

Please note that a subject classification contained in your LaTeX file may be considered invalid if we cannot literally match an entry from the 2012 ACM Computing Classification System in a \ccsdesc{...} macro in your LaTeX file. (That can have many causes.)

To save you the trouble of a new upload, please find the "Search ACM Classifications"-input field in the upload form. There you can search for the corresponding valid classification. (By using the last part of the intended classification as a search term one usually ends up with a good pre-selection.)

Note that invalid classifications will automatically be removed from the LaTeX code during the final typesetting by Dagstuhl Publishing.

Author Approval
  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

If you click on "Save and Finish Author Approval", we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata (if necessary) AND in the LaTeX file.

In any case, even if we cannot make the requested changes, you will be informed by E-mail.


IMPORTANT! Please note that only minor corrections should be done at this stage. Here, "minor" also refers to the total number of changes. (We have already had inquiries with 50 change requests, most of them typos. Although each request is minor, the implementation is time-consuming in sum.) Requests that exceed our processing capacities and thus endanger the timely publication of the whole volume may be rejected.

As soon as some authorized user (usually you or your co-authors, if any) finishes the approval request and submits it to Dagstuhl Publishing (this happens at the end of Step 2), we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata AND in the LaTeX file.


Note that, when submitting the approval, you can decide on if you want to see the changed document again or if you consider the document as approved after the changes have been made (without a further preview).


In any case, even if we cannot make the requested changes, you will be informed by E-mail.

Publication Workflow
  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).
LaTeX Style

Here is an example of a completely filled author macro:

\author{John Q. Public}
{Institute of Pure Nonsense, Dummy University, Atlantis
 \and \url{http://www.myhomepage.edu}}
{johnqpublic@dummyuni.org}
{https://orcid.org/0000-0002-1825-0097}
{funded by the man in the moon.}

Please note:

  • Use full first and last name.
  • City and country belong to the minimum requirements on an affiliation.
  • If an author has several different affiliations, please clearly separate them with the keyword \and.
  • E-mail, ORCID, and funding are optional.
  • Author macros cannot be shared! Please use separate author macros even if two or more authors have the same affiliation!

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

  • abbreviate first names
  • in case of middle initials: use \, as illustrated in the example
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation
  • in case of overfull \hboxes: use the name of the first author and "et al."

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

  • use full first and last names
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation

This macro should be used to capture general (i.e. not author-specific) funding information.

If a funding can be clearly assigned to an author, please use the last part of the \author macro instead.

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized

We expect you to provide your DARTS artifact as a single (compressed) file. To calculate the md5-sum of this file on your local machine, please type:

  • md5 [artifact_filename] in a Linux/Mac OS terminal
  • CertUtil -hashfile [artifact_filename] MD5 in a Windows Shell

The output should be a 32 byte hex string. Use this string as argument of the mdsum-macro, e.g., \mdsum{b157da23549e1d718bb16d22ded6d941}.

Not found?

Didn't find what you are looking for? Don't hesitate to leave us a message at publishing@dagstuhl.de!

Publication Workflow

Since you are not logged in, we cannot provide any further information.


General Workflow for Editors - An Overview
  1. Initial contact (usually 6-12 months before the publication date)
    • editors initially contact Dagstuhl Publishing by E-mail not later than 6 months before the planned publication date
    • Dagstuhl Publishing invites editors to register at the Dagstuhl Submission Server

  2. Specifying the details of the issue
    Dagstuhl Publishing initializes a new issue and asks editors to specify some necessary details, e.g.
    • the schedule (Dagstuhl Publishing sets some default values that can be adapted by the editors)

  3. Invitation of Authors
    • editors import the papers from conference management software into the Submission Server
    • Submission Server guides editors through the invitation of authors to submit their camera ready-version of the artifact description and the artifact

  4. Monitoring Author Submissions (ends ≈ 6 weeks before publication)
    • editors monitor the progress of description/artifact submissions (there is an E-mail notification)
    • editors send reminders (guided by the Submission Server) in case of incomplete submissions
    • editors encourage the authors to comply with the style guidelines
    • editors write a preface and include it in a pre-generated front matter template
    • editors guarantee a handing over of the volume within the agreed deadline
    • no need to check the submitted LaTeX sources manually
    • no need to do any kind of typesetting

  5. Final Typesetting (by Dagstuhl Publishing)

  6. Approval by Authors (≈ 2 weeks before publication)
    • opportunity for authors to preview their artifact descriptions along with the extracted metadata and to ask for minor corrections

  7. Approval by Editors (≈ 1 week before publication)
    • opportunity for editors to preview the web-site of the issue on the publication server and to ask for minor corrections

  8. Official Publication of the Volume
    • includes DOI registration, registration for long-term archiving, submission to indexing services like dblp or Google Scholar
    • Dagstuhl Publishing provides HTML/XML-metadata, e.g., for use in conference web-page

Front Matter

Each issue in the Dagstuhl Artifacts Series (DARTS) has a preface written by the chairs of the artifact evaluation committee that describes the artifact evaluation process. This description is also an essential part of the proposal.


Front Matter Template and Example Files

Please download the current version of the DARTS front matter style along with an example file:

dartsmaster-v2021 v2021.1.3

Since you are not logged in, we cannot provide any further information.

FAQ
Submission

In order to satisfy the standards of our series, please note that we expect an affiliation at least to contain a city and country (for locations in the United States also the state), so we usually don't support requests asking for removing this kind of information from an affiliation.

For organizations with multiple locations please choose the location where you have been most of the time physically when carrying out this work.

We hope that our completion of affiliations according to the above criteria facilitates the contacting of authors as well as the assignment of a work to individual locations, and - last but not least - serves the harmonization of affiliations across the entire volume.

An authorized user is any person (not necessarily an author) that has the permission to edit the paper. (Mostly, the list of authorized users is similar to the list of corresponding authors.) Please note:
  • Authorized users only appear within the Submission Server as far as the processing of the paper (submission, approval) is concerned.
  • They won't appear in the metadata of the published article! (The metadata will be read from the submitted LaTeX code instead.)
  • Authorized users marked with the symbol are already registered to the system. Users without this symbol have been invited to the system but have not created a user account yet.
  • Given the above, it is not necessary to synchronize name and email of authorized users in any way with the data of actual authors. (They rather synchronize automatically with the user accounts on the Submission Server).

At the beginning of the submission process, the submission system has only limited information about the actual authors of the article. But on each upload, the metadata of the paper (including authors) are updated. Before the publication, the authorized users are asked to confirm (or revise, if necessary) the metadata. In more detail:

  • Before the first successful upload of the LaTeX sources of an article, the list of authors shows the authorized users or corresponding authors (if available).
  • After each upload, the list of authors is temporarily extracted from the LaTeX sources. Since this automatic extraction could fail or be faulty, the final authors' information is only extracted by the Dagstuhl Publishing Team during the final typesetting and imported before Author Approval. During Author Approval, you can request corrections on these data.
  • Finally (usually 3 weeks before the publication), the authors are explicitly asked to approve the extracted metadata. At this stage, minor modifications or necessary corrections are still possible.
  • No LaTeX source submitted yet? Don't worry about any errors here. Every time you upload a LaTeX source, the list will automatically be updated according to the \author macros in your file.
  • Otherwise: Simply correct the \author macros in your LaTeX file and do a re-upload. If the error persists, please make sure that the \author macros are contained in the top level of your main LaTeX file (outside \if conditionals) and contain plain data (i.e. preferably no self-defined macros).
  • Note: In any case, Dagstuhl Publishing asks you to confirm/correct the metadata before the work is officially published.

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.
Note that there is an automatic extraction of (most of the) metadata on every upload. On editing these metadata you have to distinguish two cases:
  • The values of the grey (disabled) input fields can only be modified by editing the LaTeX source code and performing a re-upload of the paper afterwards.
  • For your convenience, the values of the white input fields (if any) can be edited directly in the corresponding web-form (no re-upload needed). We will process these changes later during the final typesetting.

Since the automatic extraction could fail or be faulty, the final version of metadata will be extracted by the Dagstuhl Publishing Team after the typesetting is done.

In any case we ask you to confirm/correct the metadata before the work is officially published!

Please note that a subject classification contained in your LaTeX file may be considered invalid if we cannot literally match an entry from the 2012 ACM Computing Classification System in a \ccsdesc{...} macro in your LaTeX file. (That can have many causes.)

To save you the trouble of a new upload, please find the "Search ACM Classifications"-input field in the upload form. There you can search for the corresponding valid classification. (By using the last part of the intended classification as a search term one usually ends up with a good pre-selection.)

Note that invalid classifications will automatically be removed from the LaTeX code during the final typesetting by Dagstuhl Publishing.

Author Approval
  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

If you click on "Save and Finish Author Approval", we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata (if necessary) AND in the LaTeX file.

In any case, even if we cannot make the requested changes, you will be informed by E-mail.


IMPORTANT! Please note that only minor corrections should be done at this stage. Here, "minor" also refers to the total number of changes. (We have already had inquiries with 50 change requests, most of them typos. Although each request is minor, the implementation is time-consuming in sum.) Requests that exceed our processing capacities and thus endanger the timely publication of the whole volume may be rejected.

As soon as some authorized user (usually you or your co-authors, if any) finishes the approval request and submits it to Dagstuhl Publishing (this happens at the end of Step 2), we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata AND in the LaTeX file.


Note that, when submitting the approval, you can decide on if you want to see the changed document again or if you consider the document as approved after the changes have been made (without a further preview).


In any case, even if we cannot make the requested changes, you will be informed by E-mail.

Publication Workflow
  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).
Before the volume is officially published, Dagstuhl Publishing...
  • creates a web-portal on the Dagstuhl Publication Server DROPS and communicates the link to the editors
  • provides a detailed change-log for all papers
  • asks the editors to resolve open issues that could not be clarified during the author approval (if any)
  • waits for an explicit approval of the editors to expose the web-portal to the public

The editors check everything carefully and ask for minor changes, if necessary.

When approved, the volume will be officially published.

First note that there are no automatic actions triggered when the editor submission deadline has passed! You actually decide on when to hand over the volume to Dagstuhl Publishing. (However, if you miss the deadline, we cannot guarantee a timely publication.)

Your tasks here are:

  • checking for completeness and remind delayed authors on submitting their papers
  • checking the order of papers (re-ordering, if necessary)
  • checking for/setting the correct paper categories (e.g. Invited Talk, Extended Abstract, ...)
  • writing a preface and including it into the pre-generated front matter provided by the Submission System
  • handing over the volume at the specified date (editor submission deadline) to Dagstuhl Publishing
  • no need to edit LaTeX sources submitted by the authors manually (although the possibility is given)

First note that the specified author submission deadline does not automatically trigger any actions (like closing the submission). However, it is the deadline communicated to the authors in E-mails generated by the system. Actually, you decide on when to close the submission manually.

The editor's tasks during paper submission are:

  • editors monitor the progress of paper submissions (there is an E-mail notification)
  • editors send reminders (guided by the Submission Server) in case of incomplete submissions
  • editors check the page limits (if any) and encourage the authors to comply with the style guidelines
  • editors write a preface and include it in a pre-generated front matter template
  • editors guarantee a handing over of the volume within the agreed deadline
  • no need to check the submitted LaTeX sources manually (there are some automatic checks on upload)
  • no need to do any kind of typesetting
LaTeX Style

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

  • abbreviate first names
  • in case of middle initials: use \, as illustrated in the example
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation
  • in case of overfull \hboxes: use the name of the first author and "et al."

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

  • use full first and last names
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation

This macro should be used to capture general (i.e. not author-specific) funding information.

If a funding can be clearly assigned to an author, please use the last part of the \author macro instead.

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized

We expect you to provide your DARTS artifact as a single (compressed) file. To calculate the md5-sum of this file on your local machine, please type:

  • md5 [artifact_filename] in a Linux/Mac OS terminal
  • CertUtil -hashfile [artifact_filename] MD5 in a Windows Shell

The output should be a 32 byte hex string. Use this string as argument of the mdsum-macro, e.g., \mdsum{b157da23549e1d718bb16d22ded6d941}.

Not found?

Didn't find what you are looking for? Don't hesitate to leave us message at publishing@dagstuhl.de!

Recently published volumes
  • DARTS, Vol. 10, Issue 2, Special Issue of the 38th European Conference on Object-Oriented Programming (ECOOP 2024)
    Karine Even-Mendoza and Raphaël Monat
  • DARTS, Vol. 10, Issue 1, Special Issue of the 36th Euromicro Conference on Real-Time Systems (ECRTS 2024)
    Matthias Becker and Catherine E. Nemitz
  • DARTS, Vol. 9, Issue 2, Special Issue of the 37th European Conference on Object-Oriented Programming (ECOOP 2023)
    Hernán Ponce de León and Stefan Winter
  • DARTS, Vol. 9, Issue 1, Special Issue of the 35th Euromicro Conference on Real-Time Systems (ECRTS 2023)
    Matthias Becker and Julien Forget
  • DARTS, Vol. 8, Issue 1, Special Issue of the 34th Euromicro Conference on Real-Time Systems (ECRTS 2022)
    Angeliki Kritikakou and Matthias Becker
  • DARTS, Vol. 8, Issue 2, Special Issue of the 36th European Conference on Object-Oriented Programming (ECOOP 2022)
    Alessandra Gorla and Stefan Winter
  • DARTS, Vol. 7, Issue 2, Special Issue of the 35th European Conference on Object-Oriented Programming (ECOOP 2021)
    William G. J. Halfond and Quentin Stiévenart
  • DARTS, Vol. 7, Issue 1, Special Issue of the 33rd Euromicro Conference on Real-Time Systems (ECRTS 2021)
    Alessandro Biondi and Angeliki Kritikakou
  • DARTS, Vol. 6, Issue 2, Special Issue of the 34th European Conference on Object-Oriented Programming (ECOOP 2020)
    Lisa Nguyen Quang Do and Manuel Rigger
  • DARTS, Vol. 6, Issue 1, Special Issue of the 32nd Euromicro Conference on Real-Time Systems (ECRTS 2020)
    Alessandro V. Papadopoulos and Alessandro Biondi
  • DARTS, Vol. 5, Issue 2, Special Issue of the 33rd European Conference on Object-Oriented Programming (ECOOP 2019)
    Maria Christakis and Manuel Rigger
  • DARTS, Vol. 5, Issue 1, Special Issue of the 31st Euromicro Conference on Real-Time Systems (ECRTS 2019)
    Sophie Quinton, Sebastian Altmeyer, and Alessandro Papadopoulos
  • DARTS, Vol. 4, Issue 3, Special Issue of the 32nd European Conference on Object-Oriented Programming (ECOOP 2018)
    Maria Christakis, Philipp Haller, and Marianna Rapoport
  • DARTS, Vol. 4, Issue 2, Special Issue of the 30th Euromicro Conference on Real-Time Systems (ECRTS 2018)
    Sebastian Altmayer and Martina Maggio
  • DARTS, Vol. 4, Issue 1, Special Issue of the 13th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 2018)
    Philipp Haller, Michael Pradel, and Tijs van der Storm
  • DARTS, Vol. 3, Issue 2, Special Issue of the 31st European Conference on Object-Oriented Programming (ECOOP 2017)
    Philipp Haller, Michael Pradel, and Tijs van der Storm
  • DARTS, Vol. 3, Issue 1, Special Issue of the 12th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 2017)
    Javier Cámara, Bashar Nuseibeh, and David Garlan
  • DARTS, Vol. 1, Issue 1, Special Issue of the 29th European Conference on Object-Oriented Programming (ECOOP 2015)
    Camil Demetrescu
  • DARTS, Vol. 2, Issue 1, Special Issue of the 30th European Conference on Object-Oriented Programming (ECOOP 2016)
    Matthew Flatt and Tijs van der Storm
Contact Dagstuhl Publishing
Dagstuhl Publishing Team