Skip to content

Latest commit

 

History

History
84 lines (61 loc) · 4.75 KB

CONTRIBUTING.md

File metadata and controls

84 lines (61 loc) · 4.75 KB
Raw

Welcome!

We are looking forward to changes and improvement to this package. Before you contribute, please read the Code of Conduct.

Repository structure

  • src contains all the functions, types, and methods
  • tests contains the unit tests and some integration tests

Don't know where to start?

  • report a bug or suggest an improvement -- open an issue on GitHub
  • write a vignette -- used SpatialBoundaries.jl to do something? You can add it to docs/src/examples!
  • improve the documentation -- all functions have a docstring where they are declared, and improving them is a great way to get started

Setting up your environment

Have a look at the current Julia documentation.

EMOJIS!

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
Jettisoned something :boom: 💥 manifest

Workflow

This section describes the general steps to make sure that your contribution is integrated rapidly. The general workflow is as follows:

  1. Fork the repository (see Branches, etc. below)
  2. Create an explicitly named branch from develop (if present) or master
  3. Create a pull request as soon as you make the first commit
  4. Be as explicit as possible on your goals
  5. Do not squash / rebase commits while you work -- we will do so when merging

Pull requests

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:

  1. Single purpose - it should do one thing, and one thing only
  2. Short - it should ideally involve less than 250 lines of code
  3. Limited in scope - it should ideally not span more than a handful of files
  4. Well tested and well documented
  5. Written in a style similar to the rest of the codebase

This will ensure that your contribution is rapidly reviewed and evaluated.

Branches, etc.

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