Submission Guidelines

The journal Evolutionary Computation invites authors to submit both theoretical and practical developments of computational systems drawing their inspiration from nature, with particular emphasis on evolutionary models of computation. Papers should describe mature work that is original in nature and which is neither published nor currently under review elsewhere.

• Quick link to submission system [access for authors, reviewers and Associate Editors]:
  Editorial Manager Submission System
• Guidelines for Authors
• Submission Instructions
• The Review Process
• Contact the Editor-in-Chief

Guidelines for Authors

Before submitting your paper to Evolutionary Computation, please read the following carefully.

ECJ strongly discourages the submission of papers that propose a “novel” algorithm based on a metaphor to a natural system, particularly where the natural system itself does not exhibit any optimisation property. It also discourages hybrids of such algorithms. Any ‘novel’ algorithm must be described in purely computational terms without reference to terms such as elephants, seals, hunting etc. Authors should also provide an explanation of why the proposed algorithm differs substantially from existing state-of-the-art methods in terms of its computational properties.

ECJ solicits three types of article:

• Full-length Articles (including surveys) (typically up to 35 pages)
• Letters (short articles ~6 pages)
• Software Articles

Full-length articles

ECJ accepts papers that broadly fall into the three categories: Applications, Experimental Results and Theory. Of course, many papers may fall into more than one category.

1. Applications: a commonly accepted idea is that Evolutionary Computation only focuses on the fundamentals of bio-inspired algorithms. This is not at all the case, and application papers describing original work are welcome. A minimal requirement, though, is to carefully present the application domain, assuming that the reader is not familiar with even its basic concepts.

   It is not sufficient simply to apply an arbitrarily chosen EA to a new problem domain and show some results.

   An application paper will likely fall into one of two categories:
   • Results oriented: contain strong evidence that the use of Evolutionary Computation resulted in break-through results that could not be achieved by another method
   • Methodological: papers where the specificities of the real-world problem led to significant algorithmic improvements that could possibly be generalized to other areas. Such "success stories" are of course reviewed by experts in the application domain, i.e. outside our usual pool of reviewers.
2. Experimental results: as in all experimental sciences, the first requirement is that of reproducibility. All details of the algorithm, parameter values, etc. must be clearly given - and remember that there is no such thing as "a standard EA" that would replace the complete description of your algorithm. Moreover, because we are dealing with stochastic algorithms, strong conclusions drawn from experimental results must rely on statistically sound analysis. There have been to-date many tutorials, workshops and books describing statistically sound experimental protocols. Although all papers are different, please consider the following guidelines when preparing your manuscript:
   • Ensure reproducibility (pseudo-code, parameters etc.)
   • Use the most recent and well-cited benchmarks to evaluate your work. Show the generality applicability of your method across a broad a range of instances as possible – there are many datasets freely available – testing on a small selected instance set is usually not sufficient.
   • Provide a comparison to state-of-the-art results from both EC methods and other fields if appropriate
   • Provide evidence of tuning rather than arbitrary selection of parameters (there are many packages for doing this for you)
   • Consider providing code as supplementary data
   • Consider providing datasets if possible as supplementary data
   • Provide a proper statistical analysis. This goes beyond a table showing mean/standard deviation. Use appropriate parametric/non-parametric statistics to show statistical significance with stated confidence levels
