Enable read‑only collaborators to contribute code by forking a repository to their own project/org and opening a pull request back to the upstream repo—without requiring write access to the upstream.

There are workarounds that offer a similar functionality, but we lose the PR UX and it makes policies and implementation more complex.

Forks

Allow a user to fork a repo into a chosen scope (account/org/project), preserving a fork linkage to the upstream (like GitHub).

Provide Sync from upstream (UI and API) to update the fork’s default branch (equivalent to “Fetch upstream / Sync fork”).

Cross‑Repository PRs (across forks):

Allow creating a PR where base is an upstream repo/branch and compare is a branch in the user’s fork (“compare across forks” UX).

Support the common flags: “Allow edits from maintainers,” status checks, merge strategies, and branch protections enforced by the destination repo’s rules.

Governance & RBAC:

Org/account setting to allow/disallow forks (private repos), mirroring GitHub’s forking policy toggles for private scopes.

Clear visibility of the fork network, limits on fork depth, and audit events for fork/sync/PR actions