first draft of review criteria.

README.md

@@ -39,6 +39,14 @@ allowed during the open review period which ends July 5th.
   overflow.
 - Avoid custom LaTeX markup where possible.
 
+## Review Criteria
+
+A small subcommittee of the SciPy 2015 organizing committee has created [this 
+set of suggested review 
+criteria](https://github.com/scipy-conference/scipy_proceedings/review_criteria.md) 
+to help guide authors and reviewers alike. Suggestions and amendments to these 
+review criteria are enthusiastically welcomed via discussion or pull request.
+
 ## Other markup
 
 Please refer to the example paper in ``papers/00_vanderwalt`` for

review_criteria.md

@@ -0,0 +1,65 @@
+# Suggested Review Criteria for SciPy Proceedings
+
+A small subcommittee of the SciPy 2015 organizing committee has created this 
+set of suggested review criteria
+to help guide authors and reviewers alike. Suggestions and amendments to these 
+review criteria are enthusiastically welcomed via discussion or pull request.
+
+
+## Written Quality
+
+- Prose should be written in English.
+- Prose should clearly communicate the narrative.
+- The written style should convey information that furthers the knowledge or 
+  research of the reader.
+- Due to the interdisciplinary nature of SciPy, highly domain-specific jargon 
+  should be avoided or explained where possible.
+
+## Technical Content
+
+- The technical content should be scientifically sound.
+- Computational content should, likewise, be verified.
+- The work should describe the development or use of python software for 
+  approaching a problem in a domain within the scope of the conference.
+
+## Novelty and Impact
+
+- The work should employ new or innovative methods or approaches to a problem.
+- The work should advance the state of a scientific domain, the practice 
+  of scientific computing itself, or another subject area within the scope of 
+  the conference.
+
+## Verifiability
+
+- Software descriptions should be accompanied by references to or examples of 
+  representative source code.
+- Source code essential to the conclusions of the paper should be made 
+  available to the reader.
+- Data sources should be identified (e.g., with citation to a persistent DOI).
+- Analysis should be accompanied by a workflow description sufficient
+  to reproduce the results.
+
+## Other Requirements
+
+- All mentioned software should be formally cited wherever possible.
+- Acronyms should be spelled out upon first mention.
+- License conditions on images and figures must be respected (Creative Commons, 
+  etc.).
+- Mathematical and other symbols should be defined.
+- Definitions should include consistent units where appropriate.
+
+### Length
+
+- The compiled version should be no longer than 7 pages, including figures.  
+
+### Figures
+
+- All figures and tables should have captions. 
+- Figure text should be of a readable size.
+
+### Code Snippets
+
+- Code snippets should be formatted to fit inside a single column without
+  overflow.
+- If not in Python, the language in the code snippet should be mentioned.
+- Code snippets should follow a common style guide. PEP8 is preferred.