Polly.Contrib hosts contributions around the Polly project by the community. A Polly-Contrib repo is intended for you to own and manage your own contrib! - as such, the owners of each Contrib repository have rights on that repository, for example to merge PRs (no review from the Polly team expected or needed, though the team will be happy to take a look if you alert us).
For process, the Polly team recommend that Polly-Contrib projects use Git-Workflow (1; 2) to manage their content:
- Keep the
master
branch containing only the latest-published release (as released to NuGet), or code imminently to be released.- Sensible exceptions to this may be eg to improve documentation by extending the
ReadMe
- the main point is that themaster
branch always represents releasable code and the latest-released code.
- Sensible exceptions to this may be eg to improve documentation by extending the
- Carry out development work in feature branches, usually in your own fork of the repo.
- Integrate changes into the
Polly-Contrib
master
branch using PRs.- Using PRs allows other developers who may be interested to comment before code is merged (though as mentioned above, it is not expected that the Polly team must do this).
- Using PRs allows developers coming to the project later to see what was added when, and why.
- Avoid contributing code without PRs. Committing code without PRs makes it hard for others coming to the project later to review and understand what code was added when, and why.
- Avoid committing directly to the
master
branch. Committing interim contributions directly to themaster
branch:- means users cannot review the head of the
master
branch as a reference for the published nuget packages; - means the
master
branch is not always in an 'immediately releasable' state - this can be important if an urgent bug fix needs to be released, for example; - creates unnecessarily messy merge-commits and rebasing, when there are multiple contributors.
- means users cannot review the head of the
- Consider using milestones matching release numbers, to label PRs included in and issues closed in a release; see the core Polly project for example.