🌎🌍🌏 Welcome to EDS book repository! 🌎🌍🌏
💚 We're excited that you're here and want to contribute. 💚
We want to ensure that every user and contributor feels welcome, included and supported to participate in the EDS book community. We hope that the information provided in this document will make it as easy as possible for you to get involved.
We welcome all contributions to this project via GitHub issues and pull requests. Please follow these guidelines to make sure your contributions can be easily integrated into the project. As you start contributing to EDS book, don't forget that your ideas are more important than perfect pull requests. 💚
If you have any questions that aren't discussed below, please let us know through one of the many ways to get in touch.
Been here before? Already know what you're looking for in this guide? Jump to the following sections:
- Joining the community
- Inclusivity
- Get in touch
- Contributing through GitHub
- Writing in Markdown
- Where to start: issues
- Making a change with a pull request
- Representing EDS book
- Recognising Contributions
EDS book is a community-led and collaboratively developed project. We, therefore, require that all our members and their contributions adhere to our Code of Conduct (CoC).
Please familiarize yourself with our CoC that lists the expected behaviours.
EDS book aims to be inclusive to people from all walks of life and to all research fields.
These intentions must be reflected in the contributions that we make to the project.
There are many ways to get in touch with EDS book team!
- GitHub issues and pull requests
- Join a discussion, collaborate on an ongoing task and exchange your thoughts with others.
- Can't find your idea being discussed anywhere? Open a new issue! (See our Where to start: issues section below.)
- For structured discussion and sustained engagement with the community members.
- Contact the maintainers of EDS book project - Alejandro Coca-Castro - by email at [email protected] and/or Anne Fouilloux - by email at [email protected].
- @eds_book on Twitter and fosstodon.org/@eds_book in Mastodon
- Follow us for regular updates
- Bimonthly Collaboration Cafe: We shared-out recent progress, achievements or events at The Turing Way Collaboration Cafes. At least one of core EDS book members (as described in the Ways of Working document) will be attending the collaboration cafe to onboard or discuss relevant topics within EDS book and The Turing Way communities. Members of both communities are also welcome to join to #environmental-sustainability) in The Turing Way Slack, a dedicated channel for discussing broadly relevant topics aligned to Open Research in Environment & Sustainability.
- Shared notes with joining links: https://hackmd.io/@turingway/collaboration-cafe.
- Monthly Co-working sessions: Every Second Friday (16:00 - 17:00 London time). This is a synchronous collaborative space to either discuss your ideas or quietly work in an accountable space with EDS book team members.
- Shared notes with joining links: https://hackmd.io/@eds-book/coworking-call/.
Git is a really useful tool for version control. GitHub sits on top of Git and supports collaborative and distributed working.
We know that it can be daunting to start using Git and GitHub if you haven't worked with them in the past, but EDS book maintainers are here to help you figure out any of the jargon or confusing instructions you encounter! 💚
In order to contribute via GitHub, you will need to set up a free account and sign in. Here are some instructions to help you get going. Remember that you can ask us any questions you need to along the way.
GitHub has a helpful page on getting started with writing and formatting on GitHub.
Most of the writing that you will do will be in Markdown.
You can think of Markdown as a few little symbols around your text that will allow GitHub to render the text with a little bit of formatting.
For example, you could write words as bold (**bold**), or in italics (_italics_), or as a link ([link](https://youtu.be/dQw4w9WgXcQ)) to another webpage.
Also when writing in Markdown, please start each new sentence on a new line. Having each sentence on a new line will make no difference to how the text is displayed, there will still be paragraphs, but it makes the diffs produced during the pull request review easier to read! ✨
Before you open a new issue, please check if any of our open issues cover your idea already. If you open a new issue, please follow our basic guidelines laid out in our issue templates. There are 5 issues templates to choose from.:
- 🐛 Bug Report (preview here): With this template, create an issue report that can help others repair something that is currently broken.
- ✒️ Documentation Improvement (preview here): This issue is to help us improve the documentation in the book or notebook repositories hosted in the eds-book-gallery organisation. Alternatively you can just open a pull request with the suggested improvement.
- 📗 Notebook Idea (preview here): Use this template for submitting a notebook idea. You can find further info of the scope of notebooks ideas within the Publishing guidelines.
- 🔍 PRE-REVIEW (preview here): Editors-in-chiefs use this template to open a PRE-REVIEW issue.
- 👀 REVIEW (preview here): Editors-in-chiefs use this template to open a REVIEW issue.
We appreciate all contributions to EDS book. THANK YOU for helping us build this useful resource. 🌱
All project management, conversations and questions related to EDS book project happens here in EDS book repository. This is also where you can contribute directly to writing or editing chapters of the book!
The following steps are a guide to help you contribute in a way that will be easy for everyone to review and accept with ease 🎓.
1. Comment on an existing issue or open a new issue referencing your addition
This allows other members of EDS book team to confirm that you aren't overlapping with work that's currently underway and that everyone is on the same page with the goal of the work you're going to carry out.
This blog is a nice explanation of why putting this work in upfront is so useful to everyone involved.
2. Fork EDS book repository
This is now your own unique copy of EDS book. Changes here won't affect anyone else's work, so it's a safe space to explore edits to the code!
Make sure to keep your fork up to date with the main repository, otherwise, you can end up with lots of dreaded merge conflicts. If you prefer working in the browser, these instructions describe how to sync your fork to the original repository via GitHub.
Try to keep the changes focused. If you submit a large amount of work all in one go it will be much more work for whoever is reviewing your pull request. Help them help you. 😉
While making your changes, commit often and write good, detailed commit messages. This blog explains how to write a good Git commit message and why it matters. It is also perfectly fine to have a lot of commits - including ones that break code. A good rule of thumb is to push up to GitHub when you do have passing tests then the continuous integration (CI) has a good chance of passing everything. 😸
If you feel tempted to "branch out" then please make a new branch and a new issue to go with it. This blog details the different Git branching models.
Please do not re-write history! That is, please do not use the rebase command to edit previous commit messages, combine multiple commits into one, or delete or revert commits that are no longer necessary.
Are you new to Git and GitHub or just want a detailed guide on getting started with version control? Check out our Version Control chapter in The Turing Way Book!
4. Submit a pull request
We encourage you to open a pull request as early in your contributing process as possible. This allows everyone to see what is currently being worked on. It also provides you, the contributor, feedback in real-time from both the community and the continuous integration as you make commits (which will help prevent stuff from breaking).
When you are ready to submit a pull request, you will automatically see the Pull Request Template contents in the pull request body. It asks you to:
- Describe the problem you're trying to fix in the pull request, reference any related issue and use fixes/close to automatically close them, if pertinent.
- List of changes proposed in the pull request.
- Describe what the reviewer should concentrate their feedback on.
- Acknowledging contributors.
By filling out the "Lorem ipsum" sections of the pull request template with as much detail as possible, you will make it really easy for someone to review your contribution!
If you have opened the pull request early and know that its contents are not ready for review or to be merged, add "[WIP]" at the start of the pull request title, which stands for "Work in Progress". When you are happy with it and are happy for it to be merged into the main repository, change the "[WIP]" in the title of the pull request to "[Ready for review]".
A member of EDS book team will then review your changes to confirm that they can be merged into the main repository. A review will probably consist of a few questions to help clarify the work you've done. Keep an eye on your GitHub notifications and be prepared to join in that conversation.
You can update your fork of EDS book repository and the pull request will automatically update with those changes. You don't need to submit a new pull request when you make a change in response to a review.
You can also submit pull requests to other contributors' branches! Do you see an open pull request that you find interesting and want to contribute to? Simply make your edits on their files and open a pull request to their branch!
What happens if the continuous integration (CI) fails (for example, if the pull request notifies you that "Some checks were not successful")? The CI could fail for a number of reasons. At the bottom of the pull request, where it says whether your build passed or failed, you can click “Details” next to the test, which takes you to a CI run log site. If you have the write access to the repo, you can view the log or rerun the checks by clicking the “Restart build” button in the top right. You can learn more about CI in the Continuous Integration chapter!
GitHub has a nice introduction to the pull request workflow, but please get in touch if you have any questions or ideas 💡.
You can build and host the book website locally. The steps are:
-
Install the required software to build the book, optionally in a virtual environment:
pip install -r book/requirements.txt -
You can now build or refresh the book using:
cd ./book/website jupyter-book build .
We would LOVE people to give talks about the project or represent EDS book in other ways! We have created a promotion pack for you to reuse. You will find useful details about the project, a list of frequently asked questions, slide decks, and contact details.
If you would like to represent the project in your network, please open an issue and ping @acocac, @annefou so that they can do their best to support you.
We suggest to archive presentations in Zenodo and tag Environmental Data Science book community. This will make more visible the presentation to wider Open Science network.
We welcome and recognise all kinds of contributions, from fixing small errors, to developing documentation, maintaining the project infrastructure, writing chapters or reviewing existing resources.
In the contributing chapter, you can read how your contributions will be acknowledged and recorded in EDS book. EDS book follows the all-contributors specifications. The all-contributors bot usage is described here. You can see a list of current contributors here. 😍
To add yourself or someone else as a contributor, comment on the relevant Issue or Pull Request with the following:
@all-contributors please add <username> for <contributions>
You can see the Emoji Key (Contribution Types Reference) for a list of valid <contribution> types and examples of how we've run this command in this issue.
The bot will then create a Pull Request to add the contributor and reply with the pull request details.
PLEASE NOTE: Only one contributor can be added with the bot at a time!
Add each contributor in turn, merge the pull request and delete the branch (all-contributors/add-<username>) before adding another one.
Otherwise, you can end up with dreaded merge conflicts.
Therefore, please check the open pull requests first to make sure there aren't any open requests from the bot before adding another.
What happens if you accidentally run the bot before the previous run was merged and you got those pesky merge conflicts?
(Don't feel bad, we have all done it! 🙈)
Simply close the pull request and delete the branch (all-contributors/add-<username>).
If you are unable to do this for any reason, please let us know by opening an issue, and EDS book team members will be very happy to help!
Finally, don't forget to add yourself to the list of contributors here!
These Contributing Guidelines have been adapted from The Turing Way Contributing Guidelines (License: CC BY 4.0) which were originally sourced from the BIDS Starter Kit! (License: CC-BY)