Public code does not promise an open contribution queue

Publishing a repository makes code visible. It does not automatically promise that maintainers will accept unsolicited changes or give every proposed change a review. Read access, permission to submit and authority to merge are separate commitments. A repository should explain each one clearly enough that a potential contributor can decide whether to invest time.

Two GitHub announcements in the week beginning 11 February 2026 made those boundaries easier to discuss. Pull request access settings arrived on 13 February. A required reviewer rule reached general availability on 17 February. Looking back, they addressed different points in the contribution process. Neither should be treated as a complete community policy.

Visibility is the first boundary

A public repository lets people inspect the published code. That visibility can support evaluation or learning even when the project has no capacity to process external pull requests. The social mistake is leaving the contribution expectation implicit. Readers may interpret an apparently open submission route as an invitation to spend hours preparing a change.

A clear statement should identify whether external changes are welcome and where they should begin. If prior discussion is expected, explain its purpose. The goal is to give a newcomer useful information before the work, rather than reveal an unwritten policy after submission. This is communication advice, not a legal interpretation of a project's software licence.

Visibility also has limits as evidence. The presence of source code cannot prove that maintainers have time to support a feature request, review a patch or operate someone else's installation. Those activities consume different kinds of attention. A project can publish code while setting a narrower support commitment, provided it makes that commitment understandable.

Submission access is a capacity decision

The February access announcement described disabling pull requests entirely or restricting creation to collaborators. The latter was a managed contribution route for users with write access. Those settings concern who can enter the pull request process. They do not by themselves decide which change should be merged or establish that its contents are correct.

The distinction matters when choosing a response to overload. If unsolicited submissions are the problem, a rule that adds reviewers after submission still leaves the intake open. The queue can continue to grow even if no change can merge without approval. A submission boundary deals with a different pressure from a merge boundary.

Disabling pull requests has a further communication consequence. The announcement says the pull requests tab becomes unavailable, including visibility of existing pull requests. A maintainer considering that option should therefore examine how people will find relevant prior discussions. The setting changes more than the ability to press a submission button. This article reports no actual repository setting change.

Review authority protects a different decision

The 17 February required reviewer announcement concerns approvals for changes to selected branches and files through repository rulesets. Its purpose is to require the relevant reviewers before a change can proceed under those rules. That is useful when some parts of a repository need particular expertise. It does not determine who should be allowed to propose work in the first place.

A hypothetical project might want broad submission access while requiring a database team to approve particular file changes. Another might accept submissions only from a known group and still require specialist review. Those combinations show why a single label such as “open” cannot describe the whole process. State the intended permissions at each stage.

The February dates establish historical availability announcements, not a guarantee about every present-day account or plan. Before adopting a setting now, verify its current availability and interaction with the repository's rules. The enduring recommendation is to separate the decisions. It does not depend on assuming that today's interface and entitlement details match February exactly.

Restrictions can exclude useful contributors

The strongest counterargument is that limiting submissions may shut out the newcomer who would have fixed an important problem. It can also move requests to issues, email or other channels, leaving maintainers with the same burden elsewhere. A restriction should therefore be judged by its effect on the whole contribution path, not by the disappearance of one queue.

That tradeoff deserves an explicit choice. If the project welcomes newcomers, provide a route they can realistically use before granting any standing access. If external contributions are currently outside the project's capacity, say so plainly. Avoid presenting a closed queue as a temporary inconvenience when no one has agreed to reopen or staff it.

Review requirements have a corresponding limit. A required reviewer cannot supply unlimited reviewer time. When the same people become a mandatory stop for many changes, the process still needs an honest account of their capacity. Permission controls make authority enforceable; they cannot manufacture the human attention that gives approval its value.

For teams considering custom software development around a shared codebase, the handover should identify who reads, who submits and who accepts responsibility for merging. Match the technical controls to that written expectation. The February settings were useful tools for expressing boundaries, but the commitment to contributors remains a decision the people maintaining the repository have to make.