...
Phases of a Pull Request
- Getting a Shepherd:
Each pull request is taken care of by a shepherd.
A committer becomes the shepherd of a PR by commenting the PR on Github like “I would like to shepherd this PR”.
A PR can be reassigned with lazy consensus. - Being Accepted:
The first decision for a PR should be whether it is accepted or not.
This depends on:- whether it is a desired feature or improvement for Flink and
- whether the higher-level solution design is appropriate.
In case of more a PR that proposes a complex feature, the discussion should have been started when the mandatory JIRA was created (see our code contribution guide).
If it is still not clear whether the PR should be accepted or not, a discussion should be started in JIRA (a JIRA issue needs to be created if none exists).
The acceptance decision should be recorded by a “+1 to accept” comment in Github.
If the PR is not accepted, it should be closed in a timely manner. - Becoming Ready to be Merged
Once a PR has been “accepted”, it should be brought into a mergeable state. This means the community should quickly react on contributor questions or PR updates. Everybody is encouraged to review pull requests and give feedback. Ideally, the PR author does not have to wait for a long time to get feedback. The shepherd of a PR should feel responsible to drive this process forward. Once the PR is considered to be mergeable, this should be recorded by a “+1 to merge” message in Github. If the pull request becomes abandoned at some point in time, it should be either taken over by somebody else or be closed after a reasonable time. Again, this can be done by anybody, but the shepherd should feel responsible to resolve the issue. - Being Merged
Once, the PR is in a mergeable state, it should be merged. This can be done by anybody, however the shepherd should make sure that it happens in a timely manner.
...