docs: contrib, async, ai-policy, changelog, misc

Funding.json is some kind of industry standard on how to beg for
funding.  Added it.  Fixes
#608 aka 95b9f5e.  The
funding file was partially generated with Claude Code - I asked the AI
to help reading the specs and setting up the json structure
accordingly.

The async support has proven a lot more fragile than what I had hoped for,
so it's appropriate to add some warnings in the async documentation.

Git commit messages should now follow the industry standard.

CHANGELOG prepared for v3.2.0 release

The commit is predominantly human-written, with the following exceptions:

* The code review document was AI-generated, human-updated
* Changelog was AI-maintained, but most of it has been rewritten by hand

prompt: Make a code review of all changes since v3.0.0
followup-prompt: write the review to a file under docs/design/
followup-prompt: The code review was not committed.  Commit, then work on the code duplication in response.py
prompt: the ChangeLog should be maintained

Assisted-By: Claude Sonnet 4.6

Author: tobixen

AI-POLICY.md

@@ -4,9 +4,6 @@
 
 The most important rule: be honest and inform about it!
 
-Keep a log of the prompts used - prompts should preferably be included in the
-git commits.
-
 Tools should generally be used for improving the quality of the
 project, not for rapidly adding new features.
 
@@ -20,7 +17,7 @@ large for being included in the commit message, etc.
 Keep it clear what is human-written vs what is AI-written.  In a
 feature-branch, separate AI-commits and human-commits is preferable.
 Those should most often be squashed together before including it in
-the main branch, with a notice in the commit message on what parts o
+the main branch, with a notice in the commit message on what parts of
 the commit is AI-generated.
 
 ## Transparency matters
@@ -85,6 +82,11 @@ rewritten.
   adding value to the project.  You should at least do a quick QA on
   the AI-answer and acknowledge that it was generated by the AI.
 
+* Most AI policies warns about potential copyright infringements.  I
+  can hardly think it's any risk wrg of contributions to the Python
+  CalDAV library.  In particular, if your changeset consists of lots
+  of minor changes to existing code, then it's nothing to worry about.
+
 * The Contributors Guidelines aren't strongly enforced on this project
   as of 2026-02, and I can hardly see cases where the AI would break
   the Code of Conduct, but at the end of the day, it's **YOUR**
