THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
The Apache Flink project receives a significant number of code contributions through Github pull requests (PRs).
In order to ensure a pleasant contribution experience, the Flink community follows a process to manage pull requests.
The process should help to avoid situations such as
- PRs which are lingering around without review or feedback.
- PRs which got a +1 for merging but which did not get merged.
- PRs which have been rejected after a long time.
- PRs which became irrelevant because some component was rewritten.
- PRs which are lingering around and have been abandoned by their contributors.
Pull Request Shepherds
The pull request process is driven by a pull request shepherd.
Shepherds are Flink committers that voluntarily sign up and feel responsible for helping the PR through the process until it is merged (or discarded).
The shepherd is also the person to contact for the author of the PR. It is preferable if the PR author and the PR shepherd are not the same person.
IMPORTANT: Everybody (contributors and committers) is encouraged to discuss all pull requests, give feedback, and (in case of committers) merge pull requests which are in a good shape.
However, the shepherd should feel responsible to drive a PR forward if nobody else interacts with the PR and its author.
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 on the Github PR like “I would like to shepherd this PR”.
A PR can be reassigned with lazy consensus, e.g., by commenting "I would like to take over shepherding this PR". - Being Accepted:
The first decision for a PR is to whether accepted it or not.
This depends on:- whether it is a desired feature or improvement for Flink and
- whether the solution design is appropriate.
In case of 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 not clear whether the PR should be accepted or not, a discussion must be started in the corresponding JIRA issue (a JIRA issue needs to be created if none exists).
The acceptance decision is recorded by a “PR accepted” comment in Github. This can be done by any committer (not necessarily the shepherd).
The PR should be closed in a timely manner if it is not accepted. - Becoming Ready to be Merged
Once a PR has been “accepted”, it needs to become ready to be merged. This means the community should review the code and 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 ready to be merged, this should be recorded by a “PR good to merge” message in Github. This can be done by any committer (not necessarily the shepherd).
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 in one way or the other. - Being Merged
Finally, the PR should be merged. This can be done by anybody, however the shepherd should make sure that it happens in a timely manner.
IMPORTANT: Discussions should primarily happen on Github to ensure the PR author is aware of the discussion.
If the discussion is moved to JIRA or the dev mailing list, we must make sure that the PR author is aware of that (i.e., follows the JIRA issue or is subscribed to the mailing list)