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 very early stages, as this is an entirely crowd-sourced and volunteer-led project. We are focusing inititally on Module 5 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 want to contribute, add yourself to the contributors list and join our open Slack channel.
If you have questions about the project, please email us directly.
Stay tuned on what's happening on Twitter with @OpenSci_MOOC.
- 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.
- 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.
- 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
NOTE: Be sure to merge the latest from "upstream" before making a pull request!
- Try not to pollute your pull request with unintended changes – 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