Various document fixes

Had a brief look into most of the documents in the root folder, and updated them a bit

Author: tobixen

AI_POLICY.md

@@ -0,0 +1,75 @@
+# Policy on usage of Artifical Intelligence and other tools
+
+## Background
+
+From time to time I do get pull requests where the author has done
+little else than running some tool on the code and submitting it as a
+pull request.  Those pull requests may have value to the project, but
+it's dishonest to not be transparent about it; teaching me how to run
+the tool and integrating it into the CI workflow may have a bigger
+value than the changes provided by the tool.  Recently I've also
+started receiving pull requests with code changes generated by AI (and
+I've seen people posting screenshots of simple questions and answers
+from ChatGPT in forum discussions, without contributing anything else).
+
+As of 2025-11, I've spent some time testing Claude.  I'm actually
+positively surprised, it's doing a much better job than what I had
+expected.  The AI may do things faster, smarter and better than a good
+coder.  Sometimes.  Other times it may spend a lot of "tokens" and a
+long time coming up with sub-optimal solutions, or even solutions that
+doesn't work at all.  Perhaps at some time in the near future the AI
+will do the developer profession obsoleted - but as of 2025-11, my
+experiences is that the AI performs best when being "supervised" and
+"guided" by a good coder knowing the project.
+
+## The rules
+
+* Do **respect the maintainers time**.  If/when the maintainer gets
+  overwhelmed by pull requests of questionable quality or pull
+  requests that do not pull the project in the right direction, then
+  it will be needed to add more requirements to the Contributors
+  Guidelines.
+
+* **YOU should add value to the project**. If your contribution
+  consists of nothing else than using a tool on the code and
+  submitting the resulting code, then the value is coming from the
+  tool and not from you.  I could probably have used the tool myself.
+  Ok, so you may have done some research, found the tool, installed it
+  locally, maybe paid money for a subscription, for sure there is some
+  value in that - but if you end up as a messenger copying my comments
+  to some AI tools and copying the answer back again - then you're not
+  delivering value anymore, then it would be better if the AI tool
+  itself would be delivering the pull request and responding to my
+  comments.
+
+* **YOU should look through and understand the changes**.  The change
+  goes into the project attributed to your name (or at least github
+  handle), so I do expect you to at least understand the change you're
+  proposing.
+
+* **Transparency** is important.  Ok, so a lot of tools may have been
+  used while writing the pull request, I don't need to know all the
+  details, but if a significant part of the changes was generated by
+  some tool or by some AI, then that should be informed about.
+  I.e. if your job was to run `ruff` on the code and found some
+  imporant things that should be changed, then don't write "I found
+  this issue and here is a fix", but rather "I ran the ruff tool on
+  the code, found this issue, and here is the fix".  If some AI was
+  used for generating significant parts of the code changs, then it
+  should be informed about both in the pull request itself and in the
+  git commit message.  The most common way to do this is to add
+  "Assisted-by: (name of AI-tool)" at the end of the message.  Claude
+  seems to sign off with "Co-Authored-By: Claude
+  <noreply@anthropic.com>" when it's doing commits, that's also OK.
+
+* **YOU** should be ready to follow up and respond to feedback and
+  questions on the contribution.  If all you do is to relay it to the
+  AI and relaying the AI thoughts back to the pull request, then
+  you're not adding value to the project and you're not transparent
+  and honest.  You should at least do a quick QA on the AI-answer and
+  acknowledge that it was generated by the AI.
+
+* The Contributors Guidelines aren't strongly enforced on this project
+  as of 2025-12, and I can hardly see cases where the AI would break
+  the Code of Conduct, but at the end of the day **YOU** should take
+  care to ensure the contribution follows those guidelines.

CHANGELOG.md

@@ -44,10 +44,7 @@ Highlights:
 ### Changed
 
 * Transparent handling of calendar servers not supporting sync-tokens.  The API will yield the same result, albeit with more bandwidth and memory consumption.
-* I'm still working on "compatibility hints".  Unfortunately, documentation is still missing.  The gist of it:
-  * Use `features: posteo` instead of `url: https://posteo.de:8443/` in the connection configuration.
-  * Use `features: nextcloud` and `url: my.nextcloud.provider.eu` instead of `url: https://my.nextcloud.provider.eu/remote.php/dav`
-  * Or even easier, use `features: nextcloud` and `username: tobixen@example.com`
+* I'm still working on "compatibility hints".  Unfortunately, documentation is still missing.
 * **Major refactoring!**  Some of the logic has been pushed out of the CalDAV package and into a new package, icalendar-searcher.  New logic for doing client-side filtering of search results have also been added to that package.  This refactoring enables possibilities for more advanced search queries as well as client-side filtering.
   * For advanced search queries, it's needed to create a `caldav.CalDAVSearcher` object, add filters and do a `searcher.search(cal)` instead of doing `cal.search(...)`.
 * **Server compatibility improvements**: Significant work-arounds added for inconsistent CalDAV server behavior, aiming for consistent search results regardless of the server in use. Many of these work-arounds require proper server compatibility configuration via the `features` / `compatibility_hints` system. This may be a **breaking change** for some use cases, as backward-bug-compatibility is not preserved - searches may return different results if the previous behavior was relying on server quirks.
