Skip to content

Latest commit

 

History

History
86 lines (56 loc) · 4.99 KB

CONTRIBUTING.md

File metadata and controls

86 lines (56 loc) · 4.99 KB
Raw

Contributing to Atom

The following is a set of guidelines for contributing to fatigue and its packages. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table Of Contents

Code of Conduct

How Can I Contribute?

Styleguides

Additional Notes

Code of Conduct

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code.

How Can I Contribute?

Reporting Bugs

Before creating bug reports, please check existing issues as you might find out that there is an existing issue for the bug. Fill out the required template, the information it asks for helps us resolve issues faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion for fatigue, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion and find related suggestions. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

Your First Code Contribution

Unsure where to begin contributing to Atom? You can start by looking through these beginner and help-wanted issues:

  • Beginner issues - issues which should only require a few lines of code, and a test or two.
  • Help wanted issues - issues which should be a bit more involved than beginner issues.

Local development

Included in the examples directory is a great test api to test fatigue with. The example api can be started by simply running cargo run from the test api directory. Feel free to add any functionality that may be needed to test your features to the test api. Linting and normal code quality rules do not apply to that project, but please, don't use it like a garbage bin.

Pull Requests

Please follow these steps to have your contribution considered by the maintainers:

  1. Create or reference an existing issue for your pull request.
  2. Follow the styleguides
  3. After you submit your pull request, verify that all status checks are passing
    What if the status checks are failing?If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.

While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.

Styleguides

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • Use conventional commits:
    • break: the change contains breaking changes to the command line interface or configuration file format. (the library is nowhere near being any kind of stable, and as such we aren't even going to worry about that for now.)
    • feat: the change adds a new feature
    • fix: the change fixes an existing feature
    • doc: the change only updates documentation
    • ci: the change updates ci/cd
    • chore: dependency updates, or anything else not related to actual code

Rust Stylguide

  • No clippy warnings
  • No build warnings
  • Use cargo-sort to keep crates tidy