Please first try any of these support forums before opening an issue:
* irc #docker on freenode (archives: [https://botbot.me/freenode/docker/])
* https://forums.docker.com/
* if your problem is with the "hub" (the website and other user-facing components), or about automated builds, then please direct your issues to https://support.docker.com
## So, you found a bug?
First check if your problem was already reported in the issue tracker.
If it's already there, please refrain from adding "same here" comments - these don't add any value and are only adding useless noise. **Said comments will quite often be deleted at sight**. On the other hand, if you have any technical, relevant information to add, by all means do!
Create a new proposal in the folder `open-design/specs`, named `DEP_MY_AWESOME_PROPOSAL.md`, using `open-design/specs/TEMPLATE.md` as a starting point.
Usually, it's not advisable to start working too much on the implementation itself before the proposal receives sufficient feedback, since it can significantly altered (or rejected).
<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>
These integrate with waffle.io to show the current status of the project. The project board is available at the following url:
https://waffle.io/docker/distribution
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.
## PR Titles
PR titles should be lowercased, except for proper noun references (such a
method name or type).
PR titles should be prefixed with affected directories, comma separated. For
example, if a specification is modified, the prefix would be "doc/spec". If
the modifications are only in the root, do not include it. If multiple
directories are modified, include each, separated by a comma and space.
Here are some examples:
- doc/spec: move API specification into correct position