Ship / Show / Ask

Reconciling Continuous Integration with Pull Requests

Pull Requests have become a dominant workflow for many teams. Their appeal is clear: modern code hosting platforms offer excellent review tooling and integrations for running tests, quality checks, and even full preview environments. Yet their ubiquity has come with a cost. The “Ready to Ship” mentality fostered by classic Continuous Integration has often been lost; features-in-progress can isolate work and delay integration, drifting back into the low-frequency integration pitfalls that CI aimed to avoid. Requests can sit waiting for review, become stale, or balloon in scope as developers add extra work while they wait.

There’s a simple model for bringing the best of both worlds together. Each change is categorized into one of three types: Ship, Show, or Ask.

The three paths for every change

Ship

This is the most CI-like option: make the change directly on the mainline. No waiting on anyone to review or approve it before it goes live. It relies on the standard CI toolkit (good test coverage, small batches, feature flags) to keep the mainline safe.

Ship works well for situations where confidence is high, including changes that:

• Follow an established pattern in the codebase
• Fix an unremarkable bug
• Update documentation
• Incorporate improvements suggested during earlier code review

Show

Show is the path for getting the benefits of PRs while maintaining integration momentum. Work happens on a branch, a Pull Request is opened for the record and the conversation, and then it is merged once any automated checks pass. The author takes the change live without waiting for human review, but creates an opportunity for others to give feedback, ask questions, and learn from the change asynchronously.

Show is a good choice when you want visibility on something interesting, such as:

• A new approach or pattern that you want feedback on
• A straightforward PR in which stylistic improvements or suggestions are welcome
• A particularly nasty bug whose root cause and fix deserve attention
• A refactoring that shows what the code now looks like

Ask

Ask is the intentional pause. A Pull Request is opened on a branch to solicit specific feedback before the merge happens, stopping work flow for the conversation.

This is appropriate where the change is exploratory or needs input, for instance:

• An experiment you want to float before deciding on an approach
• Work where you explicitly need help improving the implementation
• A change that benefits from review before being completed the following day

Operating rules for Ship/Show/Ask

Putting this into practice requires shifting away from review as a hard gate. The essential rules are: code review approval must not be required to merge; people merge their own Pull Requests, taking control of whether a change is a Show or an Ask; robust CI/CD practices (like feature toggles) keep the mainline releasable; and branches stay short-lived, getting rebased on mainline frequently.

Conversation beyond the Pull Request

Pull Requests are a helpful tool for talking about changes, but they carry a distinct set of pitfalls. The most important is the misconception that PRs can stand in for broader collaboration. When a team decides on an approach without talking first, time is spent on solutions that may be fundamentally sub-optimal before a single comment is written. Reviewers can get anchored to the chosen solution, making broad-based alternatives harder to suggest. Larger, longer-lived branches amplify this effect, so it is worth having pre-implementation chat to get better ideas early.

While the labels re-imagine the PR workflow, the intent goes further than the tooling. A Show or Ask needn’t be a GitHub or GitLab object. A chat or a shared screen session is often the fastest way to get useful feedback. Creating space for these conversations requires a team culture that supports giving feedback outside the Pull Request itself.

Striking the right balance

Which choice should dominate? There is no universal rule—it is a per-team judgment that shifts.

A team working in established patterns with a high level of trust does a lot of Shipping. When people are still building a common understanding or facing a new problem, the emphasis shifts to Show and Ask. A junior engineer may live quite comfortably in the Show and Ask space, while a senior engineer might Ship most changes but consciously Show to expose a new pattern or a refactoring worth replication.

The freedom to choose Ship isn’t universal: heavily regulated industries require an approval process, whether or not the team branches, and policies like “all changes require two reviewers” will restrict the Ship and Show options front a practical standpoint.

Most teams already follow this model

On closer inspection, most teams end up as either “mostly Shipping” or “mostly Asking.” Diagnosing which camp you are in can point out where a balanced approach is missing.

If your team mostly ships

Committing straight to mainline preserves speed but can be isolating. In distributed or asynchronous environments, it is easy to miss context as changes arrive with no explanation. Even on co-located teams, if communication is lacking, problematic changes may remain unnoticed for weeks, when the why behind them is a fuzzy memory.

Adding more Show-style PRs to build in some low-barrier feedback loops catches these problems while the details are still fresh, and creates learning opportunities for the rest of the team.

If your team mostly asks

If your team tends to open a PR for everything, waiting for approval, you are in the “mostly Ask” category. Pre-merge review creates a scaling bottleneck. If simply everyone waits, code slows down. If feedback quality degrades due to volume, culture fractures.

Frequently, “mostly Ask” teams are grounded in a scarcity of trust—formalized in approval policies that stand in for stronger collaboration. These approval gates don’t actually build trust; they just slow work down and give an illusion of control. Getting back to balance involves actively Show-ing work, freeing release paths, and investing in better team practices. Activities like ensemble programming, pair review and training build the kind of confidence that makes Shipping safe. Even without these, simply making a safe change that bypasses review for a tighter loop is itself an incentive to do more low-risk, incremental work.

Ship/Show/Ask as a mindset

At its core, Ship/Show/Ask is two things. First, it’s a practical move to let the author merge their own PR before the review happens, treating the PR as a place to store a conversation rather than a gate to open. Second, it’s a mental model that rejects the binary of “always merge to main” vs. “everything is an Ask.” Each change deserves an independent decision based on its risk, novelty, and the team’s current trust in its own standards. It’s a small cognitive shift that turns code hosting from a bottleneck into a piece of the CI workflow rather than a replacement for it.