Hi there! Interested in contributing? We'd love to have you!
If you're new to Rust or to this project and just want an easy issue to get started with, check out the issues with the experience-easy label. If you have any questions about anything, feel free to contact joshlf or ezrosent.
All issues are labeled with the difficulty (experience-easy, experience-medium, and experience-hard) and the component of the project that they apply to (e.g., crate-elfmalloc, travis-ci, etc). Use label search or browse the issues to find something you're interested in.
Once you've found an issue to work on, please comment on it so that people know you're working on it and don't duplicate your work.
Since we're a small project, we haven't assigned particular mentors for particular issues. However, we're happy to mentor anybody working on any issue, so if you'd like mentorship on working through an issue, don't hesitate to reach out!
We use GitHub PRs to accept and review changes. In order to submit a change:
- Fork this repository
- Make the change in your fork
- Open a PR with your changes
PRs should abide by the following guidelines, but if you aren't sure about how to do that, feel free to submit a work-in-progress PR and we'll help you out.
The following tests are automatically run by Travis CI when a PR is submitted. Since Travis can be slow, it's probably best to make sure they pass by running them locally before pushing changes.
cargo clippymust not show any warningscargo testmust pass- If there are any features for the crate, then
cargo clippyandcargo testshould also be run with each of the features enabled
Please add tests for any significant changed or added features. If you're not sure where tests should go or how they should be written, just ask and we'd be happy to help!
Providing clean, ergonomic APIs are important. If you're adding or modifying APIs, please take care to design them with the user in mind. See the Rust API Guidelines for more detailed recommendations.
All public-facing APIs should have documentation which abides by RFC 505. Try running cargo doc --open to compile and view documentation in the browser to see if it looks as you expect.
Commit messages should be of the form <component>: <description>, where the description is written in the third person singular present imperative form, and doesn't have a period at the end. What a mouthful! Basically, this means a description like "Do the thing." For example, slab-alloc: Add documentation comments.
Each crate has its own CHANGELOG.md file, and unreleased changes are tracked in the "Unreleased" section at the top of the file. Any changes that you make should be added to this section so that they can be incorporated into the changelog entry for the next release. Our changelogs follow the keep a changelog format.
Every new file should bear the following copyright comment at the top, preceding any other text:
// Copyright 2017 the authors. See the 'Copyright and license' section of the
// README.md file at the top-level directory of this repository.
//
// Licensed under the Apache License, Version 2.0 (the LICENSE-APACHE file) or
// the MIT license (the LICENSE-MIT file) at your option. This file may not be
// copied, modified, or distributed except according to those terms.Modified files should have the copyright dates updated. For example, if a file's comment reads Copyright 2017, but it is modified in 2018, then the comment should be updated to read Copyright 2017-2018.
All changes should be rebased onto the master branch so that we maintain a linear history. If you're not sure how to do that, just ask! For a good introduction to rebasing and why it's helpful, see here.
We follow the Rust Code of Conduct.