Skip to content

Clarify fork-based contributor workflow #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Parshan-MHB wants to merge 1 commit into from
Closed

Clarify fork-based contributor workflow #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 16 additions & 8 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,18 +2,26 @@

## Workflow

1. Create a focused feature branch from `main`.
2. Keep changes scoped to one concern.
3. Regenerate the Xcode project when target or project settings change.
4. Run the strongest local verification you can before opening a PR.
5. Open a pull request into `main`.
6. Merge only after required CI is green.
7. Merge with squash merge so each PR lands as one commit on `main`.
1. If you are an external contributor, work from a fork and open a pull request back to `main`.
2. If you are a maintainer, create a focused feature branch from `main`.
3. Keep changes scoped to one concern.
4. Regenerate the Xcode project when target or project settings change.
5. Run the strongest local verification you can before opening a PR.
6. Open a pull request into `main`.
7. Merge only after required CI is green.
8. Merge with squash merge so each PR lands as one commit on `main`.

Direct pushes to `main` are not part of this repo workflow. The `main` branch is protected and changes should land through pull requests, including maintainers' own changes.
`main` also enforces linear history, so merge commits and rebase merges are not part of the repo workflow.

Suggested branch naming:
## Access Model

- External contributors should use forks.
- Maintainers should use feature branches in the main repository.
- Do not grant write access to casual contributors. Without write access, GitHub already forces the fork-and-PR model in practice because contributors cannot create branches in the upstream repository.
- Anyone with write, maintain, or admin access can still create branches in the main repository. GitHub does not provide a clean repository-level switch that says "contributors must fork, but maintainers may branch here." The practical control is repo permissions.

Suggested branch naming for maintainer branches:

- `feature/<short-topic>`
- `fix/<short-topic>`
Expand Down
Loading