Submission guidelines

Project statements for peer review

Project teams are asked to submit a “project statement” that will be used by the reviewers. Reviewers will take into consideration both the project statement and the actual project.  The project statement should describe how the project contributes to its field(s) and in what ways the digital methods and modes of presentation address larger academic issues. Some elements which may be included:

  • A brief history of the project, its aims and objectives
  • A review of related projects
  • The project’s contributions to its disciplinary fields
  • The project’s methodology and timeline
  • A comparison of the project’s expected and current outcomes
  • Issues related to the technical documentation and, when possible and relevant, direct access to code for reviewers
  • Reference to use of best practices and standards (for example, for coding, design, digitization of images, markup or metadata)
  • The intended audience for this project
  • The process for selection of material
  • The project’s current status (e.g. in development, completed)
  • Issues related to sustainability and preservation.  For example, where is the project hosted and what is the evidence of ongoing commitment? What will happen with the project in the mid- and long-term future? Where will the data be stored?
  • Previous peer review of the project (e.g. editorial board, selection committee, grant funding, reviewers of initial project)
  • Project citation guidelines and/or persistent identifiers
  • Intellectual property and copyright (permission for use of materials for project as well as clearly stated uses of project material). Under which licences will the outcomes of the project (data, publications) be published?
  • Issues related to interoperability if applicable (use of standards, web services, etc.)

Project statements can be submitted as a Word document (.doc or .docx) or as plain text, with supplemental image files.

The DHCommons Journal follows the guidelines laid out by Digital Humanities Quarterly for bibliographic formatting.

Submission process

  1. First, log into or create an account on DHCommons (this site).
  2. Add your project to the DHCommons project directory, or make sure that your project's profile is up-to-date.
  3. Submit your project for review. Before you fill out this form, make sure that:
    • You have written a project statement, following the guidelines above. You can submit the project statement as plain text (using the "supplemental files" upload to include any figures), or as a Word file (doc or docx).
    • Any co-authors also have created accounts on DHCommons, and you know what their DHCommons user name is. You will need to reference them using their user name.
    • You have written up information about how reviewers can access the project, if it is not fully public (e.g. any URLs, usernames and passwords they should use).

Review process

Preliminary review

Submissions are first given a preliminary review, to ensure that they meet the guidelines for the DHCommons journal. Preliminary reviews address the following issues:

  • Is the project, as described, a mid-stage project? Mid-stage projects as defined by DHCommons are those "that have moved well beyond the planning stage and have made concrete advances without having necessarily completed the project".
  • Does this submission clearly address how the project has contributed to its academic field?
  • Does this submission include sufficient technical detail about how the project was implemented?
  • Is the structure of the project statement appropriate for DHCommons?
  • Is the project statement written in a style clearly distinct from a grant proposal?

At this stage, reviewers indicate that a submission should be accepted for peer review, revised and resubmitted by the author, or rejected for the journal.

Authors will be contacted when the preliminary review of their submission is complete, and they will be able to access reviewers' comments on their submission page. These comments will only be visible to the primary author, the preliminary reviewers, and the journal staff.

Peer review

Projects that are accepted for review will be matched with a content reviewer and a technical reviewer, who will each evaluate different aspects of the project. Reviewers write prose that will be published alongside the project statement, and may write additional private comments for the author.

Reviewers address the following issues:

  • Contribution: Please consider the overall field contribution of the project, paying special attention to gains made following the initial funding period (if applicable). We are particularly interested in how digital methods and modes of presentation offer new ways to address ongoing scholarly conversations or contribute to to Digital Humanities methodology.
  • Presentation: Please examine the project’s methodological and scholarly aims from a more disciplinary perspective. As much as possible, we want to move from thinking in terms of a form/content divide toward a full consideration of the digital project as purpose-built scholarship. In other words, the digital in digital humanities scholarship should make clear and critical interventions into important field topics, rather than simply being a mode of delivery. Issues include: 1) Does the interface effectively communicate and facilitate the goals, purpose, and argument of the project? 2) How do the design and content elements of the project interact and integrate with one another? 3) Discuss usability of the interface(s) from the perspective of a reader/researcher; if possible, also discuss usability from the perspective of current user experience best practices.
  • Preservation: Preservation can mean a number of different practices in a digital context. From long-term data storage to continued frontend browser optimization, the one thing that unifies preservation as a category is human commitment to upkeep and best practices. Preservation may be addressed in different ways depending on the short or long term goals of the project.

If the peer review process surfaces significant weaknesses in a project, reviewers may recommend that the review and statement not be published in the DHCommons journal, and instead be provided privately to the author. In such a situation, the author is encouraged to revise their project and/or project statement and re-submit. Re-submissions of this type will be given priority for publication.

"How Did They Make That?" submissions

DHCommons Journal seeks procedural descriptions of how to launch and/or maintain an exemplary aspect of a stable digital project for potential publication in its second issue. We encourage you to emphasize in your submission a component of the project that came out particularly well and/or represented a significant challenge (e.g. data visualization, accessibility compliance, data cleaning and preparation). Readers should be able to come away with a sense of how they could begin to tackle a similar challenge. In spirit, these submissions should be inspired by Miriam Posner’s “How did they make that?”

DHCommons will publish 1-3 procedural descriptions in each issue of DHCommons Journal. Submissions should be between 600-1000 words in length. Illustrative images are strongly encouraged. Submissions must correspond to digital projects that are publicly available. All submissions will be peer reviewed. 

Authors of accepted submissions will be asked to participate in an interview about their project that will be published alongside their piece. The interview will provide an opportunity to describe the project aspect and the project as a whole in more depth. Attempts will be made to select submissions in line with the theme of the overall issue, digital diversity. DHCommons Journal's concept of “diversity”  includes diversity in project language, staff, academic subject, or goals, among other possibilities. DHCommons Journal invites submissions in a wide variety of languages. DHCommons Journal has an International Advisory Board and will work with authors to find reviewers in the language of submission whenever possible.

Examples of previously published work:

Fred Gibbs, "Editorial Sustainability and Open Peer Review at Programming Historian"
Caitlin Christian-Lamb and Sara Sikes, "How Did They Make That: The Adams Timeline"

Submissions are due April 1, 2016

Submission Guidelines

Your submission should address each of the points below:

  • Timeframe from conception to implementation
  • Technical skills needed
  • Competencies needed (e.g. project management, data management, etc.)
  • Infrastructure needed
  • Funding needed, if any
  • Pointers to resources that build required skills and competencies (e.g. relevant blog posts, Programming Historian lessons, etc.)

Submission Process

Review Process

Reviewers will evaluate the clarity and completeness with which authors describe their projects.

Questions include:

  • Will the procedural description be readily accessible to readers with novice as well as advanced digital project experience?
  • Does the author effectively communicate competencies and skills required to deliver the digital project?
  • Does the author effectively describe the technologies underlying the digital project?


All inquiries should be directed to Section Editor, Thomas Padilla.

Thomas Padilla, Section Editor,
Miriam Posner, Contributing Editor
Trip Kirkpatrick, Contributing Editor
Dean Rehberger, Contributing Editor