Documentation team meeting 2024-02-08

[adamlazik1]

This is just the agenda for the meeting at 14:00 - 14:30 (CEST). Join via https://meet.google.com/zih-cgjz-czo

General

• [RESOLVED][Adam] I need to approve workflow every time for the same person. Any idea why?
  • [Maximilian] Yes, we need to approve GHA before someone has their first commit on “master” branch.
• [Maximilian] We should always select a person who create the follow-up post for our next meeting.
  • DO NOT BACKPORT changes because they’re part of the Foreman Web UI
  • track downstream or upstream? > see foreman_theme_satellite
  • Avital: add to CONTRIBUTING file for new anchors; also for anchors with “[[ANCHOR]]”
• [Maximilian] discuss Fix file names by maximiliankolb · Pull Request #2740 · theforeman/foreman-documentation · GitHub
• [Maximilian] Do we need further discussion on Documenting web UI procedures · Issue #2490 · theforeman/foreman-documentation · GitHub or just wait until we have a PoC?
• [Maximilian] Switch to lowercase for “Content View”? See Switch "Content View" to lowercase again? · Issue #2747 · theforeman/foreman-documentation · GitHub
• [Lena]: present RH modular docs tool “new docs” guidelines at Foreman Community Demo
• [Malhar]: present “vale at RH” to lint docs?

Follow up on last week’s issues

Triage

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.

• Review open PRs
• Review open issues

[ekohl]

@adamlazik1

[adamlazik1] I need to approve workflow every time for the same person. Any idea why?

• [maximilian] Yes, we need to approve GHA before someone has their first commit on “master” branch.

I’ve just loosened the action permissions from:

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

To:

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.

[adamlazik1]

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.

[ekohl]

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.

[adamlazik1]

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.

[ekohl]

@adamlazik1

Still it is peculiar that I had to approve workflow twice for the same PR

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.

[adamlazik1]

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

[apinnick]

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