Hi Robert, all, +1 to trying this in the narrow form you described.
The important boundaries for me are the ones already called out: Copilot should be advisory only, the absence of comments should not imply approval, and its comments shouldn't be considered a blocker unless confirmed by a human. Yufei On Wed, 13 May 2026 10:13:10 -0400, Dmitri Bourlatchkov [email protected] wrote: Hi Robert, This sounds interesting to try in Polaris. +1 to starting small and evolving based on practical observations. Cheers, Dmitir. On Wed, May 13, 2026 at 9:09 AM Robert Stupp [email protected] wrote: Hi all, I would like to discuss whether we should opt the Polaris repository into GitHub Copilot code review as an advisory PR review aid. The motivation is not to replace human review, but to reduce the chance that, for example, rarely touched documentation gets out of sync with code changes. Examples are AGENTS.md, README.md, CONTRIBUTING.md, the website docs under site/content, the next-release docs under site/content/in-dev, and Helm-related docs. The proposed usage of Copilot would be omission-oriented: - If a PR changes user-facing, security-relevant, operational, or contributor workflow behavior, Copilot may ask to check for related docs, tests, or security-note updates. - Copilot should prefer silence and not add speculative comments. - Absence of Copilot comments should not be interpreted as approval. The proposal is explicitly not to use Copilot as a correctness authority. It should not certify that code is correct, that tests are sufficient, that docs are complete, or that a security-sensitive change is safe. Those remain human review responsibilities. An initial PR would do this: - enable Copilot via .asf.yaml - enable review only for non-draft PRs - not enable automatic review on every new push initially - add repository instruction files focused on documentation, test, and security omissions, and generated-file handling - add a CI check that validates instruction-file size and path-specific instruction frontmatter. The intent is to start with a small instruction set and adjust based on observations. If the comments are noisy, misleading, or not useful enough, we can disable the feature. We can also add or refine instructions later, but I would prefer not to overfit the initial PR before seeing how it behaves on real PRs. This would be used within ASF’s guidance for generative tooling [1]. WDYT? Are there concerns with enabling this as an advisory, best-effort review signal? Are there areas where we should explicitly tell Copilot to stay silent, or additional safeguards we should include before trying it? Thanks, Robert [1] https://www.apache.org/legal/generative-tooling.html
