chore: add project guidelines

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.

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.

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
 
 <!-- External Links -->
 

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.

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
 
 <!-- External Links -->