+1 Seems interesting.
> On May 13, 2026, at 9:13 AM, 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 >>
