Thanks for taking the time to help this project improve! All contributions are helpful and welcome.
If you just have a question about the library or need help, the best way you can get support is by creating a post in the Q&A Discussions category or by asking in the project's Discord Server.
If something is not working as expected, you can use the repository's Issues page to report it. Before creating a bug report, use the search bar to make sure that what you're experiencing isn't already a known issue.
If the issue you found is closed, feel free to make a new one, but it helps to link the one you found under the Additional information header.
If the issue you found is open, the best way to help is by leaving a comment on it, describing your experience.
If the problem you're reporting is a typo or a just a simple mistake, you might want to use the Small issue template in the next step.
When creating your report, you should use the Bug report issue template to be provided with a list of questions that will help describe the problem you are having.
Additionally, try to do the following:
- Give the issue a clear and concise title.
- Fill out as many of the template's headers as possible.
- Provide a code sample to help readers reproduce the issue.
- Provide your Rust version, pros-rs version, and operating system.
- If you have screenshots, photos, or videos, attach them to the GitHub issue.
- Explain when the problem started happening. Was it after a recent update? Or has it always been an issue?
First of all, thanks for wanting to share your idea! Feature requests help this project grow.
Before submitting your suggestion, please consider the following:
- Your idea may have already been discussed. Use the Issues search bar to see if there are any similar suggestions.
- Your idea should be within the project's scope. The goal of this project is to provide an opinionated Rust framework for developing VEX V5 robots.
When creating your report, you should use the Feature request issue template to be provided with a list of questions that will help describe the suggestion you are submitting.
Additionally, try to do the following:
- Give the issue a clear and concise title.
- Fill out as many of the template's headers as possible.
- Provide code samples, photos, or videos to help readers understand what you're saying.
- Consider how the suggestion would be implemented.
The simplest ways to start contributing code to pros-rs are by checking the TODO list or by finding an Issue to tackle. Each one requests changes to the project, and some are more involved than others. Issues with the good first issue label are good candidates for your first contribution.
When you're ready to start coding, fork the project, then use git clone or gh repo clone to clone the repository.
.github/: CI workflows & issue/pull request templates.devcontainer/: GitHub Codespaces configuration.vscode/: Visual Studio Code configuration.cargo/: Cargo configurationpros/: Project source codepros-sys/: C bindings source codeflake.nix: Nix package configuration
All Rust source code should be formatted with Rustfmt, by running cargo fmt after making changes.
Use Clippy to lint your changes: cargo clippy.
In files not formatted by Rustfmt, there should be no trailing whitespace, the end of line sequence should be LF (line feed), and the file should end with one trailing newline.
All pros-rs projects use Conventional Commits to keep commit messages informational. Conventional commits have the following form:
type(OptionalScope): description
[optional body]
[optional footers]
Here is an example of a conforming commit message:
docs(contributing): add Acknowledgements section
From this commit, you can easily see that the commit altered docs in the contributing guidelines file by adding an Acknowledgements section. When writing the commit description, make sure to use the present imperative tense ("add ABC" instead of "added ABC" or "adds ABC"). It might help to imagine that you are telling someone to do something ("go add ABC").
Here is a list of common commit types:
| Type | Description |
|---|---|
| chore | Changes to workspace & configuration files |
| feat | New features |
| fix | Bug fixes |
| refactor | Changes to internal features but not the external interface |
| revert | Reversion of a previous change |
| style | Changes to code style and formatting |
| test | Changes or additions to unit tests |
| types | Changes to type definitions |
| docs | Changes to documentation files |
After making changes to your code, update the Unreleased section of the changelog with what you changed. Breaking changes should be painfully clear, so list all deprecations, removals, and generic breaking changes. Include your pull request's number. See the example below for the recommended format.
## [Unreleased]
### Added
### Fixed
### Changed
+ * All functions in the `foo` module now
+ must be passed a Bar struct. (**Breaking change**) (#30)
### Removed
+ * Removed the deprecated `bar` module. Use the
+ `foo` module instead. (**Breaking change**) (#28)
### Deprecated
+ * The `Baz` struct is now deprecated. (#28)When you're ready for your changes to be merged, head over to the Pull Requests page and create a new pull request. Include a description of what changed, and link to an Issue if applicable. Pull request names should follow the same conventions as commit messages.
If you're not quite done with the changes but are ready to start sharing them, you can mark it as a draft to prevent it from being merged.
Once your pull request has been merged, congrats! Your changes will be mentioned in the next release's changelog.
This CONTRIBUTING.md file contains excerpts from and was inspired in part by the Atom editor's CONTRIBUTING.md. Click here to go check it out.