|
| 1 | +# AI use policy and guidelines |
| 2 | + |
| 3 | +* [Core principle](#core-principle) |
| 4 | +* [When AI is used in contributions](#when-ai-is-used-in-contributions) |
| 5 | +* [When AI is used in communications](#when-ai-is-used-in-communications) |
| 6 | + |
| 7 | +This document aligns with the [OpenJS Foundation AI Coding Assistants Policy][]. |
| 8 | + |
| 9 | +## Core principle |
| 10 | + |
| 11 | +Tools should never replace human judgment, regardless of whether they are |
| 12 | +powered by AI. |
| 13 | + |
| 14 | +Node.js requires contributors to understand and take full responsibility for |
| 15 | +every change they propose. The answer to "Why is X an improvement?" can |
| 16 | +never be "I'm not sure. The AI did it." |
| 17 | + |
| 18 | +If AI tools assisted in generating a contribution, acknowledge that honestly. |
| 19 | +Regardless of how much code is generated by AI, disclosure does not serve |
| 20 | +as a disclaimer of responsibility. |
| 21 | + |
| 22 | +Be aware that the mention of for-profit trademarks or commercial brands in |
| 23 | +commit messages, which are part of the code base, can be abused for |
| 24 | +profit-driven marketing. If the disclosure involves for-profit trademarks or |
| 25 | +commercial brands, it's recommended to either anonymize the branding (e.g. say |
| 26 | +`a frontier reasoning model`, `a closed-source coding agent` instead of |
| 27 | +`<brand>`), or only mention the for-profit brand/trademark in the PR |
| 28 | +description, but not in the commit message, unless the message would not have |
| 29 | +made sense without mentioning the specific brand/trademark. These |
| 30 | +recommendations only apply to for-profit tools/models, not any non-profit ones. |
| 31 | + |
| 32 | +Pull requests that contain AI-generated code the contributor has not |
| 33 | +personally understood, tested, and verified waste collaborator time and |
| 34 | +will be subject to closure without additional review. Contributors who |
| 35 | +repeatedly submit such changes, show no understanding of the project or |
| 36 | +its processes, or are dishonest about the use of automated assistance |
| 37 | +may be blocked from further contributions. |
| 38 | + |
| 39 | +Pull requests must not be opened by automated tooling, unless specifically |
| 40 | +approved in advance by the project. To request approval, either open an issue in |
| 41 | +[nodejs/admin](https://github.com/nodejs/admin/issues), or if the automation can |
| 42 | +be done in the form of a GitHub workflow, submit a pull request to add the |
| 43 | +workflow and use the usual pull request review process to seek consensus. |
| 44 | + |
| 45 | +## When AI is used in contributions |
| 46 | + |
| 47 | +Contributors may use AI tools to assist with contributions, but such tools |
| 48 | +never replace human judgment. |
| 49 | + |
| 50 | +When using AI as a coding assistant: |
| 51 | + |
| 52 | +* **Understand the codebase first.** Do not skip familiarizing yourself with |
| 53 | + the relevant subsystem. Always verify analysis generated by tools against |
| 54 | + the actual source code with human judgement. |
| 55 | + |
| 56 | +* **Own every line you submit.** You are responsible for all code in your |
| 57 | + pull request, regardless of how it was created. The submitted changes |
| 58 | + must satisfy the project's [Developer's Certificate of Origin][] and licensing |
| 59 | + requirements. Be prepared to explain any change in detail during review. |
| 60 | + |
| 61 | +* **Keep the commits logical.** The [commit message guidelines][] |
| 62 | + and [commit squashing guidelines](./pull-requests.md#commit-squashing) |
| 63 | + must be followed regardless of what tool is used in the pull request. |
| 64 | + |
| 65 | +* **Test thoroughly.** Existing tests should not be removed or modified |
| 66 | + without human verification. It is crucial to verify, with human judgement, |
| 67 | + the correctness of new tests against the intended behavior of the feature |
| 68 | + being tested, independently of how the implementation happens to behave. |
| 69 | + |
| 70 | +* **Do not disappear.** If you open a PR, follow it through. Respond to |
| 71 | + feedback and iterate until the work lands or is explicitly closed. If you |
| 72 | + can no longer pursue it, close the PR. Stalled PRs block progress. |
| 73 | + |
| 74 | +* **Do not use AI to claim "good first issue" tasks.** These issues exist to |
| 75 | + help new contributors learn the codebase and processes hands-on. |
| 76 | + |
| 77 | +* **Keep the comments useful.** Verify with human judgement that the |
| 78 | + comments are necessary and accurate. Remove comments that simply |
| 79 | + restate what the code does. Add comments only where the logic is non-obvious. |
| 80 | + |
| 81 | +## When AI is used in communications |
| 82 | + |
| 83 | +Node.js values concise, precise communication that respects collaborator and |
| 84 | +contributor time. |
| 85 | + |
| 86 | +* **Do not paste messages generated entirely by AI** in pull requests, issues, |
| 87 | + or the project's communication channels. Such communication may be removed in |
| 88 | + accordance to [the Node.js moderation policy][]. |
| 89 | +* **Verify claims about the code with human judgement before using them in |
| 90 | + communications**. Results from AI tools should only be treated as hypothesis. |
| 91 | + Link to actual code, documentation and specifications as source of truth. |
| 92 | +* Grammar and spell-check tools are acceptable when they improve clarity and |
| 93 | + conciseness. |
| 94 | + |
| 95 | +[Developer's Certificate of Origin]: ../../CONTRIBUTING.md#developers-certificate-of-origin-11 |
| 96 | +[OpenJS Foundation AI Coding Assistants Policy]: https://ai-coding-assistants-policy.openjsf.org/ |
| 97 | +[commit message guidelines]: ./pull-requests.md#commit-message-guidelines |
| 98 | +[the Node.js moderation policy]: https://github.com/nodejs/admin/blob/main/Moderation-Policy.md |
0 commit comments