- [ ] please read other user comments first, and confirm this is the same issue: a given error condition might be indicative of different problems - you may also find a workaround in the comments
- [ ] please refrain from adding "same thing here" or "+1" comments
- [ ] you don't need to comment on an issue to get notified of updates: just hit the "subscribe" button
- [ ] comment if you have some new, technical and relevant information to add to the case
Additionally, you must [sign your commits](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work). It's very simple:
* configure your name with git: `git config user.name "Real Name" && git config user.email mail@example.com`
* sign your commits using `-s`: `git commit -s -m "My commit"`
Some simple rules to ensure quick merge:
- [ ] clearly point to the issue(s) you want to fix in your PR comment
- [ ] when possible, prefer multiple (smaller) PRs addressing individual issues over a big one trying to address multiple issues at once
- [ ] if you need to amend your PR following comments, please squash instead of adding more commits
## Contributing new features
You are heavily encouraged to first discuss what you want to do. You can do so on the irc channel, or by opening an issue that clearly describes the use case you want to fulfill, or the problem you are trying to solve.
If this is a major new feature, you should then submit a proposal that describes your technical solution and reasoning.
If you did discuss it first, this will likely be greenlighted very fast. It's advisable to address all feedback on this proposal before starting actual work.
Then you should submit your implementation, clearly linking to the issue (and possible proposal).
Your PR will be reviewed by the community, then ultimately by the project maintainers, before being merged.
It's mandatory to:
* interact respectfully with other community members and maintainers - more generally, you are expected to abide by the [Docker community rules](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines)
* address maintainers' comments and modify your submission accordingly
* write tests for any new code
Complying to these simple rules will greatly accelerate the review process, and will ensure you have a pleasant experience in contributing code to the Registry.
Have a look at a great, succesful contribution: the [Ceph driver PR](https://github.com/docker/distribution/pull/443)
<dd>Issues marked with this label are being worked in the current sprint. All required information should be available and design details have been worked out.</dd>
<dd>Issues marked with this label are complete. This can be considered a psuedo-label, in that if it is closed, it is considered "Done".</dd>
</dl>
If an issue or PR is not labeled correctly or you believe it is not in the right state, please contact a maintainer to fix the problem.
## Milestones
Issues and PRs should be assigned to relevant milestones. If an issue or PR is assigned a milestone, it should be available by that date. Depending on level of effort, items may be shuffled in or out of milestones. Issues or PRs that don't have a milestone are considered unscheduled. Typically, "In Progress" issues should have a milestone.
