CONTRIBUTING.md

In UBC-MDS/ColourblindR: Package That Creates Themes That Make Plots Accessible For People With Colour Blindness

Contributing

By participating in this project, you agree to abide by the Code of Conduct.

This is an open source project, and we welcome all contributions of all kinds: - New themes - New functions - New colour palettes - Fixes to functions - New ideas!

How to Contribute

The easiest way to get started is to file an issue to tell us about a mistake, awkward wording, or a factual error. This is a good way to introduce yourself.

1. If you do not have a GitHub account, you can open one here.

2. If you have a GitHub account, but do not know how to use Git, you can report problems or suggest improvements by creating an issue. This allows us to assign the item to someone and to respond to it in a threaded discussion.

3. If you are comfortable with Git, and would like to resolve an existing issue or typos/bugs, you can submit a pull request (PR). If you'd like to suggest substantial changes such as removing or adding features in the package, please first raise an issue to allow the maintainers to comment, so we can discuss whether/how these changes should be made.

Quick contribution tips and guidelines

This section gives the experienced contributor some tips and guidelines.

Pull requests are always welcome

Not sure if that typo is worth a pull request? Found a bug and know how to fix it? Do it! We will appreciate it. Any significant improvement should be documented as a GitHub issue before anybody starts working on it.

We are always thrilled to receive pull requests. We do our best to process them quickly. If your pull request is not accepted on the first try, don't get discouraged!

Commit Messages

Commit messages must start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.

Commit messages should follow best practices, including explaining the context of the problem and how it was solved, including in caveats or follow up changes required. They should tell the story of the change and provide readers understanding of what led to it.

If you're lost about what this even means, please see How to Write a Git Commit Message for a start.

If you squash a series of commits, don't just submit that. Re-write the commit message, as if the series of commits was a single stroke of brilliance.

That said, there is no requirement to have a single commit for a PR, as long as each commit tells the story. For example, if there is a feature that requires a package, it might make sense to have the package in a separate commit then have a subsequent commit that uses it.

Remember, you're telling part of the story with the commit message.

Attributions

• This contributing guide is based on:
• Moby Project Contributing Guidelines
• Software Carpentry Contributing Guidelines

UBC-MDS/ColourblindR documentation built on May 28, 2020, 8:29 p.m.