readme

Author: joannecheng

README.md

@@ -1,14 +1,13 @@
 # lambdaisland/kaocha-junit-xml
 
 <!-- badges -->
-[![CircleCI](https://circleci.com/gh/lambdaisland/kaocha-junit-xml.svg?style=svg)](https://circleci.com/gh/lambdaisland/kaocha-junit-xml) [![cljdoc badge](https://cljdoc.org/badge/lambdaisland/kaocha-junit-xml)](https://cljdoc.org/d/lambdaisland/kaocha-junit-xml) [![Clojars Project](https://img.shields.io/clojars/v/lambdaisland/kaocha-junit-xml.svg)](https://clojars.org/lambdaisland/kaocha-junit-xml)
+[![GitHub Actions](https://github.com/lambdaisland/kaocha-junit-xml/actions/workflows/main.yml/badge.svg)] [![cljdoc badge](https://cljdoc.org/badge/lambdaisland/kaocha-junit-xml)](https://cljdoc.org/d/lambdaisland/kaocha-junit-xml) [![Clojars Project](https://img.shields.io/clojars/v/lambdaisland/kaocha-junit-xml.svg)](https://clojars.org/lambdaisland/kaocha-junit-xml)
 <!-- /badges -->
 
 [Kaocha](https://github.com/lambdaisland/kaocha) plugin to generate a JUnit XML version of the test results.
 
 <!-- opencollective -->
-
-## Support Lambda Island Open Source
+## Lambda Island Open Source
 
 Thank you! kaocha-junit-xml is made possible thanks to our generous backers. [Become a
 backer on OpenCollective](https://opencollective.com/lambda-island) so that we
@@ -22,20 +21,17 @@ can continue to make kaocha-junit-xml better.
 
 &nbsp;
 
-kaocha-junit-xml is part of a growing collection of quality Clojure libraries and
-tools released on the Lambda Island label. If you are using this project
-commercially then you are expected to pay it forward by
-[becoming a backer on Open Collective](http://opencollective.com/lambda-island#section-contribute),
-so that we may continue to enjoy a thriving Clojure ecosystem.
+kaocha-junit-xml is part of a growing collection of quality Clojure libraries created and maintained
+by the fine folks at [Gaiwan](https://gaiwan.co).
 
-&nbsp;
+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.
 
-&nbsp;
+You can find an overview of all our different projects at [lambdaisland/open-source](https://github.com/lambdaisland/open-source).
 
 &nbsp;
 
 &nbsp;
-
 <!-- /opencollective -->
 
 ## Usage
@@ -206,39 +202,35 @@ Notably, CircleCI's [parallelization](https://circleci.com/docs/use-the-circleci
 <!-- contributing -->
 ## Contributing
 
-Everyone has a right to submit patches to kaocha-junit-xml, and thus become a contributor.
-
-Contributors MUST
+We warmly welcome patches to kaocha-junit-xml. 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 EPL 1.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 EPL 1.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-2020 Arne Brasseur and contributors
+Copyright &copy; 2018-2025 Arne Brasseur and contributors
 
 Available under the terms of the Eclipse Public License 1.0, see LICENSE.txt
-<!-- /license -->
+<!-- /license -->