Documentation team meeting 2024-02-08

This is just the agenda for the meeting at 14:00 - 14:30 (CEST). Join via


Follow up on last week’s issues


Anything updated within the past week can be ignored during triage. If someone wants to discuss a specific issue/PR then it should be added to the agenda.

I’ve just loosened the action permissions from:

Require approval for first-time contributors
Only first-time contributors will require approval to run workflows.


Require approval for first-time contributors who are new to GitHub
Only first-time contributors who recently created a GitHub account will require approval to run workflows.

If we see abuse then we can change it back, but in general I think this is secure enough.

My issue is not that I need to approve workflow one time for the first time contributor, but that I need to approve workflow for the same person multiple times. Specifically, I had to approve workflow for @apinnick twice on one PR and then again on another PR. It is logical that we need to approve workflow for the first-time contributor, but I do not think that it is intended to have to approve it every time.

They’re not a contributor until a patch has been merged. Are you sure a PR was merged? @apinnick has a sufficiently old GitHub account so that shouldn’t be an issue anymore.

The second PR could have been created before the first one was merged. Still it is peculiar that I had to approve workflow twice for the same PR. Even though a contributor does not have commit merged to master yet I would expect workflow to run automatically on after first appproval at least on that PR. Anyway if the workflow does not need to be approved to run after PR has been merged then my issue is resolved.

Every commit needs to be approved. The idea behind it is that otherwise you could submit a harmless commit that’s approved and then add some change that is harmful.

Now they can still submit a small PR (typo fix somewhere) that gets merged and then submit harmful PRs.

That’s why I think the automatic approval of non-contributors with decently old accounts is good enough. Then at least they can’t create a new account and spam harmful PRs.

I see, thank you for the explanation. In this case, I am fine with both new and old setting.

These were very large PRs, which required multiple commits. It’s unlikely that this will happen with my PRs in the future.