CONTRIBUTING.md

Contribution Guidelines

Issues

This repository contains issue templates for bugs and feature requests.
Unclear documentation or error messages are considered bugs.

For anything else, please use the "Custom issue" template.

Pull Requests

Code Style

Please keep your code human-readable.

Meta data

Please add yourself to each copyright holders list of LICENSE-APACHE and LICENSE-MIT when contributing, or alternatively include a note in your pull request that you intentionally didn't do so.

Nicknames and entries without email addresses are fine, too.

For substantial contributions (basically anything more than typo or grammar fixes), feel free to add yourself to the authors list in Cargo.toml. This explicitly includes documentation changes, testing and bug fixes that just happen to be not much code.

Optional: Update CHANGELOG.md

I use the following format for an upcoming release with contributed changes:

## next

TODO: Date

- Revisions:
  - Change title (contributed by @<your GitHub @> in #<PR #>)
    > Further description or motivation, if necessary.

When adding your change, replace:

• Revisions with Features or **Breaking changes**, if your contribution falls into one of those categories instead.
• <your GitHub @> with your GitHub username.
• <PR #> with the id of your pull-request. (Squashing is optional)
• Change title and > Further description… as appropriate.

See non-contributed changes from earlier releases for examples.

Labels

Don't worry about these too much.

You're encouraged to add any that seem applicable where possible, but I'll otherwise just take care of it.

(Don't undo changes I make to labels without immediate reason.)

See https://github.com/Ameyanagi/chemical-formula-rs/issues/labels for details on individual labels.

Categories

• Assorted

  Labels without prefix like breaking, good first issue or help wanted.

• domain:

  Categorises changes by domain. Mostly not necessary.

• effort:

  Relative effort required. There's no specific unit of measurement.

• priority:

  Vaguely informs my schedule, cross-repository.

  You're welcome to let me know that (and ideally why) you'd like to see a specific change and I'll take that into account.

  -->

• state:

  General scheduling categories. See label descriptions for details!

  Rarely, more than one may be applicable.

• type:

  General problem or change domain categories.

  Only one of these should be used at a time.

• work:

  These are inspired by the Cynefin framework to categorise the type of work done or required.

  I adjusted the labels to be a bit friendlier and more expressive. See the label descriptions for details.

  The unknown category at the centre is not labelled explicitly.