Contribution Guidelines

New to GIT and GitHub? See these learning resources and this 10 min. GIT tutorial.

These are the main contributing guidelines for the development of this project. The development structure for this is based on a combination of two things:

• Invited experts as part of a core development team, led by one or two managers for each module.
• Open participation, where anyone can contribute using the standard processes on GitHub.

Feedback and contributions of any form are welcomed. Feel free also to contact us to discuss anything further.

At the present, development is in early stages, as this is an entirely crowd-sourced and volunteer-led project. We are focusing inititally on Module 5, Open Research Software and Open Source to run as a pilot for testing and receiving feedback. After this, the protocol and content will be revised, and then applied accordingly to the development of the remaining modules.

Contact us

If you want to contribute, please firstly join our open Youtube channel. Secondly, please add yourself to the Development team on GitHub. Thirdly, please add yourself to the main website.

If you have questions about the project, please email us directly.

Stay tuned on what's happening on Twitter with @Kamachikuq.

For partnerships, please see here.

Getting started

• Forming a team for collaborative design.

• The development process.

• Familiarise yourself with the script writing guide, the script template and the video management protocol.

Each team will adhere to the MOOC planning template to structure development in a systematic way.

Altering the module content.

Modules are rendered from markdown files (here is a useful markdown cheatsheet) located in the content development folder.

For each update made, make sure to update the MOOC planning template as needed.

Reporting issues

• Search for existing issues. Please check to see if someone else has reported the same issue.

• Share as much information as possible. Include operating system and version, browser and version. Also, include steps to reproduce the bug.

Project Setup

Refer to the README.

Content style

This is flexible to each module as required, and defined by each development team in advance as part of the protocol.

Code style

Flexible, as long as it is consistent. Ideally, all content would be drafted in markdown, for increasing re-use. This can be easily performed in R Studio, for example, which also has a GitHub interface to make collaborating on this project even simpler.

Please read this guide to familiarise yourself with this process. Which in itself, is actually fairly powerful for Open Science!

Pull requests

Please refer to each project's style guidelines and guidelines for submitting patches and additions. In general, we follow the "fork-and-pull" Git workflow.

NOTE: Be sure to merge the latest from "upstream" before making a pull request!

• Fork the repo on GitHub

• Clone the project to your own machine

• Commit changes to your own branch

• Push your work back up to your fork

• Submit a Pull request so that we can review your changes

• Try not to pollute your pull request with unintended changes and keep them simple and small. If possible, squash your commits.

• Try to share how your code has been tested before submitting a pull request.

• If your PR resolves an issue, include closes #ISSUE_NUMBER in your commit message (or a synonym).

• Review

  • If your PR is ready for review, another contributor will be assigned to review your PR.
  • The reviewer will accept or comment on the PR.
  • If needed address the comments left by the reviewer. Once you're ready to continue the review, ping the reviewer in a comment.
  • Once accepted your code will be merged to master.