Merge rust-bitcoin/rust-bitcoin#4119: chore: remove redundant words in CONTRIBUTING.md

083a33af85 chore: remove redundant words in CONTRIBUTING.md (costcould)

Pull request description:

ACKs for top commit:
  tcharding:
    ACK 083a33af85
  apoelstra:
    ACK 083a33af85d6e6fb9080049b21fd3ddeb79a63de; successfully ran local tests

Tree-SHA512: 7ec7d6f4a38630a1c2ab73674d431c8950eed6569589f16a6ae48425de39eb94e11a35f865e32d721f1ff0d51ebef0604ad0bc7236e37f666473405b2e2cd6ab
This commit is contained in:
merge-script 2025-02-27 20:39:59 +00:00
commit 4f895a7b4e
No known key found for this signature in database
GPG Key ID: C588D63CE41B97C1
1 changed files with 2 additions and 2 deletions

View File

@ -130,7 +130,7 @@ adhere to the ideas presented in the following two blog posts:
Whenever any part of your code wants to mention the version number the code will
be released in, primarily in deprecation notices, you should use the string
`TBD` (verbatim), so that the release preparation script can detect the
change and the correct version number can be filled in in preparation of the
change and the correct version number can be filled in preparation of the
release.
```rust
@ -360,7 +360,7 @@ All errors that live in an `error` module (eg, `foo/error.rs`) and appear in a p
With respect to `expect` messages, they should follow the
[Rust standard library guidelines](https://doc.rust-lang.org/std/option/enum.Option.html#recommended-message-style).
More specifically, `expect` messages should be used to to describe the reason
More specifically, `expect` messages should be used to describe the reason
you expect the operation to succeed.
For example, this `expect` message clearly states why the operation should succeed: