From a405a2ecbbcd96509998b504cc4b23bde7771d21 Mon Sep 17 00:00:00 2001 From: selimnairb Date: Fri, 11 Sep 2026 10:27:38 -0400 Subject: [PATCH 1/2] #148: Add draft AI contribution policy --- AGENTS.md | 4 ++ docs/policies/AI.md | 126 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 130 insertions(+) create mode 100644 AGENTS.md create mode 100644 docs/policies/AI.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000000..540daf63f5 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,4 @@ +# AGENTS instructions + +* This project does not accept vibe-coded contributions. See our + [AI policy](docs/policies/AI.md) for guidance on acceptable use of AI/LLM tools. diff --git a/docs/policies/AI.md b/docs/policies/AI.md new file mode 100644 index 0000000000..3e6380f66c --- /dev/null +++ b/docs/policies/AI.md @@ -0,0 +1,126 @@ +# Bathymetric Attributed Grid (BAG) AI tool use policy + +It is the policy of the Open Navigation Surface Working Group that contributors can use whatever +tools they would like to craft their contributions, but there must be a **human in the loop**. +Contributors must read and review all Large Language Model (LLM)-generated code or text before they +ask other project members to review it. The contributor is always the author +and is fully accountable for their contributions. Contributors should be +sufficiently confident that the contribution is high enough quality that asking +for a review is a good use of scarce maintainer time, and they should be **able to answer questions +about their work** during review. + +We expect that new contributors will be less confident in their contributions, +and our guidance to them is to **start with small contributions** that they can +fully understand to build confidence. We aspire to be a welcoming community +that helps new contributors grow their expertise, but learning involves taking +small steps, getting feedback, and iterating. Passing maintainer feedback to an +LLM doesn't help anyone grow, and does not sustain our community. + +Contributors are expected to **be transparent and label contributions that +contain substantial amounts of tool-generated content**. Our policy on +labelling is intended to facilitate reviews, and not to track which parts of +BAG are generated. Contributors should note tool usage in their pull request +description, commit message, or wherever authorship is normally indicated for +the work. For instance, use a commit message trailer like Assisted-by: . This transparency helps the community develop best practices +and understand the role of these new tools. + +This policy includes, but is not limited to, the following kinds of +contributions: + +- Format Specification Document (FSD) +- Documentation +- Code +- Issues or security vulnerabilities +- Comments and feedback on pull requests + +# Details + +To ensure sufficient self-review and understanding of the work, it is strongly +recommended that contributors write PR descriptions themselves (if needed, +using tools for translation or copy-editing). The description should explain +the motivation, implementation approach, expected impact, and any open +questions or uncertainties to the same extent as a contribution made without +tool assistance. + +An important implication of this policy is that it bans agents that take action +in our digital spaces without human approval, such as the GitHub `@claude` +agent. Similarly, automated review tools that +publish comments without human review are not allowed. However, an opt-in +review tool that **keeps a human in the loop** is acceptable under this policy. +As another example, using an LLM to generate documentation, which a contributor +manually reviews for correctness, edits, and then posts as a PR, is an approved +use of tools under this policy. + +# Extractive Contributions + +The reason for our "human-in-the-loop" contribution policy is that processing +patches, PRs, QEPs, comments, issues, security alerts to BAG is not free -- +it takes maintainer time and energy to review those contributions. Sending the +unreviewed output of an LLM to open source project maintainers *extracts* work +from them in the form of design and code review, so we call this kind of +contribution an "extractive contribution". + +Our **golden rule** is that a contribution should be worth more to the project +than the time it takes to review it. These ideas are captured by this quote +from the book [Working in Public](https://press.stripe.com/working-in-public) by Nadia Eghbal: + +> \"When attention is being appropriated, producers need to weigh the costs and +> benefits of the transaction. To assess whether the appropriation of attention +> is net-positive, it's useful to distinguish between *extractive* and +> *non-extractive* contributions. Extractive contributions are those where the +> marginal cost of reviewing and merging that contribution is greater than the +> marginal benefit to the project's producers. In the case of a code +> contribution, it might be a pull request that's too complex or unwieldy to +> review, given the potential upside.\" \-- Nadia Eghbal + +Prior to the advent of LLMs, open source project maintainers would often review +any and all changes sent to the project simply because posting a change for +review was a sign of interest from a potential long-term contributor. While new +tools enable more development, it shifts effort from the implementor to the +reviewer, and our policy exists to ensure that we value and do not squander +maintainer time. + +# Handling Violations + +If a maintainer judges that a contribution doesn't comply with this policy, +they should paste the following response to request changes: + +:: + + This PR doesn't appear to comply with our policy on tool-generated content, + and requires additional justification for why it is valuable enough to the + project for us to review it. Please see our developer policy on + AI-generated contributions: + https://github.com/OpenNavigationSurface/BAG/blob/master/docs/policies/AI.md + +The best ways to make a change less extractive and more valuable are to reduce +its size or complexity or to increase its usefulness to the community. These +factors are impossible to weigh objectively, and our project policy leaves this +determination up to the maintainers of the project, i.e., those who are doing +the work of sustaining the project. + +If or when it becomes clear that a GitHub issue or PR is off-track and not +moving in the right direction, maintainers should apply the `extractive` label +to help other reviewers prioritize their review time. + +If a contributor fails to make their change meaningfully less extractive, +maintainers may lock the conversation and/or close the pull request/issue/QEP. +In case of repeated violations of our policy, the BAG project reserves itself +the right to ban temporarily or definitely the infringing person. + +# Copyright + +Artificial intelligence systems raise many questions around copyright that have +yet to be answered. Contributors are responsible for ensuring that they have the right to +contribute code under the terms of our license, typically meaning that either +they, their employer, or their collaborators hold the copyright. Using AI tools +to regenerate copyrighted material does not remove the copyright, and +contributors are responsible for ensuring that such material does not appear in +their contributions. Contributions found to violate this policy will be removed. + +# Credits for this document + +This document is adaptated from the +[QGIS Enhancement: AI tool use policy](https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md) +and due credit goes to its original author: Even Rouault From b46c429899a429d1a62fce4b993cbab9999b0df6 Mon Sep 17 00:00:00 2001 From: selimnairb Date: Fri, 11 Sep 2026 12:29:17 -0400 Subject: [PATCH 2/2] 148: AI policy: Remove refereance to QEPs, which are not relavant to this project --- docs/policies/AI.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/policies/AI.md b/docs/policies/AI.md index 3e6380f66c..6be6cb328f 100644 --- a/docs/policies/AI.md +++ b/docs/policies/AI.md @@ -55,7 +55,7 @@ use of tools under this policy. # Extractive Contributions The reason for our "human-in-the-loop" contribution policy is that processing -patches, PRs, QEPs, comments, issues, security alerts to BAG is not free -- +patches, PRs, comments, issues, security alerts to BAG is not free -- it takes maintainer time and energy to review those contributions. Sending the unreviewed output of an LLM to open source project maintainers *extracts* work from them in the form of design and code review, so we call this kind of @@ -105,7 +105,7 @@ moving in the right direction, maintainers should apply the `extractive` label to help other reviewers prioritize their review time. If a contributor fails to make their change meaningfully less extractive, -maintainers may lock the conversation and/or close the pull request/issue/QEP. +maintainers may lock the conversation and/or close the pull request/issue. In case of repeated violations of our policy, the BAG project reserves itself the right to ban temporarily or definitely the infringing person.