Welcome to the
NEGI-Abisko-2019 repository! We're excited you're here and want to contribute.
These guidelines are designed to make it as easy as possible to get involved. If you have any questions that aren't discussed below, please let us know by opening an issue!
By contributing, you agree that we may redistribute your work under our license. In exchange, we will address your issues and/or assess your change proposal as promptly as we can, acknowledge your contributions and help you become a member of our community. Everyone involved in [Nordic Earth System Modeling hub][nordicesmhub-site] agrees to abide by our code of conduct.
Already know what you're looking for in this guide? Jump to the following sections:
- Joining the conversation
- Contributing through Github
- Understanding issues, milestones, and project boards
- Making a change
- Structuring contributions
- Recognizing contributors
NEGI-Abisko-2019 repository has been setup for the 3rd course “Climate science at high latitudes: eScience for linking Arctic measurements and modeling” that will be held at Abisko Scientific Research Station from 15th until 24th of October 2019.
We're excited to have you join! Most of our discussions will take place on open issues.
As a reminder, we expect all contributors to
NEGI-Abisko-2019 to adhere to the Carpentries Code of Conduct in these conversations.
You'll use Markdown to chat in issues and pull requests on GitHub.
You can think of Markdown as a few little symbols around your text that will allow GitHub
to render the text with formatting.
For example you could write words as bold (
**bold**), or in italics (
or as a link (
[link](https://https://youtu.be/dQw4w9WgXcQ)) to another webpage.
GitHub has a helpful page on getting started with writing and formatting Markdown on GitHub.
Every project on GitHub uses issues slightly differently.
The following outlines how the
jupyter-book developers think about these tools.
Issues are individual pieces of work that need to be completed to move the project forwards. A general guideline: if you find yourself tempted to write a great big issue that is difficult to describe as one unit of work, please consider splitting it into two or more issues.
Issues are assigned labels which explain how they relate to the overall project's goals and immediate next steps.
The current list of labels are here and include:
If you feel that you can contribute to one of these issues, we especially encourage you to do so!
If you find new a bug, please give as much detail as possible in your issue, including steps to recreate the error. If you experience the same bug as one already listed, please add any additional information that you have as a comment.
Please try to make sure that your enhancement is distinct from any others that have already been requested or implemented. If you find one that's similar but there are subtle differences please reference the other request in your issue.
Please check the issues (especially closed ones) to see if your question has been asked and answered before. If you find one that's similar but there are subtle differences please reference the other request in your issue.
We appreciate contributions from all assistants, teachers and students to
NEGI-Abisko-2019, but those accepted fastest will follow a workflow similar to the following:
1. Comment on an existing issue or open a new issue referencing your addition.
This allows other members of the Abisko core 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 up front is so useful to everyone involved.
This is now your own unique copy of NEGI-Abisko-2019. Changes here won't effect 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 master repository.
3. Make the changes you've discussed.
Make sure you only update the master branch.
Try to keep the changes focused. We've found that working on a new branch makes it easier to keep your changes targeted.
4. Submit a pull request.
A member of the development team will review your changes to confirm that they can be merged into the main code base. When opening the pull request, we ask that you follow some specific conventions. We outline these below.
To improve understanding pull requests "at a glance", we encourage the use of several standardized tags. When opening a pull request, please use at least one of the following prefixes:
- [DOC] for new or updated documentation
- [JNB] for new or updated jupyter notebook
- [ENH] for enhancements
- [FIX] for bug fixes
- [REF] for refactoring existing code
- [STY] for stylistic changes
You can also combine the tags above, for example if you are updating both a test and the documentation: [STY, DOC].
Pull requests should be submitted early and often!
If your pull request is not yet ready to be merged, please open your pull request as a draft. More information about doing this is available in GitHub's documentation. This tells the development team that your pull request is a "work-in-progress", and that you plan to continue working on it.
When your pull request is Ready for Review, you can select this option on the PR's page, and a project maintainer will review your proposed changes.
We welcome and recognize all contributions from documentation to testing to code development. You can see a list of current contributors in the contributors tab.
Thank you for sharing your codes, documentation, jupyter notebooks, etc.