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 >
