Contributions are always welcome! And there is a multitude of ways in which you can help depending on what you like to do, or are good at. Anything from documentation, code cleanup, issue completion, new features, you name it, even filing issues is contributing and greatly appreciated!
There are a few goals of `clap` that I'd like to maintain throughout contributions. If your proposed changes break, or go against any of these goals we'll discuss the changes further before merging (but will *not* be ignored, all contributes are welcome!). These are by no means hard-and-fast rules, as I'm no expert and break them myself from time to time (even if by mistake or ignorance :P).
* Remain backwards compatible when possible
- If backwards compatibility *must* be broken, use deprecation warnings if at all possible before removing legacy code
- This does not apply for security concerns
* Parse arguments quickly
- Parsing of arguments shouldn't slow down usage of the main program
- This is also true of generating help and usage information (although *slightly* less stringent, as the program is about to exit)
* Try to be cognizant of memory usage
- Once parsing is complete, the memory footprint of `clap` should be low since the main program is the star of the show
*`panic!` on *developer* error
(e.g. [apps](https://github.com/clap-rs/clap/blob/62eff1f8d3394cef819b4aa7b23a1032fc584f03/src/build/app/debug_asserts.rs) and [args](https://github.com/clap-rs/clap/blob/62eff1f8d3394cef819b4aa7b23a1032fc584f03/src/build/arg/debug_asserts.rs)),
- [Discussions](https://github.com/clap-rs/clap/discussions) can be useful for getting help and brainstorming
- [Issues](https://github.com/clap-rs/clap/issues) work well discussing a need and how to solve it
- Focus: requirements gathering and design discussions
- Sometimes a branch or Draft PR might be used to demonstrate an idea
- [PRs](https://github.com/clap-rs/clap/pulls) work well for when the solution has already been discussed as an Issue or there is little to no discussion (obvious bug or documentation fixes)
- Develop the feature behind an `unstable-<name>` feature flag with a stabilization tracking issue (e.g. [Multicall Tracking issue](https://github.com/clap-rs/clap/issues/2861))
As we work towards [a more flexible architecture](https://github.com/clap-rs/clap/discussions/3476), we hope to support multiple major versions to help ease users through the upgrade churn.
Note: We have not yet determined the End-of-Life schedule for previous major versions. We will give at least a 2 month warning before changing the support status.
A helpful technique is to see the `clap` debug output while developing features. In order to see the debug output while running the full test suite or individual tests, run:
- Add tests in a commit before their feature or fix, showing the current behavior.
The diff for the feature/fix commit will then show how the behavior changed,
making it clearer to reviewrs and the community and showing people that the
test is verifying the expected state.
- e.g. [clap#5520](https://github.com/clap-rs/clap/pull/5520)
Note that we are talking about ideals.
We understand having a clean history requires more advanced git skills;
feel free to ask us for help!
We might even suggest where it would work to be lax.
We also understand that editing some early commits may cause a lot of churn
with merge conflicts which can make it not worth editing all of the history.
For code organization, we recommend
- Grouping `impl` blocks next to their type (or trait)
- Grouping private items after the `pub` item that uses them.
- The intent is to help people quickly find the "relevant" details, allowing them to "dig deeper" as needed. Or put another way, the `pub` items serve as a table-of-contents.
