| title | layout |
|---|---|
Editorial Policies |
directory |
The editorial values and policies of Programming Historian cluster around our interest in facilitating a community-driven resource of the highest quality that embraces the standards of openness and accessibility.
Programming Historian is committed to open source and open access principles. All contributed lessons must make use of open source programming languages and open source software whenever possible. This policy is meant to minimize costs for all parties, and to allow the greatest possible level of participation. We believe everyone should be able to benefit from these tutorials, not just those with large research budgets for expensive proprietary software.
Programming Historian also emphasizes sharing credit where it is due. Potential authors agree to release their lesson under a Creative Commons Attribution 3.0 Unported license, also known as a “CC-BY” license. This means that you have the right to post your lesson to your blog, to your local newspaper, or to anywhere else you see fit without asking anyone’s permission. However, you grant Programming Historian and anyone else interested in your work the right to do the same as long as they list you as the author. This allows the lessons to have the greatest possible diffusion and impact.
Rather than offering lessons in a set order, we present more of a smorgasbord that enables readers to pick and choose particular lessons that seem most relevant for immediate research needs. We deliberately aim for our lessons to build and draw upon each other, often creating small lesson expressly for explaining a basic concept or technique that appears across many lessons. As a author, this means that you don’t need to explain in detail every concept, technologies, or technique, but can focus on the problem you’re most interested in.
Lessons must make every effort to use stable, non-deprecated (or soon to be deprecated) techniques, languages and software. Alpha versions of software should be avoided; Beta versions only used if they are extremely stable. We discourage operating-system specific tutorials, but we are happy to work with you to get your tutorial tested on other platforms so that everyone can benefit from them.
Our peer review process is a bit different from what might be considered the “traditional” peer review process. We do not solicit reviews to judge whether a tutorial is “good enough” to be published. Rather, we consider the review process an integral component of a collaborative, productive, and sustainable effort for scholars to create useful technical resources for each other. Once a tutorial slips into our editorial workflow, our goal is to do everything we can to make sure the tutorial becomes as useful as possible and published in a reasonable amount of time. Consult our Reviewer Guidelines for more information.
Lessons should be written in Markdown, a lightweight syntax that helps us to generate our site using GitHub Pages. For more information about how lessons should be formatted, see our Markdown Style Guide.
All lessons must be submitted via GitHub with a pull request. If GitHub is unfamiliar to you, introductory tutorials can walk you through the process. Our first-time authors almost always report that while GitHub can seem intimidating, it's actually quite straightforward once you dive in. For more detailed instructions, new authors should consult our new lesson workflow.