Principle:SeleniumHQ Selenium Pull Request Submission
| Knowledge Sources | |
|---|---|
| Domains | Collaboration, Code_Review, Developer_Experience |
| Last Updated | 2026-02-11 00:00 GMT |
Overview
Process for submitting code changes as a pull request following Selenium's PR template, review guidelines, and squash-merge workflow.
Description
Selenium PRs follow a standardized template (.github/PULL_REQUEST_TEMPLATE.md) with sections for Related Issues, Description, Implementation Notes, Additional Considerations, and Change Type. PRs should focus on one thing and are squash-merged to the trunk branch, producing a single clean commit to maintain linear history. The PR title becomes the squash commit message, so it should be descriptive. CI checks (build, test, format) must pass before merge. Review feedback should be applied as new commits (preferably fixup commits) pushed to the same branch, which will be squashed at merge time.
GitHub labels are used to track PR status: R-awaiting reviewer (pending review), R-needs code changes (feedback to address), R-awaiting merge (approved and ready), R-needs rebase (out of sync with trunk), R-blocked on external (waiting on upstream). Component labels (C- prefix) and driver labels (D- prefix) categorize the areas affected.
Usage
Submit a PR after code changes are built, tested, and formatted. Fill in the PR template completely. Reference related issues with Fixes #N or Closes #N syntax. Apply review feedback in new fixup commits.
Theoretical Basis
# PR Submission Process
1. Ensure changes are built, tested, and formatted
2. Push feature branch: git push origin feature-name
3. Create PR: GitHub UI or gh pr create
4. Fill template:
- Related Issues: "Fixes #1234" or "Closes #5678"
- What does this PR do?: Description of changes
- Implementation Notes: Why this approach, alternatives considered
- Additional Considerations: Decisions needed, follow-up work
- Types of changes: Cleanup / Bug fix / New feature / Breaking change
5. CI runs: build + test + format checks
6. Review: maintainers review and request changes
7. Address feedback: push fixup commits to same branch
8. Squash merge: committer squash-rebases PR into single commit on trunk
# PR Labels (tracking workflow)
R-awaiting reviewer -> pending code review
R-needs code changes -> review feedback to address
R-awaiting answer -> question for contributor
R-awaiting merge -> approved, ready to merge
R-needs rebase -> branch out of sync with trunk
R-blocked on external -> waiting on upstream change
C-* (component) -> java, py, rb, dotnet, etc.
D-* (driver) -> WebDriver implementation affected