From bf04c52fb713564c66be8c27cd2927f84d19026f Mon Sep 17 00:00:00 2001 From: "Sean T. Allen" Date: Fri, 22 May 2026 19:42:30 -0400 Subject: [PATCH] Document AI-assisted contributions policy in CONTRIBUTING.md --- CONTRIBUTING.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4b79014..647281c 100755 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,6 +4,7 @@ You want to contribute to fork_join? Awesome. There are a number of ways to contribute. As this document is a little long, feel free to jump to the section that applies to you currently: +* [AI-assisted contributions](#ai-assisted-contributions) * [Bug report](#bug-report) * [How to contribute](#how-to-contribute) * [Pull request](#pull-request) @@ -14,6 +15,28 @@ Additional notes regarding formatting: * [Code formatting](#code-formatting) * [File naming](#file-naming) +## AI-assisted contributions + +We appreciate contributions, whatever the source. If AI tools help you contribute to Pony, we're glad to have you. Many of us use them too. + +That also means we know what AI-assisted code looks like when no one's reviewed it, and we won't merge PRs that read that way. If your contribution is clearly AI-assisted, you have an extra responsibility before opening it. + +The Pony project publishes a set of LLM skills at [ponylang/llm-skills](https://github.com/ponylang/llm-skills). Familiarize yourself with what's there and make sure your contribution uses the ones that apply to it. A PR that adds an API might lean on `pony-software-design` as you build it, `pony-test-design` for its tests, and `pony-release-notes` for the user-facing change. Which ones apply depends on your PR. + +One skill isn't optional: `pony-code-review`. We recommend running it against any contribution. For clearly AI-assisted PRs, we require it. Run it. Understand every finding. Then address it — by fixing it, or by dismissing it with a justification you can defend in the PR. The review surfaces the kind of issues a human maintainer would catch, but it isn't infallible. What you can't do is skip a finding because you didn't understand it. Don't open the PR until you've worked through them all. + +If the review surfaces something you don't understand or don't know how to answer, stop. Don't open the PR. Come to the [Pony Zulip](https://ponylang.zulipchat.com/) and ask. We are happy to teach. We enjoy helping people learn Pony. + +What we won't do is teach an AI. If a PR's open questions can only be resolved by maintainers explaining things to you so you can relay them to your AI for the next round, that's not a code review. That's us teaching a tool that won't remember any of it. Our time is better spent on the contributor who came to Zulip first. + +You don't have to disclose AI use, though saying so up front often makes review faster. What you do have to do is stand behind the code. If you can't answer questions about why your PR looks the way it does, it isn't ready. + +### Junk PRs + +This isn't new policy. Long before AI tools were any good, low-effort PRs that wasted maintainer time could get a contributor blocked. That hasn't changed. What's changed is how easy it has become to produce a junk PR. One won't get you blocked. A pattern of them will. How many makes a pattern is our call. + +We don't owe anyone our time. We choose to give it. Don't waste it. + ## Bug report First of all please [search existing issues](https://github.com/ponylang/fork_join/issues) to make sure your issue hasn't already been reported. If you cannot find a suitable issue — [create a new one](https://github.com/ponylang/fork_join/issues/new).