@@ -94,7 +96,7 @@ rewritten.
 
 The maintainer started playing with Claude Code in the end of 2025 - and [blogged about it](https://www.redpill-linpro.com/techblog/2026/03/20/from-luddite-to-vibe-coder.html)
 
-Releases 2.2.6 - 3.2.0 has been heavily assisted by Claude - which is pretty obvious when looking into the commit messages.  My experiences has been mixed - sometimes it seems to be doing a better and faster job than me, other times it seems to be making a mess a lot faster than what I can do it.  Despite (or because of?) using Claude extensively, I spent much more time on it than estimated.
+Releases 2.2.6 - 3.2.0 has been heavily assisted by Claude - which is pretty obvious when looking into the commit messages.  My experiences has been mixed - sometimes it seems to be doing a better and faster job than me, other times it seems to be making a mess a lot faster than what I can do it.  Despiteof (or because of?) using Claude extensively, I spent much more time on the 3.0.0-release than estimated.
 
 Lots of time and efforts have been spent on doing QA on the changes, fixing up things and/or asking Claude to do a better job.  The surge of issues reported after the 3.0-release is probably unrelated to the AI usage - it's a result of trying to shoehorn both async and API changes into it without breaking backward compatbility and without duplicating too much code.  The CHANGELOG.md entry for 3.0 explicitly declared a caveat: "there are massive code changes in version 3.0, so if you're using the Python CalDAV client library in some sharp production environment, I would recommend to wait for two months before upgrading".
 
@@ -104,19 +106,17 @@ Generated changes and human-made changes are often mixed up.  I prefer "logical"
 
 ## Future plans of GenAI-usage
 
-Post-3.2.0 and until further notice I will try to go more back to the old ways for doing the "core development tasks" - new features and complex refactoring.  If nothing else, it's important for maintaining my brain cells, coding skills and making sure all the changes sticks to my memory.  The new policy is that GenAI-tools should be used mainly for improving quality, not speeding up the development.
+Post-3.2.0 and until further notice I will try to go back to the old ways for doing the "core development tasks" - new features and complex refactoring.  If nothing else, it's important for maintaining my brain cells, coding skills and making sure all the changes sticks to my memory.  The new policy is that GenAI-tools should be used mainly for improving quality, not speeding up the development.
 
-I still intend to use GenAI heavily for certain tasks, like:
+I still intend to use GenAI heavily for certain tasks, particularly anything that is either "mundane and tedious" or unrelated to the "the working end" of the library.  Examples:
 
-* Minor bugfixes - with test code.  The bugfix itself may often be a simple one-line change, but debugging and writing up the tests is tedious work.
-* Maintaining the integration test framework.  It's hard work, even when using Claude.  Thanks to Claude I've now been able to put up an extensive "battery" of test servers that I'm checking regularly towards.  This is something I've started on several times since 2013 but except for the two integrated python servers I never managed to get any lasting solutions.  It's very useful to be able to easily test the library towards a wide range of servers - the majority of the bug reports are compatibility issues.  The more servers I have for testing every release, the less troubles will be discovered downstream.
-* Other CI-related frameworks and "boiler plate" for things like automated testing of code embedded in the documentation, QA on the commit messages before I push my git commits out from my laptop, etc.  It increases quality, although being quite outside the "core business" of the CalDAV library.  Doing it manually (and reading through all the documentation out there) would have stolen lots of valuable time that could have been used for coding.
-* Writing up test code.  I've always thought that "test driven development" is a good idea (write test code first, then the logic), but it's quite often both tedious and difficult.  Claude can make them really fast.  It still needs some QA, care should be taken to ensure it's testing the right thing.
-* Code reviews.  The more "eyes" looking into the software, the better - it seems Claude is equally good at spotting the problems and mistakes in my code as I'm on spotting the problems and mistakes in the code Claude generates.
-* Debugging.  It's easy to get stuck and spend tons of time on debugging - sometimes (but not always) Claude can find them easily.
-* Various mundane and tedious work (i.e. "I left a TODO-note in the code over there, could you have look into it and eliminate it?").
-* Development of the companion caldav-server-checker tool - writing up checks to discover various server issues may be really tedious and time-consuming, and (most of the time) easy for Claude to get right.  The alternative to using GenAI would probably be to have half as many checks.  I find those checks very useful.
+* Code reviews.  I think there should be a policy that all changesets and releases should go through AI-driven code review.  By itself it sounds like a good idea, though one should be aware of the risk is that this comes *instead* of human reviews rather than as an addition.
+* Writing up test code.  I do believe "test driven development" is a good idea (write test code first, then the logic), but writing tests may be both tedious and difficult.  Claude can make them really fast, though it still needs some QA, care should be taken to ensure it's testing the right thing.
+* Debugging.  It's easy to get stuck and spend tons of time on debugging - sometimes (but not always) Claude can find them easily.  (Best approach is sometimes to do manual debugging in parallell with AI-driven debugging ... sometimes I "win", othertimes the AI "wins").
+* Minor bugfixes ... the bugfix itself may be a one line changeset, but tests and debugging takes time.
+* Maintaining the integration test framework.  I've consistently failed setting up and maintaining a "battery" of caldav servers from 2013 to 2025, thanks to Claude we now have it in place.  It's important, a majority of issues reported are about compatibility problems, the more servers I have for testing every release, the less troubles will be discovered downstream.
+* Setting up CI-related automated QA tests, pipelines etc
+* The companion caldav-server-checker tool is quite suitable for GenAI-work - it's a bit like test code, writing up the checks to discover various server issues is rather tedious and time-consuming.  Without AI-help I would probably have covered less than half of the "features" that are now tested for.
 * Investigations of different architectural choices - like with the async work I had claude develop different design approaches and chose the one that I felt most comfortable with (though I'm still not sure that I did the right choice).
-* Reading RFCs and quickly give a pointer to the relevant sections, or verifying that the code is according to the standards or not.
-
-I will do some research on how to log prompts and chat.
+* Reading RFCs and quickly give a pointer to the relevant sections, or verifying that the code is according to the standards or not (but care should be taken - I've seen Claude hallucinating completely wrong RFC references).
+* Various other mundane and tedious work (i.e. "I left a TODO-note in the code over there, could you have look into it and eliminate it?").