We are looking forward to changes and improvement to this package. Before you contribute, please read the Code of Conduct.
Before submitting a pull request, please add your name and information in
alphabetic order (after the first name) to .zenodo.json
. You will get
credited as an author of the next release of the package.
src
contains all the functions, types, and methodstests
contains the unit tests and some integration testsdocs
contains the documentation- please use
julia docs/_weave/make.jl
to update the webpage and the README - the notebooks go in
notebook
(also compile them, and update the README)
- please use
- report a bug or suggest an improvement -- open an issue on GitHub
- write a vignette -- used
GBIF.jl
to do something? Put a Jupyter notebook indocs/notebooks
, and add it to the README - improve the documentation -- all functions have a
docstring
where they are declared, and improving them is a great way to get started
Have a look at the current Julia documentation.
Please use emojis, this helps visually sorting through the commits.
If the commit is about... | ...then use | Example |
---|---|---|
Work in progress | :construction: |
🚧 new graphics |
Bug fix | :bug: |
🐛 mean fails if NA |
Code maintenance | :wrench: |
🔧 fix variable names |
New test | :rotating_light: |
🚨 wget JSON resource |
New data | :bar_chart: |
📊 example pollination network |
New feature | :sparkles: |
✨ (anything amazing) |
Documentation | :books: |
📚 null models wrapper |
Performance improvement | :racehorse: |
🐎 parallelizes null model by default |
Upcoming release | :package: |
📦 v1.0.2 |
This section describes the general steps to make sure that your contribution is integrated rapidly. The general workflow is as follows:
- Fork the repository (see Branches, etc. below)
- Create an explicitly named branch from
develop
(if present) ormaster
- Create a pull request even if you haven't pushed code yet
- 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.
The tagged versions of anything on master
are stable releases. The master
branch itself is the latest version, but it must always work (after the first
tagged release). For more intensive development, use the develop
branch, or
feature-specific branches. All significant branches are under continuous
integration and code coverage analysis.
We use semantic versioning (major
.minor
.patch
). Anything that adds
no new feature should increase the patch
number, new non-API-breaking changes
should increase minor
, and major changes should increase major
. Any increase
of a higher level resets the number after it (e.g, 0.3.1
becomes 1.0.0
for
the first major release). It is highly recommended that you do not start working
on API-breaking changes without having received a go from us first.