From 268e1e1b78d0ff7c9f1e3909e96aa048a149741d Mon Sep 17 00:00:00 2001 From: haraldmaida Date: Sun, 18 Oct 2026 09:31:04 +0200 Subject: [PATCH 1/4] chore: add "OpenSSF Best Practices" badge to README.md --- README.md | 4 ++++ docs/cratesio/README.md | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/README.md b/README.md index 864a9c6..896224f 100644 --- a/README.md +++ b/README.md @@ -5,6 +5,7 @@ ![MSRV][msrv-badge] [![code coverage][code-coverage-badge]][code-coverage-url] [![security][security-audit-badge]][security-audit-url] +[![OpenSSF Best Practices][openssf-best-practices-bagde]][openssf-best-practices-url] Fluent assertions for tests in Rust. An extensive collection of assertions to express the intent of the expected result in a test. @@ -165,6 +166,9 @@ possibilities for custom assertions, including examples. [security-audit-url]: https://github.com/innoave/asserting/actions +[openssf-best-practices-badge]: https://www.bestpractices.dev/projects/15639/badge + +[openssf-best-practices-url]: https://www.bestpractices.dev/projects/15639 diff --git a/docs/cratesio/README.md b/docs/cratesio/README.md index 261c71e..c079cb5 100644 --- a/docs/cratesio/README.md +++ b/docs/cratesio/README.md @@ -5,6 +5,7 @@ ![MSRV][msrv-badge] [![code coverage][code-coverage-badge]][code-coverage-url] [![security][security-audit-badge]][security-audit-url] +[![OpenSSF Best Practices][openssf-best-practices-bagde]][openssf-best-practices-url] Fluent assertions for tests in Rust. An extensive collection of assertions to express the intent of the expected result in a test. @@ -165,6 +166,9 @@ possibilities for custom assertions, including examples. [security-audit-url]: https://github.com/innoave/asserting/actions +[openssf-best-practices-badge]: https://www.bestpractices.dev/projects/15639/badge + +[openssf-best-practices-url]: https://www.bestpractices.dev/projects/15639 From f0c93073b1d30be00050d5d42ea9d7f2b2624002 Mon Sep 17 00:00:00 2001 From: haraldmaida Date: Sun, 18 Oct 2026 12:37:51 +0200 Subject: [PATCH 2/4] chore: add security policy to the project (SECURITY.md) --- SECURITY.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..38dc5ac --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,19 @@ +# Security Policy + +## Supported Versions + +Only the latest released minor version of `asserting` is supported. + +| Version | Supported | +|---------------------------------------------------------------------------------------------------|--------------------| +| [![Crates.io](https://img.shields.io/crates/v/asserting.svg)](https://crates.io/crates/asserting) | :white_check_mark: | +| Previous Versions | :x: | + +## Reporting a Vulnerability + +If you believe you have found a security vulnerability, please DO NOT disclose it publicly until +we’ve had a chance to fix it. + +Please don’t report security vulnerabilities via GitHub issues, instead +[report them privately](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) +via the [Security Advisories](https://github.com/innoave/asserting/security/advisories/new) page. From b9421df16200a14b56620cc5d8489aa400391aa1 Mon Sep 17 00:00:00 2001 From: haraldmaida Date: Sun, 18 Oct 2026 12:38:12 +0200 Subject: [PATCH 3/4] chore: add CODE_OF_CONDUCT.md to the project --- CODE_OF_CONDUCT.md | 80 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..808434c --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,80 @@ +# Code of Conduct + +_This Code of Conduct is based on +the [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct) +and +the [Bevy Code of Conduct](https://github.com/bevyengine/bevy/blob/main/CODE_OF_CONDUCT.md), +which are adapted from +the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) +and the [Contributor Covenant](https://www.contributor-covenant.org)._ + +## Our Pledge + +We as members, contributors, and leaders pledge to make participation in our +community a harassment-free experience for everyone, regardless of age, body +size, visible or invisible disability, ethnicity, sex characteristics, gender +identity and expression, level of experience, education, socio-economic status, +nationality, personal appearance, race, religion, or sexual identity +and orientation. + +We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community. + +## Our Standards + +We are a community of people learning and exploring how to build better web applications +with Rust. When interacting with one another, please remember that there are no experts and there +are +no stupid questions. Assume the best in other people's communication and take a step back if +you find yourself getting defensive. + +Please note the following guidelines as well: + +* Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, + safe and welcoming environment for all. +* Please be kind and courteous. There’s no need to be mean or rude. +* Respect that people have differences of opinion and that every design or implementation choice + carries a trade-off and numerous costs. There is seldom a right answer. +* Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment + with, make a fork and see how it works. +* We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome + behavior. We interpret the term “harassment” as including the definition in + the [Citizen Code of Conduct](https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md); + if you have any lack of clarity about what might be included in that concept, please read their + definition. In particular, we don’t tolerate behavior that excludes people in socially + marginalized groups. +* Private harassment is also unacceptable. No matter who you are, if you feel you have been or are + being harassed or made uncomfortable by a community member, please contact the maintainers + immediately. Whether you’re a regular contributor or a newcomer, we care about making this + community a safe place for you and we’ve got your back. +* Do not make casual mention of slavery or indentured servitude and/or false comparisons of one's + occupation or situation to slavery. Please consider using or asking about alternate terminology + when referring to such metaphors in technology. +* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not + welcome. + +## Moderation + +These are the policies for upholding [our community’s standards of conduct](#our-standards). If you +feel that a thread needs moderation, please contact the maintainers. + +1. Remarks that violate the community standards of conduct, including hateful, hurtful, oppressive, + or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, + and never in a hateful manner). +2. Remarks that maintainers find inappropriate, whether listed in the code of conduct or not, are + also not allowed. +3. Maintainers will first respond to such remarks with a warning. +4. If the warning is unheeded, the user will be “kicked,” i.e., kicked out of the communication + channel to cool off. +5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely + excluded. +6. Maintainers may choose at their discretion to un-ban the user if it was a first offense and they + offer the offended party a genuine apology. +7. If a maintainer bans someone and you think it was unjustified, please take it up with that + maintainer, or with a different maintainer, in private. Complaints about bans in-channel are not + allowed. +8. Maintainers are held to a higher standard than other community members. If a maintainer creates + an inappropriate situation, they should expect less leeway than others. + +The enforcement policies in the code of conduct apply to all official venues, including Discord +channels, GitHub repositories, and all other forums. \ No newline at end of file From 7aa730fa00010f33b0feae936d1231d02dee8bc9 Mon Sep 17 00:00:00 2001 From: haraldmaida Date: Sun, 18 Oct 2026 20:36:20 +0200 Subject: [PATCH 4/4] chore: write first draft of the CONTRIBUTING.md guidelines --- CONTRIBUTING.md | 154 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..553dfdb --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,154 @@ +# Contributing to asserting + +`asserting` welcomes contribution from everyone in the form of suggestions, bug reports, +pull requests, and feedback. This document gives some guidance if you consider helping us. + +There are opportunities to contribute to `asserting` at any level. It doesn't matter if you are just +getting started with Rust or are the most weathered expert, we can use your help. + +**No contribution is too small and all contributions are valued.** + +This guide will help you get started. Do not let this guide intimidate you. It should be considered +a map to help you navigate the process. + +## Code of Conduct + +This project and everyone participating in it is governed by +the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected +to uphold this code. + +## Questions and Feedback + +If you have a question on using the library in your project or want to share feedback, feel free to +start a discussion at [Discussions](https://github.com/innoave/asserting/discussions). + +## Issues and Feature Requests + +### Submitting a Bug Report + +If you are facing a problem or have an idea for a new feature, please open an issue at +[Issues](https://github.com/innoave/asserting/issues). + +Please provide as much information as possible about the issue to help us diagnose and resolve it. + +* Describe the problem or feature request in detail. What did happen? And what did you expect to + happen? +* Include steps to reproduce the problem or feature request. +* Include any relevant code snippets or examples. +* Include any relevant error messages or logs. +* Include any relevant environment information, such as operating system, Rust version. +* Include any relevant links or resources that may be helpful in diagnosing or resolving the issue. + +### Submitting a Feature Request + +When making a feature request, please make it clear what problem you intend to solve with the +feature, any ideas for how `asserting` could support solving that problem, any possible +alternatives, and any disadvantages. + +### Provide supporting details to existing issues + +If you are experiencing a problem described in an existing issue, you may provide additional +information or context that might help us diagnose and resolve the issue. + +If you have a similar idea for a new feature as already mentioned in an existing issue, please add +your thoughts to that feature request or describe your point of view. + +### Resolving an Issue + +In the majority of cases, issues are resolved by opening a Pull Request. Pull Requests need to be +reviewed and approved by official project maintainers. This ensures that the proposed changes meet +the quality standard of the project. + +If you consider resolving an issue, please make sure that you have at least read and understood the +chapter [Pull Request](#pull-requests) of these contributing guidelines. + +## Pull Requests + +Pull Requests are the way concrete changes are made to the code, documentation, and dependencies in +the `asserting` repository. + +Even tiny pull requests (e.g., one-character pull request fixing a typo in API documentation) are +greatly appreciated. Before making a large change, it is usually a good idea to first open an issue +describing the change to solicit feedback and guidance. This will increase the likelihood of the PR +getting merged. + +### Code Style + +This project uses `Clippy` and `Rustfmt` as mandatory code style tools. We consider compiler and +linter warnings as errors. All errors and warnings must be resolved. + +Please do not use annotations to silence compiler and linter warnings. If you feel that silencing +a warning is the best way to proceed, please provide a reason why this is the best solution. + +There is one exception to this rule: in test code it is allowed to use `expect` on `Option` and +`Result` types. The annotation `#![allow (clippy::expect_used)]` should be placed at the top of a +test file. + +### Tests + +If the change being proposed alters code (as opposed to only adding or improving documentation, for +example), it is either adding new functionality to the crate or it is fixing existing, broken +functionality. + +In both cases it is mandatory to include tests that demonstrate the correctness of the change and +ensure that the crate does not regress in the future. + +#### Documentation Tests + +Ideally, every API has at least one documentation test that demonstrates how to use the API. The +tricky part to documentation tests is striking a balance between being succinct for a reader to +understand and actually testing the API. + +### Commits + +It is a recommended best practice to keep your changes as logically grouped as possible within +individual commits. There is no limit to the number of commits any single Pull Request may have, +and many contributors find it easier to review changes that are split across multiple commits. + +The maintainers of the project adhere to +the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) +specification. Though it is not a hard requirement to follow this specification for getting Pull +Requests merged. + +If a commit introduces a breaking change, it is recommended to include a note in the commit message +explaining the reason for the change and how it affects the API. This will help reviewers and +contributors understand the impact of the change and make informed decisions about merging the +Pull Request. + +### Submitting a Pull Request + +Before submitting a Pull Request, it is recommended to ensure that all tests pass and that the +documentation is up to date. Additionally, it is recommended to include a clear and concise +description of the changes made in the Pull Request, including any relevant context or motivation +for the change. + +This project uses the `Just` tool to help ensure code quality. The `justfile` defines the recipe +`continues-integration` that performs most of the tasks in the CI pipeline in your (local) +development environment. To execute the recipe, run `just continues-integration` or use the short +alias `just ci`. + +We heavily use `Clippy` and `Rustfmt` to ensure code quality and consistency. Please run `just ci` +before submitting a Pull Request to ensure that the code meets the project's standards. + +The CI pipeline runs on any Pull Request. Errors and warnings found by the CI pipeline must be +addressed before the Pull Request can be merged. + +### Reviewing Pull Requests + +**Any community member is welcome to review any Pull Request.** + +All contributors who choose to review and provide feedback on Pull Requests have a responsibility +to both the project and the individual making the contribution. Reviews and feedback must be +helpful, insightful, and geared towards improving the contribution as opposed to simply blocking it. +If there are reasons why you feel the PR should not land, explain what those are. Do not expect to +be able to block a Pull Request from advancing simply because you say "No" without giving an +explanation. Be open to having your mind changed. Be open to working with the contributor to make +the Pull Request better. + +Reviews that are dismissive or disrespectful of the contributor or any other reviewers are strictly +counter to the Code of Conduct. + +When reviewing a Pull Request, the primary goals are for the codebase to improve and for the person +submitting the request to succeed. Even if a Pull Request does not land, the submitters should come +away from the experience feeling like their effort was not wasted or unappreciated. Every Pull +Request from a new contributor is an opportunity to grow the community.