Mirrors/clap
2
0
Fork 0
mirror of https://github.com/clap-rs/clap synced 2024-11-10 06:44:16 +00:00
Code Issues Projects Releases Packages Wiki Activity

chore: updates the contributing instructions

Browse source
This commit is contained in:
Kevin K 2016-12-30 21:23:19 -05:00
parent 7eb949ba38
commit 85ea57835d
No known key found for this signature in database
GPG key ID: 17218E4B3692F01A
2 changed files with 41 additions and 28 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
.clog.toml
View file

@ -8,4 +8,6 @@ Performance = ["perf"]
Improvements = ["impr", "im", "imp"]
Documentation = ["docs"]
Deprecations = ["depr"]
Examples = ["examples"]
Examples = ["examples"]
"New Settings" = ["setting", "settings"]
"API Additions" = ["add", "api"]

65
.github/CONTRIBUTING.md vendored
View file

@ -2,33 +2,6 @@
Contributions are always welcome! Please use the following guidelines when contributing to `clap`
1. Fork `clap`
2. Clone your fork (`git clone https://github.com/$YOUR_USERNAME/clap-rs && cd clap-rs`)
3. Create new branch (`git checkout -b new-branch`)
4. Make your changes, and commit (`git commit -am "your message"`)
* I use a [conventional](https://github.com/ajoslin/conventional-changelog/blob/a5505865ff3dd710cf757f50530e73ef0ca641da/conventions/angular.md) changelog format so I can update my changelog using [clog](https://github.com/clog-tool/clog-cli)
* In addition to the conventions defined above, I also use `imp`, `wip`, `examples`.
* Format your commit subject line using the following format: `TYPE(COMPONENT): MESSAGE` where `TYPE` is one of the following:
- `feat` - A new feature
- `imp` - An improvement to an existing feature
- `perf` - A performance improvement
- `docs` - Changes to documentation only
- `tests` - Changes to the testing framework or tests only
- `fix` - A bug fix
- `refactor` - Code functionality doesn't change, but underlying structure may
- `style` - Stylistic changes only, no functionality changes
- `wip` - A work in progress commit (Should typically be `git rebase`'ed away)
- `chore` - Catch all or things that have to do with the build system, etc
- `examples` - Changes to existing example, or a new example
* The `COMPONENT` is optional, and may be a single file, directory, or logical component. Can be omitted if commit applies globally
5. Run the tests (`cargo test --features "yaml unstable"`)
5. Run the lints (`cargo build --features lints`) (requires a nightly compiler)
6. `git rebase` into concise commits and remove `--fixup`s (`git rebase -i HEAD~NUM` where `NUM` is number of commits back)
7. Push your changes back to your fork (`git push origin $your-branch`)
8. Create a pull request! (You can also create the pull request first, and we'll merge when ready. This a good way to discuss proposed changes.)
Another really great way to help is if you find an interesting, or helpful way in which to use `clap`. You can either add it to the [examples/](examples) directory, or file an issue and tell me. I'm all about giving credit where credit is due :)
## Goals
There are a few goals of `clap` that I'd like to maintain throughout contributions.
@ -43,3 +16,41 @@ There are a few goals of `clap` that I'd like to maintain throughout contributio
* 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, exit gracefully on *end-user* error
### Commit Messages
I use a [conventional](https://github.com/ajoslin/conventional-changelog/blob/a5505865ff3dd710cf757f50530e73ef0ca641da/conventions/angular.md) changelog format so I can update my changelog automatically using [clog](https://github.com/clog-tool/clog-cli)
* Please format your commit subject line using the following format: `TYPE(COMPONENT): MESSAGE` where `TYPE` is one of the following:
- `api` - An addition to the API
- `setting` - A new `AppSettings` variant
- `feat` - A new feature of an existing API
- `imp` - An improvement to an existing feature/API
- `perf` - A performance improvement
- `docs` - Changes to documentation only
- `tests` - Changes to the testing framework or tests only
- `fix` - A bug fix
- `refactor` - Code functionality doesn't change, but underlying structure may
- `style` - Stylistic changes only, no functionality changes
- `wip` - A work in progress commit (Should typically be `git rebase`'ed away)
- `chore` - Catch all or things that have to do with the build system, etc
- `examples` - Changes to existing example, or a new example
* The `COMPONENT` is optional, and may be a single file, directory, or logical component. Parenthesis can be omitted if you are opting not to use the `COMPONENT`.
### Tests and Documentation
1. Create tests for your changes
2. **Ensure the tests are passing.** Run the tests (`cargo test --features "yaml unstable"`), alternatively `just run-tests` if you have `just` installed.
3. **Optional** Run the lints (`cargo build --features lints`) (requires a nightly compiler), alternatively `just lint`
4. Ensure your changes contain documentation if adding new APIs or features.
### Preparing the PR
1. `git rebase` into concise commits and remove `--fixup`s or `wip` commits (`git rebase -i HEAD~NUM` where `NUM` is number of commits back to start the rebase)
2. Push your changes back to your fork (`git push origin $your-branch`)
3. Create a pull request against `master`! (You can also create the pull request first, and we'll merge when ready. This a good way to discuss proposed changes.)
### Other ways to contribute
Another really great way to help is if you find an interesting, or helpful way in which to use `clap`. You can either add it to the [examples/](examples) directory, or file an issue and tell me. I'm all about giving credit where credit is due :)