3. Theoretical results: submitted material should include all proofs. While conference papers, because of space limitation, often cannot present the complete proofs, journal papers must be self-contained, or refer to easily accessible published results when citing existing proofs (e.g. no "Personal Communication"). In exceptional cases (e.g. Andrew Wiles' proof of Fermat theorem), parts of the proofs can be added as supplementary material.

Letters

Letters fall into the three broad categories described above. A letter will typically focus on a single idea, or provide a commentary or reaction to published material.

Software Articles

Creating quality open source software is a major effort in computational research fields, and an important community service. Researchers invest considerable resources into the development of software. This entails the correct and efficient implementation of algorithms, as well as infrastructure such as interfaces and test problems. The goal of the software section is to provide a peer reviewed publication platform and to make the work easily citable in academic contexts. The track also hopes to encourage and support open and reproducible research.

ECJ publishes papers about software, while the software itself is hosted elsewhere. However, it is the understanding of the section that the software, not the paper, is the star of the publication. Software meeting the following criteria is in the scope of the track:

• The software must be open source. It must be available under an approved open source software license
• The scope of the software must be clearly within the domain of evolutionary computation. For large software packages, a significant part of the software must be dedicated to Evolutionary Computation.
• As a general guideline, the software should represent a development workload of at least several person months. The scope ranges from (tidy) research code for a specific niche or algorithm (class) to full-blown optimization software libraries.
• The software should provide added value to a wider community of users. It should be easy to install and use, and it should be well-documented.

The paper, the software, and the accompanying documentation are assessed as a unit. ECJ does not aim to enforce a certain style of writing and maintaining software. However, the review criteria follow established best practices, in the interest of ease of use by the community and high long-term impact. The following quality criteria apply.

1. General Criteria
   
   • The scope of (core parts of) the software must be Evolutionary Computation.
   • The software project should be relevant to the community. This can be proven by means of an active user community (number of contributors, commits, github stars) or by scientific publications using the software. It is understood that newer software projects have less to show than long-established ones. At the very least the software should be of potential interest to more than a handful of users.
2. Paper
   
   • The authors of the paper should have considerable overlap with the current lead development team of the software.
   • The paper should present scope and core functionality of the software from a high-level research perspective. It is not intended as documentation, but rather to help researchers to pick the right software package for their needs.
   • The software needs to be put into perspective of alternatives (if they exist), discussing specific strengths and limitations.
3. Software
   
   • The software needs to be available under an open source software license. The license must be included as a separate text file (COPYING, LICENSE or similar) or be included in the headers of all source files.
   • If the software or a part thereof is accessible through a web service, then its core needs to be open source (but all components used to run the service do not).
   • There should be installation instructions for all supported platforms. Support of at least one open source platform is a plus.
   • Dependencies must be listed. Automatic dependency management, e.g. by means of a package manager, is a plus.
   • In the interest of maintainability and the ability of a wider audience to make contributions, the source code should be documented (commented).
   • Software projects should adhere to development best practices.
   • Issue tracking, code review, and reasonable unit test coverage are appreciated. Projects should be hosted on a platform supporting modes of cooperation suitable for open source software.
   • It should be clear for users how to get support, how to report potential issues, and if desired, how to get involved.

Before the software enters the review process, it undergoes a sanity check. If it does not install, if it does not offer an open source license, or if it does not provide any documentation, then it is rejected outright.

4. Documentation
   
   • On the project landing page and/or on the documentation main page, the software project is expected to clearly state its scope and purpose.
   • If applicable, in particular for larger projects, documentation should consist of the following components:
     
     • guides (getting started) and tutorials,
     • documentation of general concepts,
     • API documentation, and
     • example programs.
   • Guides should get users up to speed quickly. They should be brief, yet demonstrate core capabilities and get the "feel" of the software across.
   • Good documentation explains how domain concepts are encapsulated into software concepts like classes and functions. It should help new users to quickly develop a high-level mental model of the software. It should not be necessary to extract such information from the API documentation or by reading between the lines of the code.
   • API documentation should be useful for looking up specific information while working with the software. It should go significantly beyond listing information that can be deduced from class and function names and signatures. As an example, consider a function `getID(x)`.
     
     • Bad: "returns the ID of x"
     • Good: "Each object has a unique ID. Given an object `x`, this function returns its ID. This ID is a 64-bit unsigned integer value. An ID can act as a reference to the object. In contrast to a pointer, it is meaningful to store the ID to persistent storage (like a file or database), or to transfer it over a network."

Submission Instructions

The following applies to all types of submission. Please also refer to the separate sub-sections for explicit instructions depending on the type of your submission.

• All papers should be submitted through the Editorial Manager Submission system.
• Papers must be prepared using LaTeX and submitted as pdf file.
• All style files, including the ecj.sty style used to typeset the paper.
• Login to check progress of your paper here.

Full-length Articles

• As a rule, papers should be 8,000 to 12,000 words in length (maximum of 35 pages in the Evolutionary Computation LaTeX style, including references).
• You can also include an additional file of Supplementary Material (containing data, additional visualisations etc.) that will be made available online following acceptance of a paper. There is no limit on the size of this file.
• Authors are strongly encouraged to include a link to a code repository (such as github) where code can be downloaded to promote reproducibility. Code can also be included as part of Supplementary Material.

Letters

• Please select Letter as the article type in the submission system
• Letters should have a maximum of 6 pages.

Software Articles

Please select Software Article as the article type in the submission system. We do not request authors to submit the software itself. However, it should be straightforward for users and reviewers to obtain the version of the software that is described in the paper from a public website or repository.

Most software is expected to be written in popular programming languages like Python, R, C, C++, C#, Java, and Matlab/Octave. Code in other languages is acceptable. However, in this case suggestions for possible reviewers with a background in EC and in the programming language should be listed in the cover letter.

A submission must consist of:

• A cover letter (PDF file) stating:
  
  • the submission is intended for the open source software track
  • the web or repository address of the project
  • the version of the software to be reviewed
  • the open source license(s) under which the software is released
  • the programming language(s) and the supported platforms
  • projects and papers using the software.
• A paper in ECJ format (PDF file), no more than four pages long.

The Review Process

What happens after a paper has been submitted?

• After first vetting, the Editor in Chief sends it to Associate Editors.
• The Associate Editor finds independent reviewers (usually at least 3). Most likely again, one of them is a member of the Editorial Board.
• When all reviewers have entered their review in the system, the Associate Editor can either make a recommendation to the Editor in Chief, based on the reviews and his/her own opinion, or start a discussion among the reviewers if there is some disagreement. The discussion involves all reviewers, the Associate Editor and the Editor in Chief.
• After an agreed decision have been reached, the authors are notified by the Editor in Chief or the Associate Editor.
• The possible decisions are
  • Accept: the paper can be published as it is now (except maybe for some typos).
  • Accept with minor revisions: the paper will have to be slightly revised following the reviewers' comments, but there will not be any additional round of review, only the Action Editor and/or the Editor in Chief will check the modifications.
  • Revise and resubmit: although the topic is worth publishing, but the paper requires significant revisions before it can actually be published (often including additional experimental work). A substantial rewrite of the paper is likely, rather than merely clarifying material. If a revised version is sent within 6 months, it will most probably be handled by the same Action Editor.
  • Reject: the paper is out of scope, or does not contain any significant contribution, or may be simply too difficult to understand. In this case, the same work should not be resubmitted without first seeking approval from the EiC.

Last but not least, it is our goal that the whole review process does not take more than 3 months before the decision is sent to the authors.

Peer Review Taxonomy

Identity transparency: Single anonymized
Reviewer interacts with: Editor
Review information published: Non

Contact Information

Any inquiries concerning editorial issues, as well as submission format and submissions themselves, should be directed by e-mail to the Editors-in-Chief: