Resolve merge issue

README-footer.md

@@ -1,26 +1,12 @@
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us %%MAILING_LIST%% through a [GitHub issue](https://github.com/docker-library/%%REPO%%/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans %%MAILING_LIST%% through a [GitHub issue](https://github.com/docker-library/%%REPO%%/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans %%MAILING_LIST%% through a [GitHub issue](https://github.com/docker-library/%%REPO%%/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

buildpack-deps/README.md

@@ -1,27 +1,13 @@
 
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

gcc/README.md

@@ -30,28 +30,14 @@ This will add your current directory as a volume to the comtainer, set the worki
 
     docker run --rm -v "$(pwd)":/usr/src/myapp -w /usr/src/myapp gcc make
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/gcc/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/gcc/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/gcc/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

golang/README.md

@@ -30,28 +30,14 @@ This will add your current directory as a volume to the comtainer, set the worki
 
     docker run --rm -v "$(pwd)":/usr/src/myapp -w /usr/src/myapp make
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/golang/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/golang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/golang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

hello-world/README.md

@@ -21,28 +21,14 @@ $ docker run hello-world
     REPOSITORY      TAG             IMAGE ID        CREATED         VIRTUAL SIZE
     hello-world     latest          565a9d68a73f    26 hours ago    922 B
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/hello-world/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hello-world/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hello-world/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

hylang/README.md

@@ -4,28 +4,14 @@
 
 # How to use this image
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/hylang/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hylang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hylang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

java/README.md

@@ -31,28 +31,14 @@ This will add your current directory as a volume to the comtainer, set the worki
 
     docker run --rm -v "$(pwd)":/usr/src/myapp -w /usr/src/myapp java make
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/java/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/java/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/java/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

mongo/README.md

@@ -19,28 +19,14 @@ This image includes `EXPOSE 27017` (the mongo port), so standard container linki
 ## ... or via `mongo`
     docker run -it --link some-mongo:mongo --rm mongo sh -c 'exec mongo "$MONGO_PORT_27017_TCP_ADDR:$MONGO_PORT_27017_TCP_PORT/test"'
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/mongo/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mongo/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mongo/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

mysql/README.md

@@ -18,28 +18,14 @@ This image includes `EXPOSE 3306` (the mysql port), so standard container linkin
 ## ... or via `mysql`
     docker run -it --link some-mysql:mysql --rm mysql sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/mysql/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mysql/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mysql/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

nginx/README.md

@@ -46,28 +46,14 @@ Then, build with `docker build -t some-custom-nginx .` and run:
 
     docker run --name some-nginx -d some-custom-nginx
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/nginx/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/nginx/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/nginx/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

node/README.md

@@ -23,28 +23,14 @@ Node.js internally uses the Google V8 JavaScript engine to execute code, and a l
     # replace this with your main "server" script file
     CMD [ "node", "server.js" ]
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/node/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/node/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/node/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

perl/README.md

@@ -23,28 +23,14 @@ For many single file projects, it may not be convenient to write a `Dockerfile`
 
     docker run -it --rm --name my-running-script -v $(pwd):/usr/src/myapp -w /usr/src/myapp perl perl your-daemon-or-script.pl
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/Perl/docker-perl/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/perl/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
+## Contributing
 
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
-
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
-
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/Perl/docker-perl/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

postgres/README.md

@@ -19,28 +19,14 @@ This image includes `EXPOSE 5432` (the postgres port), so standard container lin
 ## ... or via `psql`
     docker run -it --link some-postgres:postgres --rm postgres sh -c 'exec psql -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U postgres'
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or through a [GitHub issue](https://github.com/docker-library/postgres/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or through a [GitHub issue](https://github.com/docker-library/postgres/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans on the [mailing list](http://www.postgresql.org/community/lists/subscribe/) or through a [GitHub issue](https://github.com/docker-library/postgres/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

python/README.md

@@ -34,28 +34,14 @@ or (again, if you need to use Python 2):
 
     docker run -it --rm --name my-running-script -v $(pwd):/usr/src/myapp -w /usr/src/myapp python:2 python your-daemon-or-script.py
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/python/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/python/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/python/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

rails/README.md

@@ -28,28 +28,14 @@ Then hit `http://container-ip:3000` in a browser. On the other hand, if you need
 
 Then hit `http://localhost:8080` or `http://host-ip:8080` in a browser.
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/rails/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/rails/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/rails/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

redis/README.md

@@ -40,28 +40,14 @@ Using this method means that there is no need for you to have a Dockerfile for y
 
 
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/redis/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/redis/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/redis/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

ruby/README.md

@@ -27,28 +27,14 @@ For many single file projects, it may not be convenient to write a `Dockerfile`
 
     docker run -it --rm --name my-running-script -v $(pwd):/usr/src/myapp -w /usr/src/myapp ruby ruby your-daemon-or-script.rb
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/ruby/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ruby/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ruby/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

ubuntu/README.md

@@ -75,28 +75,14 @@ If you run into any problems with this image, please check (and potentially file
 * [saucy (13.10) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
 * [trusty (14.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
-
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
-
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ubuntu/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
-
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+## Issues
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/ubuntu/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
+## Contributing
 
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ubuntu/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.

wordpress/README.md

@@ -22,28 +22,14 @@ If you'd like to be able to access the instance from the host without the contai
 
 Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browser.
 
-# Issues and Contributing
+# User Feedback
 
-We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
+## Issues
 
-If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
+If you have any questions about the image, please contact us through a [GitHub issue](https://github.com/docker-library/wordpress/issues) or in the IRC channel `#docker-library` on [Freenode](https://freenode.net).
 
-We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/wordpress/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
-
-Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
-
-## Conventions
-
-Fork the repository and make changes on your fork in a feature branch.
-
-Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
+## Contributing
 
-Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
+If you want to contribute new features or updates, we are always thrilled to receive pull requests, and do our best to process them as fast as possible.
 
-Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
-
-Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
-
-Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
-Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
+We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/wordpress/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.