Hello,
I’ve validated this feature across multiple PRs. It works reliably and has been a real improvement for managing and raising PRs. One observation worth raising: GitHub workers (at least on the required-check.yml final step) have felt slower recently. I’m not sure whether this is due to the additional CI load from this change or unrelated infrastructure issues. Might be worth checking worker queue times to confirm. Respectfully, Matthew Ball > On May 14, 2026, at 11:27 AM, Yicong Huang <[email protected]> wrote: > > This is to be verified by a non committer. > > Best, > Yicong Huang > [email protected] >> On May 14, 2026 at 10:50 AM -0700, Xuan Gu <[email protected]>, wrote: >> Sounds good. I will test it and share the findings soon. >> >> Best, >> Xuan >> >>> On Thu, May 14, 2026 at 10:43 AM Ali Risheh <[email protected]> wrote: >>> >>> Good morning, >>> >>> Since Xuan has recently become a committer, I guess she can verify >>> this, so I will contact her. >>> >>> On Wed, May 13, 2026 at 10:02 PM Chen Li <[email protected]> wrote: >>>>> >>>>> Matthew, Xuan, Sarah, and other contributors: Can you try and verify? >>>>> >>>>> Chen >>>>> >>>>> On Tue, May 12, 2026 at 11:56 AM Yicong Huang <[email protected]> >>>>> wrote: >>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I opened an INFRA ticket on this topic, and according to the reply, the >>>>>>> INFRA team has enabled this setting for us. Now new contributors only >>> need >>>>>>> to be approved for CI for their first PR. once the first PR got merged, >>>>>>> then CIs on future PRs can automatically run without committers to >>> approve. >>>>>>> >>>>>>> Matthew or other contributors can you try and verify? I will need to >>> get >>>>>>> back to the INFRA team. >>>>>>> >>>>>>> Cheers, >>>>>>> Yicong Huang >>>>>>> [email protected] >>>>>>> >>>>>>> On May 7, 2026 at 10:43 PM -0700, Xinyuan Lin <[email protected]>, >>>>>>> wrote: >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> >>>>>>>>> Xinyuan Lin >>>>>>>>> >>>>>>>>> On Thu, May 7, 2026 at 22:13 Jiadong Bai <[email protected]> >>> wrote: >>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Jiadong Bai >>>>>>>>>>> >>>>>>>>>>> On Mon, May 4, 2026 at 10:37 PM Zuozhi Wang <[email protected]> >>> wrote: >>>>>>>>>>> >>>>>>>>>>>>>>> I also like and support this. It makes sense and reduce >>> unnecessary >>>>>>>>>>>>>>> frictions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best >>>>>>>>>>>>>>> Zuozhi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, May 4, 2026 at 10:30 PM Chen Li <[email protected]> >>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I support this change because it can make it easier for >>>>>>> non-committers >>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> contribute. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Chen Li >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, May 5, 2026 at 1:00 AM Yicong Huang < >>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Texera dev, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I'd like to propose a change to our GitHub Actions >>>>>>> configuration on >>>>>>>>>>>>>>>>>>>>>>> apache/texera to reduce friction for non-committer >>>>>>> contributors. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *Background:* Currently, the ASF GitHub Actions policy >>>>>>> requires >>>>>>>>>>>>>>> committer >>>>>>>>>>>>>>>>>>>>>>> approval for all outside collaborators, meaning every >>> push >>>>>>> from a >>>>>>>>>>>>>>>>>>>>>>> non-committer's fork needs approval before CI runs. >>> This >>>>>>> leads to >>>>>>>>>>> slow >>>>>>>>>>>>>>>>>>>>>>> feedback and unnecessary work for committers. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *Proposal:* Ask ASF Infra to change to: "Require >>> approval >>>>>>> for >>>>>>>>>>>>>>> first-time >>>>>>>>>>>>>>>>>>>>>>> contributors." This means that after a contributor's >>>>>>> initial PR >>>>>>>>>>>>>>> approval, >>>>>>>>>>>>>>>>>>>>>>> their subsequent pushes and future PRs would trigger CI >>>>>>>>>>> automatically. >>>>>>>>>>>>>>>>>>>>>>> Committers still have visibility, and Infra can revert >>> if >>>>>>> needed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> As a project, we need to follow certain requirements >>> that >>>>>>> are called >>>>>>>>>>>>>>> out >>>>>>>>>>>>>>>>>>>>>>> here - >>>>>>> >>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Finfra.apache.org%2Fgithub-actions-policy.html&data=05%7C02%7Cyiconghuang%40umass.edu%7C9b189c6fa00a4dfc273f08deb1e14fc2%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639143778430727343%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y1bA5CcbnURTUFuIG5UugPjL7JoJi3Mip9fvq6KsZms%3D&reserved=0 >>>>>>> I have >>>>>>>>>>>>>>>>>>>>>>> confirmed >>>>>>>>>>>>>>>>>>>>>>> that: >>>>>>>>>>>>>>>>>>>>>>> - GitHub does not pass repository secrets to runners on >>>>>>> fork PRs >>>>>>>>>>>>>>>>>>>>>>> (regardless of whether the workflow file references >>>>>>>>>>> `secrets.*`). >>>>>>>>>>>>>>>>>>>>>>> GITHUB_TOKEN is provided but with read-only >>> permissions on >>>>>>> fork >>>>>>>>>>>>>>>>>>>>>>> PRs. >>>>>>>>>>>>>>>>>>>>>>> - Workflows that intentionally need write privileges >>> in PR >>>>>>>>>>> context >>>>>>>>>>>>>>>>>>>>>>> (auto-assign, lint-pr, pr-labeler) use >>>>>>> `pull_request_target`, >>>>>>>>>>>>>>>>>>>>>>> which runs in the base-branch context and is >>> unaffected by >>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> approval-policy setting. >>>>>>>>>>>>>>>>>>>>>>> - Workflows that touch sensitive secrets >>>>>>> (build-and-push-images, >>>>>>>>>>>>>>>>>>>>>>> create-release-candidate, direct-backport-push) are >>> gated >>>>>>> on >>>>>>>>>>>>>>>>>>>>>>> `workflow_dispatch` / `push` and are not reachable from >>>>>>> fork >>>>>>>>>>> PRs >>>>>>>>>>>>>>>>>>>>>>> at all. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *Precedent:* Several ASF projects have made this switch >>>>>>> via Infra >>>>>>>>>>> Jira, >>>>>>>>>>>>>>>>>>>>>>> including Apache ShardingSphere and Apache Druid. >>>>>>>>>>>>>>>>>>>>>>> - Apache ShardingSphere — >>>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-24389&data=05%7C02%7Cyiconghuang%40umass.edu%7C9b189c6fa00a4dfc273f08deb1e14fc2%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639143778430739529%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vPi%2FKRio9T2ikZxPMrtrhqtP2IgVNJ3sho89PjoV7vQ%3D&reserved=0 >>>>>>>>>>>>>>>>>>>>>>> - Apache Druid — >>>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-24657&data=05%7C02%7Cyiconghuang%40umass.edu%7C9b189c6fa00a4dfc273f08deb1e14fc2%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639143778430748751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cT18InQDGjHP9nXxACStMqtXkdULQzN3mG%2B1CmUpEfo%3D&reserved=0 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Please share your thoughts. If no-one objects within >>> three >>>>>>> days, I’ll >>>>>>>>>>>>>>>>>>>>>>> assume lazy consensus and open a ticket to INFRA. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>> Yicong Huang >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>
