Provide guidelines for tool-generated content

In the last few years, the capabilities of coding tools have exploded.
As those capabilities have expanded, contributors and maintainers have
more and more questions about how and when to apply those capabilities.

Add new documentation to guide contributors on how to best use BIND 9
development tools, new and old.

In short: Please show your work and make sure your contribution is
easy to review.

This has been adopted from the Linux Kernel guidelines.

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 266162239bca985d7a65370d4643f36de4225196..455a4aed0057033e71a866df62c7873e7ea2c9f5 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -18,6 +18,7 @@ information regarding copyright ownership.
 1. [Access to source code](#access)
 1. [Reporting bugs](#bugs)
 1. [Contributing code](#contrib)
+1. [Generated code](#generated-code)
 
 ### Introduction
 
@@ -211,6 +212,101 @@ automated testing and cannot merge new code without adequate test coverage.
 Please see [the "Testing" section of doc/dev/dev.md](doc/dev/dev.md#testing)
 for more information.
 
+### <a name="generated-code"></a>Guidelines for Tool-Generated Content
+
+#### Purpose
+
+BIND 9 contributors have long used tooling to assist in development.
+These tools can increase the volume and velocity of contributions.  At
+the same time, reviewer and maintainer bandwidth is a scarce resource,
+and the stability of DNS software is critical infrastructure.
+Understanding which portions of a contribution come from humans versus
+tools is helpful to maintain those resources, assess risk, and keep
+BIND 9 development healthy.
+
+The goal here is to clarify community expectations around tools,
+particularly LLMs (Large Language Models) and generative AI.  This
+lets everyone become more productive while maintaining high degrees of
+trust between submitters and reviewers.
+
+#### Out of Scope
+
+These guidelines do not apply to tools that make trivial tweaks to
+preexisting content or verify adherence to style guides.  Nor do they
+pertain to AI tooling that helps with menial tasks.  Some examples:
+
+ - Spelling and grammar fix-ups, like rephrasing documentation to the
+   imperative voice.
+ - Typing aids like IDE identifier completion, common boilerplate, or
+   trivial pattern completion.
+ - Purely mechanical transformations like variable renaming across a
+   scope.
+ - Reformatting using the standard BIND 9 clang-format configuration
+   or black (for Python system tests).
+
+Even if your tool use is out of scope, you should still always
+consider if it would assist the review of your contribution if the
+reviewer knows about the tool that you used.
+
+#### In Scope
+
+These guidelines apply when a meaningful amount of content in a BIND 9
+contribution (code, documentation, or tests) was not written by a
+person contributing the patch or merge request, but was instead
+created by a tool.
+
+Detection of a problem and testing the fix for it is also part of the
+development process; if a tool was used to find a problem addressed by
+a change (e.g., a fuzzer or static analyzer), that should be noted in
+the commit message or MR description.  This not only gives credit where
+it is due, it also helps fellow developers find out about these tools.
+
+Some examples:
+
+ - Complex semantic patches generated by Coccinelle scripts.
+ - A chatbot or AI assistant generated a new function in your Merge
+   Request to handle a specific DNS RR type.
+ - A .c file or system test in the MR was originally generated by a
+   coding assistant but cleaned up by hand.
+ - The commit message or MR description was generated by handing the
+   diff to a generative AI tool.
+ - Documentation or comments were translated from another language
+   using an automated tool.
+
+If in doubt, choose transparency and assume these guidelines apply to
+your contribution.
+
+#### Guidelines
+
+You are responsible for the code you submit, regardless of how it was generated.
+When opening a Merge Request, be transparent about the origin of content in the
+MR description and commit messages.  You can be more transparent by adding
+information like this:
+
+ - What tools were used?
+ - The input to the tools you used, like the Coccinelle source script
+   or specific configuration.
+ - If code was largely generated from a single or short set of
+   prompts, include those prompts.  For longer sessions, include a
+   summary of the prompts and the nature of the resulting assistance.
+ - Which portions of the content were affected by that tool?
+ - How is the submission tested? (e.g., "I used tool X to generate a
+   system test case that triggers the bug.")
+
+As with all contributions, BIND 9 maintainers have discretion to
+choose how they handle the contribution.  For example, they might:
+
+ - Treat it just like any other contribution.
+ - Reject it outright if the provenance is unclear or the code quality
+   is low.
+ - Treat the contribution specially, such as reviewing with extra
+   scrutiny regarding memory safety or RFC compliance.
+ - Suggest a better prompt or approach instead of suggesting specific
+   code changes.
+ - Ask the submitter to explain in more detail about the contribution
+   to ensure the submitter fully understands the DNS logic or internal
+   BIND 9 architecture implemented by the tool.
+
 #### Thanks
 
 Thank you for your interest in contributing to the ongoing development