These are the main contributing guidelines for the development of this MOOC, and apply to each module within. 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.
If you have questions about the project, please email us directly.
Stay tuned on what's happening on Twitter with @OpenSci_MOOC.
For partnerships, please see here.
Each team will adhere to the MOOC planning template to structure development in a systematic way.
Altering the module content.
For each update made, make sure to update the MOOC planning template as needed.
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.
Refer to the README.
This is flexible to each module as required, and defined by each development team in advance as part of the protocol.
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!
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).
- 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