The Journal of Open Source Education

The Journal of Open Source Education (JOSE) is an educator friendly journal for publishing computational learning modules and educational software.

JOSE, pronounced [hoe-zay], is a sibling journal to the Journal of Open Source Software (JOSS), which publishes open research software. JOSE relies on the journal management infrastructure and tools developed for JOSS.

JOSE publishes two types of articles that describe:

• open educational software tools
• open-source learning modules

Why is this journal needed?

Currently, academia lacks a mechanism for crediting efforts to develop software for assisting teaching and learning or open-source educational content. As a result, beyond personal motivation, there is little incentive to develop and share such material.

The Journal of Open Source Education (JOSE) is a scholarly journal with a formal peer review process designed to improve the quality of the software or content submitted. Upon acceptance into JOSE, a CrossRef DOI is minted and we list your paper on the JOSE website.

Who is behind this journal?

This is an initiative led directly by the Editorial Board on a purely volunteer basis. There is no publisher seeking revenue through the journal. JOSE runs on the efforts of the editors, authors, and reviewers, to communicate scholarly work to the open-source community without intermediaries.

What do you mean by "open-source educational materials"?

Examples include Jupyter notebooks or plaintext/markup language documents like LaTeX, R Markdown, and ReST for course/lesson content and associated notes, with embedded or associated code snippets/programs.

We do not mean openly available slides, lecture notes, or YouTube videos, though these may be acceptable as supplementary materials. In addition, course syllabi by themselves are not suitable for submission (Syllabus may be more appropriate).

tl;dr: your course or lesson content must contain or use code to teach. We are not focused exclusively on learning to code, but coding to learn.

What do you mean by "educational software tools"?

Open-source software that serves as educational technology; examples include (but are not limited to) alternatives to learning management systems, autograders, cloud systems for lesson delivery, student collaboration tools. For these tools, peer review will follow a similar process as JOSS.

Scope

We consider submissions from all areas of academia, although our computational focus may result in more natural submissions from STEM fields—but all are welcome!

Submissions must be "feature complete" to the extent that another educator could adopt, reuse, and/or extend for their purposes.

The ideal submission size is a course module, although entire courses are also acceptable.

Code of Conduct

Although spaces may feel informal at times, we want to remind authors and reviewers (and anyone else) that this is a professional space. As such, the JOSE community adheres to a code of conduct adapted from the Contributor Covenant code of conduct.

Authors and reviewers will be required to confirm they have read our code of conduct, and are expected to adhere to it in all JOSE spaces and associated interactions.

Affiliations

The Journal of Open Source Education is a NumFOCUS-sponsored project.

Author Guidelines

Preparing your JOSE submission should be a simple task, once you have a complete software or learning module you wish to publish.

The two submission types

JOSE accepts two types of submissions: (1) computational learning modules, created as open educational resources (OER), and (2) open-source software, created as educational technology or infrastructure.

Submission requirements

JOSE submissions must be fully open, under the Open Definition. This means that any text content or graphical objects should be under a Creative Commons license (ideally CC-BY) and code components should be under an OSI-approved license.

Computational learning modules should be complete and immediately usable for self-learning or adoption by other instructors. They should make a clear contribution to teaching and learning of any subject, supported by computing. JOSE is not focused in OER for "learning to code" as much as "coding to learn."

Software submissions should make a clear contribution to the available open-source software that supports teaching and learning, or makes an educational process better (e.g., faster, easier, simpler). Examples include software to auto-grade student work, learning management systems, and student collaboration frameworks. Software should be feature-complete (no half-baked solutions).

What about novelty?

Authors make the case for their submission's contribution in the paper, under the heading "Statement of Need." The criterion is less one of novelty, than need: submissions targeting subjects or applications already addressed by other resources are eligible, if the authors make a case for why they might be adopted by learners or other instructors. For example, authors could say that they approach a topic differently, that they update material to modern contexts, that the need is born of a new educational program, or a conference tutorial or other informal-learning scenario.

How to prepare a software submission?

Before starting your submission, you should:

• Have the software available in an open repository (GitHub, Bitbucket etc.) under an OSI-approved license.
• Write a short Markdown file titled paper.md with title, author names and affiliations, containing a description of the software, statement of need, and key references.
• Ideally, also create a metadata file and include it in your repository. We provide a script that generates the metadata automatically.

Once you have those items in place, submit via the JOSE web app.

