Guidelines: Should we force opening PRs from forks only for members?

pbokoc commented

2026-05-26 11:01:23 +00:00

Owner

An interesting topic came up in docs/docs-template#20 (comment): Is it okay for team members to open PRs directly from a repository, or should we mandate that everyone use a fork? I'd like the team's input on this, I haven't really thought about it myself.

If we wanted to restrict this, it seems that we can configure our repos to ensure everyone has to fork before they can submit a PR.

An interesting topic came up in https://forge.fedoraproject.org/docs/docs-template/pulls/20#issuecomment-713926: Is it okay for team members to open PRs directly from a repository, or should we mandate that everyone use a fork? I'd like the team's input on this, I haven't really thought about it myself. If we wanted to restrict this, it seems that we can configure our repos to ensure everyone has to fork before they can submit a PR.

pbokoc added this to the Docs Team Meeting Planner project

2026-05-26 11:01:30 +00:00

pbokoc referenced this issue from docs/docs-template

2026-05-26 11:02:05 +00:00

feat: Configurable docsbuilder port #20

korora commented

2026-05-26 14:57:05 +00:00

Member

I'm of the opinion that we should all be working off of forks and then opening PR's to merge to main. I am, however, not a software developer and this is hte first time that I've really worked with repos wiht others, so I'm learning as I go.

Forks then merge to main seems like the safer option and prevents errors on main and lets us, as a group, make sure that we are putting accurate and quality checked information out there. We might be 'amateurs' (in terms of this being a profesisonal position that we are being paid for) but there is no reason why we shouldn't strive to publish work that looks professional.

Just my .02 btc.

I'm of the opinion that we should all be working off of forks and then opening PR's to merge to main. I am, however, not a software developer and this is hte first time that I've really worked with repos wiht others, so I'm learning as I go. Forks then merge to main seems like the safer option and prevents errors on main and lets us, as a group, make sure that we are putting accurate and quality checked information out there. We might be 'amateurs' (in terms of this being a profesisonal position that we are being paid for) but there is no reason why we shouldn't strive to publish work that looks professional. Just my .02 btc.

pbokoc added the

meeting topic

label

2026-05-29 10:18:00 +00:00

hricky commented

2026-06-02 03:43:32 +00:00

Member

In other teams I am a member of, we've discussed that the best practice for contributing to projects is to first fork the repo, push commits to it, and then open PRs in the main repo. This should be done from separate, properly and descriptively named branches. We have strict rules for commit messages, AI agents, etc. We've documented all of this to avoid any confusion. This also applies to members of orgs. We've disabled direct pushes to all repos in these orgs and even the owners make contributions from their forks.

pbokoc commented

2026-06-02 14:44:34 +00:00

Author

Owner

We've discussed this at the latest meeting - https://discussion.fedoraproject.org/t/fedora-docs-team-meeting-2026-06-02/192972

Most people seemed to be leaning towards "allow but not encourage". Team members should be allowed to push directly and to directly edit without a fork, but only as long as it's used sparingly and for small fixes. If it's anything not very small, it should be a proper PR created from a fork.

Further discussion to take place in the comments here.

We've discussed this at the latest meeting - https://discussion.fedoraproject.org/t/fedora-docs-team-meeting-2026-06-02/192972 Most people seemed to be leaning towards "allow but not encourage". Team members should be allowed to push directly and to directly edit without a fork, but only as long as it's used sparingly and for small fixes. If it's anything not very small, it should be a proper PR created from a fork. Further discussion to take place in the comments here.

mwinters commented

2026-06-02 17:59:52 +00:00

Member

My modus operandi

Here are the guidelines I use with projects where I'm a maintainer. This works well when you have a relatively small number of changes in flight at a time (compared to, say, Kubernetes or Apache projects, where branch names can actually conflict easily).

Trivial commits can go straight to main. You are expected to know which commits are trivial and which might break something or interfere with another developer's work. You should also be good at naming forks. In other words, you must demonstrate both good judgement and responsibility.
Non-trivial PRs should be done from a branch on the main repo.
Automation should ensure that by default, merging a branch PR also deletes the branch.

Why

This eases not just git clone but getting other humans to actually test your code. Otherwise, setting up remotes and branches to locally test code from dozens of repos realistically presents a high enough hurdle that it happens far less often than it should. And the busiest members are those most affected by this.
Ease of development (by becoming a maintainer) is a perk that you earn with a history of trust. It incentivizes good behavior and becomes a signifier of stewardship. In other words, it can drive culture around the project.
Adding a forking requirement for maintainers accomplishes nothing. Violating any of these guidelines are grounds to be removed as a maintainer anyway, so we're not averting any bad behavior by adding friction.

## My modus operandi Here are the guidelines I use with projects where I'm a maintainer. This works well when you have a relatively small number of changes in flight at a time (compared to, say, Kubernetes or Apache projects, where branch names can actually conflict easily). 1. Trivial commits can go straight to main. You are expected to know which commits are trivial and which might break something or interfere with another developer's work. You should also be good at naming forks. In other words, you must demonstrate both good judgement and responsibility. 2. Non-trivial PRs should be done from a branch on the main repo. 3. Automation should ensure that by default, merging a branch PR also deletes the branch. ## Why - This eases not just `git clone` but getting other humans to _actually_ test your code. Otherwise, setting up remotes and branches to locally test code from dozens of repos realistically presents a high enough hurdle that it happens far less often than it should. And the busiest members are those most affected by this. - Ease of development (by becoming a maintainer) is a perk that you earn with a history of trust. It incentivizes good behavior and becomes a signifier of stewardship. In other words, it can drive culture around the project. - Adding a forking requirement for maintainers accomplishes nothing. Violating any of these guidelines are grounds to be removed as a maintainer anyway, so we're not averting any bad behavior by adding friction.

