- report an issue or suggest new content -- open an issue on GitHub
- improve the documentation -- suggest changes in the various READMEs if instructions are unclear
Have a look at the current Julia documentation.
Please use emojis, this helps visually sorting through the commits (and makes for a fun time). Inspiration taken from sciencegitmojis
| If the commit is about... | ...then use | Example |
|---|---|---|
| Work in progress | :construction: |
🚧 new output structure |
| Bug fix | :bug: |
🐛 mean fails if NA |
| Fixing typos | :pencil2: |
✏️ README |
| Code maintenance | :wrench: |
🔧 fix variable names |
| New test | :clapper: |
🎬 wget JSON resource |
| Plot figures | :bar_chart: |
📊 example boundaries |
| New data | :cd: |
💿 example pollination network |
| New feature | :sparkles: |
✨ (insert achievement) |
| Documentation | :books: |
📚 lattice function |
| Performance improvement | :racehorse: |
🐎 parallelizes models by default |
| Upcoming release | :package: |
📦 v1.0.6 |
| Ugly but working code | :dragon: |
🐉 added lattice function |
| Working on code that doesn't work but I want to go home | :neutral_face: |
😐 for triangulation |
| I forgot to save everything before committing | :sandwich: |
🥪 what is saving |
| Jettisoned something | :boom: |
💥 manifest |
This section describes the general steps to make sure that your contribution is
integrated rapidly. Note that the main branch is protected and you will be
unable to make any changes directly but rather through pull requests. The
general workflow is as follows:
- Create an issue that outlines proposed content or fixes
- Fork the repository (see Branches, etc. below)
- Create an explicitly named branch from
main - Create a pull request as soon as you make the first commit and link this to the relevant issue
- Be as explicit as possible on your goals
- Do not squash / rebase commits while you work -- we will do so when merging
Creating a pull request before you push any code will signal that you are interested in contributing to the project. Once this is done, push often, and be explicit about what the commits do (see commits, below). This gives the opportunity for feedback during your work, and allow for tweaks in what you are doing.
A good pull request (in addition to satisfying to all of the criteria below) is:
- Single purpose - it should do one thing, and one thing only
- Short - it should ideally involve less than 250 lines of code
- Limited in scope - it should ideally not span more than a handful of files
- Well tested and well documented
- Written in a style similar to the rest of the codebase
This will ensure that your contribution is rapidly reviewed and evaluated.
While you are working on changes you can render the site locally using
quarto render and if you want to preview it you can use quarto preview.
The website itself is deployed through github actions and is the reason that we will use pull requests as a way to not only act as a checkpoint as to what content is added to the website but also as a means to test that any changes that are made to the files will not break the deployment workflow.
This is all automated and you should not need to manually activate these deployments
however, if they fail you will not be able to merge your pull request and it is
at this point that you will need to work out what has caused the build to fail.
You can refer to the build logs on Github but it might be easier to run
quarto render locally and see what the error messages are from there.
The only time that you will need to first render the site locally before publishing
is if you modify any code-based content. This is because we use the freeze
functionality that allows us to store partial builds of the website nad makes remote
rendering mush more efficient. Currently this will only apply to changes made to the
collaborators map in people.yml.