@@ -64,6 +61,9 @@ Highlights:
 
 * **New ways to configure the client connection, new parameters**
   - **RFC 6764 DNS-based service discovery**: Automatic CalDAV/CardDAV service discovery using DNS SRV/TXT records and well-known URIs. Users can now provide just a domain name or email address (e.g., `DAVClient(username='user@example.com')`) and the library will automatically discover the CalDAV service endpoint. The discovery process follows RFC 6764 specification.  This involves a new required dependency: `dnspython` for DNS queries.  DNS-based discovery can be disabled in the davclient connection settings, but I've opted against implementing a fallback if the dns library is not installed.
+  - Use `features: posteo` instead of `url: https://posteo.de:8443/` in the connection configuration.
+  - Use `features: nextcloud` and `url: my.nextcloud.provider.eu` instead of `url: https://my.nextcloud.provider.eu/remote.php/dav`
+  - Or even easier, use `features: nextcloud` and `username: tobixen@example.com`
   - New `require_tls` parameter (default: `True`) prevents DNS-based downgrade attacks
   - The client connection parameter `features` may now simply be a string label referencing a well-known server or cloud solution - like `features: posteo`.  https://github.com/python-caldav/caldav/pull/561
   - The client connection parameter `url` is no longer needed when referencing a well-known cloud solution. https://github.com/python-caldav/caldav/pull/561
@@ -79,7 +79,7 @@ Highlights:
 ### Security
 
 There is a major security flaw with the RFC6764 discovery.  If the DNS is not trusted (public hotspot, for instance), someone can highjack the connection by spoofing the service records.  The protocol also allows to downgrade from https to http.  Utilizing this it may be possible to steal the credentials.  Mitigations:
- * DNSSEC is the ultimate soluion, but DNSSEC is not widely used.  I tried implementing robust DNSSEC validation, but it was too complicaed.
+ * DNSSEC is the ultimate soluion, but DNSSEC is not widely used.  I tried implementing robust DNSSEC validation, but it was too complicated.
  * Require TLS.  By default, connections through the autodiscovery is required to use TLS.
  * Decline domain change.  If acme.com forwards to caldav.acme.com, it will be accepted, if it forward to evil.hackers.are.us the connection is declined.
 
@@ -182,10 +182,10 @@ External servers tested:
 * Synology
 * Posteo
 * Baikal
+* Robur
 
 Servers and platforms not tested this time:
 
-* Robur (Some tests have been run towards Robur - but it seems to be some problems with the server, or perhaps active rate-limiting, the tests stops up after a while)
 * PurelyMail (partly tested - but test runs takes EXTREMELY long time due to the search-cache server peculiarity, and the test runs still frequently fails in non-deterministic ways).
 * GMX (It throws authorization errors, didn't figure out of it yet)
 * DAViCal (my test server is offline)

CODE_OF_CONDUCT

@@ -14,6 +14,21 @@ That said, personally I'm all ears for suggestions on how to improve
 the CalDAV library - even if that includes blunt criticism of the work
 I've done.
 
+Specific for this project, we should probably strive not to use too
+many negative adjectives on server implementations, even when they
+break all the standards badly.  I may not have been very good at this
+earlier (and I may not have weeded out all he negativity from the
+mastar branch yet), but I'm striving to improve myself.  While the
+RFCs may seem sub-optimal or ambiguous sometimes, accusing the authors
+for being stupid, evil or corrupt is clearly way out of the line.
+
+The main branch for this project is called "master".  If the project
+was made today, the name of the branch would be "main.  For ME, I
+cannot understand how naming a git-branch "master" can be offensive -
+but if YOU get offended by it, please notify me.  I will not quesion
+it, and I will not hold you responsible for it, I will just rename the
+branch.
+
 Unacceptable behavior may be reported to Tobias Brox, the current
 maintainer of the project.  The email address coc-abuse@plann.no may
 be used.  If complaining to Tobias doesn't help, you may try reaching
@@ -22,4 +37,4 @@ If Tobias is the subject of the complaint, you may want to put Cyril
 on the Cc-list in your complaint.  His email address can be found
 through http://scr.im/22q7
 
-Tobias Brox, 2025-05-21
+Tobias Brox, 2025-05-21 (amended 2025-12-04)

CONTRIBUTING.md

@@ -2,6 +2,10 @@
 
 Contributions are mostly welcome.  If the length of this text scares you, then I'd rather want you to skip reading and just produce a pull-request in GitHub.
 
+## Usage of AI and other tools
+
+A separate [AI POLICY](AI_POLICY.md) has been made.  The gist of it, be transparent and inform if your contribution was a result of clever tool usage and/or AI-usage, don't submit code if you don't understand the code yourself, and you are supposed to contribute value to the project.  If you're too lazy to read the AI Policy, then at least have a chat with the AI to work out if your contribution is within the policy or not.
+
 ## GitHub
 
 The official guidelines currently involves contributors to have a GitHub account - but this is not a requirement!  If you for some reason or another don't want to use GitHub, then that's fine.  Reach out by email, IRC, matrix, signal, deltachat, telegram or whatnot.
@@ -36,10 +40,7 @@ Consider this procedures to be a more of a guideline than a rigid procedure.  Us
 * Add an entry in the `CHANGELOG.md` file.
 
 * Create a pull request
-```
 
 ## Code of Conduct
 
-There is some text on https://www.contributor-covenant.org/, please DO reach out at t-py-caldav@tobixen.no if you notice a need for an explicit Code of Conduct.
-
-Specific for this project, we should probably strive not to use too many negative adjectives on server implementations.
+Code of Conduct has been moved to a [separate document](CODE_OF_CONDUCT]