bookwar commented

2026-06-17 23:39:31 +00:00

Just want to add here for awareness:

there is a a way to create pull requests in Forgejo without requiring a fork or a branch in the main repo:

https://forgejo.org/docs/latest/user/agit-support/

It is not that user friendly as user needs to use git cli to create such a pull request. But it is an interesting feature, which might be useful for drive-by contributors.

Just want to add here for awareness: there is a a way to create pull requests in Forgejo without requiring a fork or a branch in the main repo: https://forgejo.org/docs/latest/user/agit-support/ It is not that user friendly as user needs to use git cli to create such a pull request. But it is an interesting feature, which might be useful for drive-by contributors.

pboy added the

Contributors' Guidance

Improve written Material

label

2026-06-28 17:28:53 +00:00

pbokoc commented

2026-06-30 13:38:46 +00:00

Author

Owner

From today's meeting:

!agreed Normally, and particularly in the case of changes that require lengthy discussion and refinement, a pull request should be submitted via a fork. Owners and content owners who maintain an article on an ongoing basis may also submit a pull request or push directly.

From today's meeting: >!agreed Normally, and particularly in the case of changes that require lengthy discussion and refinement, a pull request should be submitted via a fork. Owners and content owners who maintain an article on an ongoing basis may also submit a pull request or push directly.

jflory7 commented

2026-06-30 17:34:26 +00:00

Owner

Discussed in 2026-06-30 Fedora Docs Team meeting.

The team discussed PR/forking guidelines for docs/* repositories. The consensus is that forks are the preferred workflow, especially for changes requiring discussion or refinement. Org owners and content owners who maintain an article on an ongoing basis may push directly or submit PRs from branches for routine updates. @pbokoc will configure Forgejo repo settings to enforce branch protections — only docs-owners can push to main, and at least one review approval will be required before merge.

AGREED: "Normally, and particularly in the case of changes that require lengthy discussion and refinement, a pull request should be submitted via a fork. Owners and content owners who maintain an article on an ongoing basis may also submit a pull request or push directly."
@pbokoc: Experiment with Forgejo repo settings to find a minimally obtrusive configuration, then deploy across all docs/* repos

_{Assisted-by: Claude Opus 4.6 (1M context)}

_Discussed in [2026-06-30 Fedora Docs Team meeting](https://discussion.fedoraproject.org/t/fedora-docs-team-meeting-2026-06-30/195195/3)._ --- The team discussed PR/forking guidelines for `docs/*` repositories. The consensus is that forks are the preferred workflow, especially for changes requiring discussion or refinement. Org owners and content owners who maintain an article on an ongoing basis may push directly or submit PRs from branches for routine updates. @pbokoc will configure Forgejo repo settings to enforce branch protections — only `docs-owners` can push to `main`, and at least one review approval will be required before merge. - **AGREED:** "Normally, and particularly in the case of changes that require lengthy discussion and refinement, a pull request should be submitted via a fork. Owners and content owners who maintain an article on an ongoing basis may also submit a pull request or push directly." - @pbokoc: Experiment with Forgejo repo settings to find a minimally obtrusive configuration, then deploy across all `docs/*` repos <sub>_Assisted-by: Claude Opus 4.6 (1M context)_</sub>

pbokoc was assigned by jflory7

2026-06-30 17:34:34 +00:00

jflory7 added this to the 2026 Q3 Team Goals milestone

2026-06-30 17:34:34 +00:00

jflory7 removed the

meeting topic

label

2026-06-30 17:34:36 +00:00

jflory7 added

Contributors' Guidance

technical support measures

and removed

Contributors' Guidance

Improve written Material

labels

2026-07-14 14:26:24 +00:00

jflory7 commented

2026-07-14 14:26:33 +00:00

Owner

Discussed in 2026-07-14 Fedora Docs Team meeting.

@pbokoc acknowledged that the action item from the previous meeting to configure repository settings enforcing the new PR/forking guidelines has not yet been completed. He will prioritize this work this week.

Follow-up:

@pbokoc: Will prioritize enforcing new PR/forking guidelines (configuring repo settings to require forks for PRs) this week

_{Assisted-by: Claude Opus 4.6 (1M context)}

_Discussed in [2026-07-14 Fedora Docs Team meeting](https://discussion.fedoraproject.org/t/fedora-docs-team-meeting-2026-07-14/196628)._ --- @pbokoc acknowledged that the action item from the previous meeting to configure repository settings enforcing the new PR/forking guidelines has not yet been completed. He will prioritize this work this week. **Follow-up:** - @pbokoc: Will prioritize enforcing new PR/forking guidelines (configuring repo settings to require forks for PRs) this week <sub>_Assisted-by: Claude Opus 4.6 (1M context)_</sub>

jflory7 added the due date 2026-07-17

2026-07-14 14:26:36 +00:00

Rows
Columns

Guidelines: Should we force opening PRs from forks only for members? #46

My modus operandi

Why