How to prepare a learning-module submission?

Before starting your submission, you should:

• Have the content in an open repository, under a Creative Commons license (ideally CC-BY), and any code components under an OSI-approved license.
• Write a short Markdown file titled paper.md with title, author names and affiliations, containing a description of the module, a summary of its contents, a statement of need, and key references.
• Ideally, also create a metadata file and include it in your repository. We provide a script that generates the metadata automatically.

Once you have those items in place, submit via the JOSE web app.

What to include in the paper

JOSE papers should:

1. List all authors and affiliations.
2. Describe the submission, and explain its eligibility for JOSE.
3. Include a _Statement of Need_, explaining how the submitted artifacts contribute to computationally enabled teaching and learning, and describing how they might be adopted by others.
4. For software submissions, describe the functionality of the software, usage and recent experience of use in teaching and learning situations.
5. For learning modules, describe the learning objectives, content, instructional design, and experience of use in teaching and learning situations.
6. Tell us the "story" of the project: how did it come to be?
7. List key references including a link to the open archive of the sofware or the learning module.

JOSE welcomes submissions with diverse educational contexts. You should write your paper for a non-specialist reader. Your submission should probably be around 1000 words (or around two pages).

The goal is that someone reading the JOSE paper has enough information to decide if they'd be interested in adoping the learnig module or software. Readers will want to know how the content/software has been used, and how they would adopt it. They may also want to be persuaded that the authors have put careful work on creating the material, and have experience teaching with it.

JOSE papers contain a limited set of metadata, plus Summary & Reference sections. We explicitly do not publish long-form articles, because the scholarship represented by a JOSE article is contained in the software or learning modules themselves. Expected length less than 1000 words.

  Example paper.md:

---
title: 'Fidgit: An ungodly union of GitHub and figshare'
tags:
- example
- tags
- for the paper
authors:
- name: Arfon M Smith
  orcid: 0000-0000-0000-1234
  affiliation: "1, 2" # (Multiple affiliations must be quoted)
- name: Mickey Mouse
  orcid: 0000-0000-0000-1234
  affiliation: 2
affiliations:
- name: Space Telescope Science Institute
  index: 1
- name: Disney Inc.
  index: 2
date: 14 February 2016
bibliography: paper.bib
---

# Summary

Lorem ipsum ...

