Ship/Show/Ask is a fairly recent strategy to handle the workflow of your Pull Requests. Its goal is to provide the advantages of having pull requests, while at the same time keeping a fast pace in producing new features. It does it by caracterizing your pull requests into three big categories : ship, show and ask, as the name suggests.
This strategy differs from more classical PR workflows by streamlining trivial or small pull requests managements. This, in turn, gives more room for carefully handle complex ones.
The DevSensei app will help you apply the Ship/Show/Ask workflow to your pull requests, by guiding you through the decision to chose any of the three kinds.
Ask Pull Requests
You will typically opt in for an Ask pull request when you want feedback and discussions on the changes you made. You only want to merge these changes after there was enough time for discussion, reviewing changes, and decide that it is fully ready. Examples include:
Adding a new feature
Changing how a feature work
Major refactoring
Show Pull Requests
You will chose to make a Show pull request when you want to show what has been done, but otherwise go ahead with the change. You might still want to ask for review, but you essentially use it as validation and you don’t need to enter in a deep discussion.
Examples:
Completing a well defined issue/ticket
a local refactoring you want people to be aware of (e.g., renaming a function or changing an small implementation detail)
added test cases
Ship Pull Requests
You will use Ship pull requests when you make small, barely noticeable changes that don’t require people to review, nor even to be aware of. Such small changes could in theory be comitted directly to the target branch, but for external reasons (e.g., internal policy, CI pipeline), you still want to keep it as a record pull request.
Examples:
Fixing a typo or spelling mistake
Increasing a dependency’s minor version
A bugfix you already discussed with the team or paired programmed on
You can read more about Ship/Show/Ask in Martin Fowlers’s blog post.