From 781da9f8b3d82f11a7e2367b7e39a65450e06a1f Mon Sep 17 00:00:00 2001 From: Michael Lieberman Date: Tue, 13 Oct 2026 23:42:21 -0400 Subject: [PATCH] docs(ai-policy): reviewed AI-drafted text is the poster's own; no unreviewed posting Replace the Responsibility and Communication lines that forbade AI-drafted comments and descriptions outright. Issues, pull requests and comments must be written for a human reader, specific to the project, and understood by the person posting them. AI may draft; the person reads and stands behind it, and discloses that AI helped. A tool may post only at the person's request after they reviewed the text, never on its own. Maintainers may close unclear, padded, generic or duplicate contributions without a detailed review, and new contributors keep one pull request open until their first is merged. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Michael Lieberman Signed-off-by: Marc-cn <130138935+Marc-cn@users.noreply.github.com> --- AI_POLICY.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/AI_POLICY.md b/AI_POLICY.md index 7d7ae0ac..15ea11aa 100644 --- a/AI_POLICY.md +++ b/AI_POLICY.md @@ -20,13 +20,30 @@ For guidelines on code quality for all darnit contributions, refer to [CONTRIBUT You are responsible for any code you submit to darnit's repositories, regardless of whether it was manually written or generated by AI. You must understand and be able to explain the code you submit as well as the existing related code. It is not acceptable to submit a patch that you cannot understand and explain yourself. -In explaining your contribution, do not use AI to automatically generate comments, pull request descriptions, or issue descriptions. +How you explain your contribution is covered under Communication below. See below for our policy on AI translation systems. ### Communication -When interacting with developers (e.g., slack, issues, PRs) do not use AI to speak for you, except for translation or grammar editing. -Human-to-human communication is essential for an open source community to thrive. +Issues, pull requests, reviews and comments exist to move the project forward. A maintainer has to read each one, so whoever posts it, and however it was written, it must be: + +- **written for a human reader:** clear, specific, and as short as the content allows. Length is not effort. Padding, restated context and generic boilerplate make a contribution harder to review, not better; +- **about this project and this change,** not text that could be posted to any repository; +- **understood by the person posting it,** who stands behind it as their own words and can answer questions about it. + +AI may help you draft. Text you have read, understood and stand behind is yours to post; say that AI helped draft it. Do not post text you have not read. + +A tool may post for you only at your request, after you have reviewed what it will post. Asking a coding agent to open a pull request, an issue or a comment whose text you have read and approved is fine. A tool that reviews, writes and posts on its own, without you reading the result first, is not. + +Translation and grammar help need no disclosure. Human-to-human communication is essential for an open source community to thrive. + +Quantity is not a contribution. Maintainers may close, without a detailed review: + +- an issue or pull request that is unclear, padded or generic; +- one whose author does not appear to understand it; +- one that duplicates work already in progress. + +If you are new to the project, check the open issues and pull requests before starting, and keep one pull request open at a time until your first one is merged. ### Disclosure