Citations to entries in paper.bib should be in
[rMarkdown](http://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.html)
format.

This is an example citation [@figshare_archive].

Figures can be included like this: ![Fidgit deposited in figshare.](figshare_article.png)

# References

  Example paper.bib:

@misc{figshare_archive,
author = {{figshare Archive}},
title = {Fidgit: An ungodly union of GitHub and figshare},
doi = {10.6084/m9.figshare.828487},
howpublished = {\url{https://doi.org/10.6084/m9.figshare.828487}}
}

Submission then is as simple as:

• Filling in the short submission form
• Waiting for reviewers to be assigned over in https://github.com/openjournals/jose-reviews

If you think your submission is not an obvious fit or have a question then please submit a pre-submission enquiry

What does a typical review process look like?

We encourage you to familiarize yourself with our reviewer guidelines as this will help you understand what our reviewers will be looking for. Broadly speaking though, provided you have followed our pre-submission steps and meet our submission requirements then you should expect a rapid review (typically less than two weeks).

After submission:

• One or more JOSE reviewers are assigned and the review is carried out in the reviews repository
• Authors respond to reviewer-raised issues (if any are raised) on the submitted repository's issue tracker. Reviewer contributions, like any other contributions, should be acknowledged in the repository.
• Upon successful completion of the review, deposit a copy of your (updated) repository with a data-archiving service such as Zenodo or figshare, issue a DOI for the archive, and update the review issue thread with your DOI.
• After assignment of a DOI, your paper metadata is deposited in CrossRef and listed on the JOSE website.
• And that's it.

Reviewer Guidelines

Thank you for agreeing to review for JOSE! Follow this guide to help you complete your review, and feel free to ask editors for more help using any medium (email, Twitter, comments on review issues, etc.)

JOSE review principles

JOSE accepts two types of submissions, and your role as reviewer will be different depending on the type. For software submissions, you will download, build, test and assess the software quality. For learning modules, you will download and read, test code components, and assess content and pedagogy.

For both types of submissions, your goal as reviewer is to help authors improve the quality of the submission to the standard for acceptance into JOSE. Categorical rejections are expected only in cases of out-of-scope or otherwise ineligible submissions. If authors decide they cannot meet your requests for improvements, however, they can withdraw their submission.

JOSE provides a checklist for review. You will check off each item, as you proceed with the review, adding comments and suggestions in the Review issue thread. You may also post specific issues on the main repository of the submitted software or module. Be sure to post links between the JOSE Review issue and the submission repository's issue tracker, as needed.

JOSE aim and scope

We're witnessing a swelling of communities that develop and share tools and practices in computationally enabled teaching and learning. The founding editors of JOSE have been participating in these communities, and recognized a need for a publication to house these scholarly products in a citable form.

Several journals already exist that publish academic papers reporting on education research: the systematic collection and analysis of data on teaching methods and student learning, and related qualitative studies. JOSE has a different scope. We're focused on the rich and growing work applying computational methods to enhance teaching and learning. For example, a whole new genre of open educational resources (OER) has sprouted out of creating and sharing Jupyter notebooks, in a variety of subjects benefitting from a computational treatment. At the same time, members of open-source communities are creating software tools to automate processes (like grading), facilitate access to computing for learning (via cloud systems), or otherwise enhance teaching and learning with computing. These are valuable contributions, independently of their possible use in education research, and their creators merit publication and citation credit for them.

JOSE also aims to disseminate the best practices in creating these scholarly objects, and increase quality via peer review. We want to be a formal, yet open and collegial vehicle for sharing accumulated knowledge in using computing to teach and learn.

The JOSE paper

Authors will submit a paper to accompany their software or learning module, consisting of the following minimum items:

• Title, and author list with affiliations
• Description of the software or learning module
• Statement of need
• Key references, including the submission archive

Detailed documentation should be present in the repository of the submitted software or module, is reviewed there, and does not need to be included in the paper.

Submission Requirements

License

The submission should be open, under the Open Definition. Any text content or graphical objects should be under a Creative Commons license (ideally CC-BY) and code components should be under an OSI-approved license. License information must be clearly visible in the submission's online repository, which must include a plain-text LICENSE file.

Acceptable: A plain-text LICENSE file with the contents of an OSI-approved license
Not acceptable: A phrase such as 'MIT license' in a README file

Statement of need

A key component of the JOSE paper is a statement by the authors, explaining the contribution made by the submitted artifacts to computationally enabled teaching and learning, and describing how they might be used by others. The criterion is less one of novelty, than need: submissions targeting subjects or applications already addressed by other resources are eligible, if the authors make a case for why they might be adopted by learners or other instructors.

Community guidelines

The online repository of the software or learning module needs to contain guidelines for potential contributors who may want to: submit changes, make improvements or report issues.

Specific requirements for software submissions

Documentation: The software repository should contain enough documentation to understand the functionality of the software, to guide through the build process (including a list of dependencies), and to complete examples of use.

Tests: Software quality depends on testing. Ideally, the software should include an automated test suite, but it's also acceptable to include documented manual steps to test the functionality of the software.

Examples: Potential users of new software rely on well-documented examples to get started. Reviewers will look for examples of use that illustrate beginner and advanced functionality

Good: A package management file such as a Gemfile or package.json or equivalent
OK: A list of dependencies to install
Bad (not acceptable): Reliance on other software not listed by the authors

Specific requirements for learning modules

Substance: A learning module should cover a substantial portion of material to achieve plainly clear learning objectives. The ideal module consists of a few lessons, building up a well-rounded topic, as a full tutorial or part of a term or semester course. This direction follows trends and recommendations to 'modularize' courses, both online and on-campus—one example is the 2014 report on the Future of MIT Education. The module should contain well-written and complete presentation of the material, weaved with the computatational portions and sample output.

Pedagogical soundness: Instructional design of the module should be intentional and apparent. For example, the weaving of text, images, code and output might apply the worked-example effect, deliberately. The authors should briefly explain their design in the JOSE paper.

Community guidelines

There should be clear guidelines for third-parties wishing to:

• Contribute to the software/module
• Report issues or problems with the software/module
• Seek support

What happens if the submission I'm reviewing doesn't meet the JOSE criteria?

We ask that reviewers grade submissions in one of three categories: 1) Accept 2) Minor Revisions 3) Major Revisions. Unlike some journals, we do not reject outright submissions requiring major revisions. we like to give the author as long as they need to make these modifications/improvements.

Editorial Board

Topic Editors