Hi Robert, Several ASF projects already use this feature with interesting results, some requesting Copilot on demand and others using it systematically per area.
Your proposed approach sounds good to me. Focusing on documentation resources is a great starting point, and we can allow it to evolve from there. Regards, JB On Wed, May 13, 2026 at 3:09 PM 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 >
