Update README

Author: plexus

README.md

@@ -264,17 +264,25 @@ When not using `*debug*` you can still set these log levels separately through
 <!-- opencollective -->
 ## Lambda Island Open Source
 
+Thank you! kaocha-cljs is made possible thanks to our generous backers. [Become a
+backer on OpenCollective](https://opencollective.com/lambda-island) so that we
+can continue to make kaocha-cljs better.
+
+<a href="https://opencollective.com/lambda-island">
+<img src="https://opencollective.com/lambda-island/organizations.svg?avatarHeight=46&width=800&button=false">
+<img src="https://opencollective.com/lambda-island/individuals.svg?avatarHeight=46&width=800&button=false">
+</a>
 <img align="left" src="https://github.com/lambdaisland/open-source/raw/master/artwork/lighthouse_readme.png">
 
 &nbsp;
 
 kaocha-cljs is part of a growing collection of quality Clojure libraries created and maintained
 by the fine folks at [Gaiwan](https://gaiwan.co).
 
-Pay it forward by [becoming a backer on our Open Collective](http://opencollective.com/lambda-island),
-so that we may continue to enjoy a thriving Clojure ecosystem.
+Pay it forward by [becoming a backer on our OpenCollective](http://opencollective.com/lambda-island),
+so that we continue to enjoy a thriving Clojure ecosystem.
 
-You can find an overview of our projects at [lambdaisland/open-source](https://github.com/lambdaisland/open-source).
+You can find an overview of all our different projects at [lambdaisland/open-source](https://github.com/lambdaisland/open-source).
 
 &nbsp;
 
@@ -284,39 +292,35 @@ You can find an overview of our projects at [lambdaisland/open-source](https://g
 <!-- contributing -->
 ## Contributing
 
-Everyone has a right to submit patches to kaocha-cljs, and thus become a contributor.
-
-Contributors MUST
+We warmly welcome patches to kaocha-cljs. Please keep in mind the following:
 
 - adhere to the [LambdaIsland Clojure Style Guide](https://nextjournal.com/lambdaisland/clojure-style-guide)
-- write patches that solve a problem. Start by stating the problem, then supply a minimal solution. `*`
-- agree to license their contributions as MPL 2.0.
-- not break the contract with downstream consumers. `**`
-- not break the tests.
+- write patches that solve a problem 
+- start by stating the problem, then supply a minimal solution `*`
+- by contributing you agree to license your contributions as MPL 2.0
+- don't break the contract with downstream consumers `**`
+- don't break the tests
 
-Contributors SHOULD
+We would very much appreciate it if you also
 
-- update the CHANGELOG and README.
-- add tests for new functionality.
+- update the CHANGELOG and README
+- add tests for new functionality
 
-If you submit a pull request that adheres to these rules, then it will almost
-certainly be merged immediately. However some things may require more
-consideration. If you add new dependencies, or significantly increase the API
-surface, then we need to decide if these changes are in line with the project's
-goals. In this case you can start by [writing a pitch](https://nextjournal.com/lambdaisland/pitch-template),
-and collecting feedback on it.
+We recommend opening an issue first, before opening a pull request. That way we
+can make sure we agree what the problem is, and discuss how best to solve it.
+This is especially true if you add new dependencies, or significantly increase
+the API surface. In cases like these we need to decide if these changes are in
+line with the project's goals.
 
-`*` This goes for features too, a feature needs to solve a problem. State the problem it solves, then supply a minimal solution.
+`*` This goes for features too, a feature needs to solve a problem. State the problem it solves first, only then move on to solving it.
 
-`**` As long as this project has not seen a public release (i.e. is not on Clojars)
-we may still consider making breaking changes, if there is consensus that the
-changes are justified.
+`**` Projects that have a version that starts with `0.` may still see breaking changes, although we also consider the level of community adoption. The more widespread a project is, the less likely we're willing to introduce breakage. See [LambdaIsland-flavored Versioning](https://github.com/lambdaisland/open-source#lambdaisland-flavored-versioning) for more info.
 <!-- /contributing -->
 
 <!-- license -->
 ## License
 
-Copyright &copy; 2018-2021 Arne Brasseur and Contributors
+Copyright &copy; 2018-2025 Arne Brasseur and Contributors
 
 Licensed under the term of the Mozilla Public License 2.0, see LICENSE.
-<!-- /license -->
+<!-- /license -->