...
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 partition your pull requests into three categories : Ship, Show and Ask, as the name suggests.
This strategy differs from more classical PR workflows by automating the management of trivial or small pull requests. This, in turn, gives more room for carefully handle complex changes in more interesting pull requests.
...
Choose Show pull request when you want to show what has been done, but otherwise you would like it to be merged automatically. 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 discussionpeople to be notified of the change (for example so that they can review later on) but you don’t expect the need for deep discussions.
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 a small implementation detail)
added test cases
...
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. Ask pull requests correspond to the classical way of working with pull requestrequests. Examples include:
Adding a new feature
Changing how a feature work
Major refactoring
You can read more about Ship/Show/Ask pattern in Martin Fowlers’s Fowlers’ blog post.