From 73663c0fb080374d6df69bf32be2260863081bd2 Mon Sep 17 00:00:00 2001 From: Joe Ferguson Date: Wed, 3 Sep 2014 14:21:41 -0600 Subject: [PATCH 1/2] Shorter footer for issues and contrib --- README-footer.md | 20 +++----------------- buildpack-deps/README.md | 20 +++----------------- gcc/README.md | 20 +++----------------- golang/README.md | 20 +++----------------- hello-world/README.md | 20 +++----------------- hylang/README.md | 20 +++----------------- java/README.md | 20 +++----------------- mongo/README.md | 20 +++----------------- mysql/README.md | 20 +++----------------- nginx/README.md | 20 +++----------------- node/README.md | 20 +++----------------- perl/README.md | 22 ++++------------------ postgres/README.md | 20 +++----------------- python/README.md | 20 +++----------------- rails/README.md | 20 +++----------------- redis/README.md | 20 +++----------------- ruby/README.md | 20 +++----------------- ubuntu/README.md | 20 +++----------------- wordpress/README.md | 20 +++----------------- 19 files changed, 58 insertions(+), 324 deletions(-) diff --git a/README-footer.md b/README-footer.md index 52adab242..bb8c10c09 100644 --- a/README-footer.md +++ b/README-footer.md @@ -1,26 +1,12 @@ # Issues and Contributing -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 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). + +If you want to contribute, 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 %%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. - -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. diff --git a/buildpack-deps/README.md b/buildpack-deps/README.md index 5eaed798a..76a26be41 100644 --- a/buildpack-deps/README.md +++ b/buildpack-deps/README.md @@ -2,26 +2,12 @@ # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/gcc/README.md b/gcc/README.md index dd30cfe6f..25b4828c0 100644 --- a/gcc/README.md +++ b/gcc/README.md @@ -32,26 +32,12 @@ This will add your current directory as a volume to the comtainer, set the worki # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/golang/README.md b/golang/README.md index a1288ff6a..9e86a8969 100644 --- a/golang/README.md +++ b/golang/README.md @@ -32,26 +32,12 @@ This will add your current directory as a volume to the comtainer, set the worki # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/hello-world/README.md b/hello-world/README.md index 551ee399f..c89b6c934 100644 --- a/hello-world/README.md +++ b/hello-world/README.md @@ -23,26 +23,12 @@ $ docker run hello-world # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/hylang/README.md b/hylang/README.md index 87b017c9d..316ba0ffb 100644 --- a/hylang/README.md +++ b/hylang/README.md @@ -6,26 +6,12 @@ # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/java/README.md b/java/README.md index 7271e6e63..e554ab785 100644 --- a/java/README.md +++ b/java/README.md @@ -2,26 +2,12 @@ Java is a registered trademark of Oracle and/or its affiliates. # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/mongo/README.md b/mongo/README.md index 0ab12204e..9dd964616 100644 --- a/mongo/README.md +++ b/mongo/README.md @@ -21,26 +21,12 @@ This image includes `EXPOSE 27017` (the mongo port), so standard container linki # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/mysql/README.md b/mysql/README.md index 18f42c6a3..f62db9307 100644 --- a/mysql/README.md +++ b/mysql/README.md @@ -20,26 +20,12 @@ This image includes `EXPOSE 3306` (the mysql port), so standard container linkin # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/nginx/README.md b/nginx/README.md index 03631fec0..73047dd26 100644 --- a/nginx/README.md +++ b/nginx/README.md @@ -48,26 +48,12 @@ Then, build with `docker build -t some-custom-nginx .` and run: # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/node/README.md b/node/README.md index 0ff648a1e..c2a045cfb 100644 --- a/node/README.md +++ b/node/README.md @@ -25,26 +25,12 @@ Node.js internally uses the Google V8 JavaScript engine to execute code, and a l # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/perl/README.md b/perl/README.md index e361312ad..144dab878 100644 --- a/perl/README.md +++ b/perl/README.md @@ -25,26 +25,12 @@ For many single file projects, it may not be convenient to write a `Dockerfile` # Issues and Contributing -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 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). + +If you want to contribute, 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/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. +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. 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. - -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. diff --git a/postgres/README.md b/postgres/README.md index 02b430b76..2bf3e7306 100644 --- a/postgres/README.md +++ b/postgres/README.md @@ -21,26 +21,12 @@ This image includes `EXPOSE 5432` (the postgres port), so standard container lin # Issues and Contributing -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 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). + +If you want to contribute, 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 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. - -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. diff --git a/python/README.md b/python/README.md index fc8518f4b..51461bdf3 100644 --- a/python/README.md +++ b/python/README.md @@ -36,26 +36,12 @@ or (again, if you need to use Python 2): # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/rails/README.md b/rails/README.md index 4f2fa50c2..c0581bfaa 100644 --- a/rails/README.md +++ b/rails/README.md @@ -30,26 +30,12 @@ Then hit `http://localhost:8080` or `http://host-ip:8080` in a browser. # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/redis/README.md b/redis/README.md index d77ad7836..f90816675 100644 --- a/redis/README.md +++ b/redis/README.md @@ -42,26 +42,12 @@ Using this method means that there is no need for you to have a Dockerfile for y # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/ruby/README.md b/ruby/README.md index df5ae8b79..e69f4b090 100644 --- a/ruby/README.md +++ b/ruby/README.md @@ -23,26 +23,12 @@ This image includes multiple `ONBUILD` triggers so that should be all that you n # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. diff --git a/ubuntu/README.md b/ubuntu/README.md index ff0de43d8..a6f793a77 100644 --- a/ubuntu/README.md +++ b/ubuntu/README.md @@ -77,26 +77,12 @@ If you run into any problems with this image, please check (and potentially file # Issues and Contributing -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 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). + +If you want to contribute, 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. - -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. diff --git a/wordpress/README.md b/wordpress/README.md index 2d26a1638..609d4a75d 100644 --- a/wordpress/README.md +++ b/wordpress/README.md @@ -24,26 +24,12 @@ Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browse # Issues and Contributing -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 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). + +If you want to contribute, 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/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. - -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. From 69d341da4f722c1cf7b81369b49a595c174f9e94 Mon Sep 17 00:00:00 2001 From: Joe Ferguson Date: Thu, 4 Sep 2014 16:15:00 -0600 Subject: [PATCH 2/2] Extra short footer about issues and contrib --- README-footer.md | 10 +++++----- buildpack-deps/README.md | 10 +++++----- gcc/README.md | 10 +++++----- golang/README.md | 10 +++++----- hello-world/README.md | 10 +++++----- hylang/README.md | 10 +++++----- java/README.md | 10 +++++----- mongo/README.md | 10 +++++----- mysql/README.md | 10 +++++----- nginx/README.md | 10 +++++----- node/README.md | 10 +++++----- perl/README.md | 10 +++++----- postgres/README.md | 10 +++++----- python/README.md | 10 +++++----- rails/README.md | 10 +++++----- redis/README.md | 10 +++++----- ruby/README.md | 10 +++++----- ubuntu/README.md | 10 +++++----- wordpress/README.md | 10 +++++----- 19 files changed, 95 insertions(+), 95 deletions(-) diff --git a/README-footer.md b/README-footer.md index bb8c10c09..8137e72b2 100644 --- a/README-footer.md +++ b/README-footer.md @@ -1,12 +1,12 @@ -# Issues and Contributing +# User Feedback + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/buildpack-deps/README.md b/buildpack-deps/README.md index 76a26be41..19bf0e8d9 100644 --- a/buildpack-deps/README.md +++ b/buildpack-deps/README.md @@ -1,13 +1,13 @@ -# Issues and Contributing +# User Feedback + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/gcc/README.md b/gcc/README.md index 25b4828c0..31218ced4 100644 --- a/gcc/README.md +++ b/gcc/README.md @@ -30,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/golang/README.md b/golang/README.md index 9e86a8969..2279ba8af 100644 --- a/golang/README.md +++ b/golang/README.md @@ -30,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/hello-world/README.md b/hello-world/README.md index c89b6c934..b36f084f7 100644 --- a/hello-world/README.md +++ b/hello-world/README.md @@ -21,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/hylang/README.md b/hylang/README.md index 316ba0ffb..dde7dc953 100644 --- a/hylang/README.md +++ b/hylang/README.md @@ -4,14 +4,14 @@ # How to use this image -# Issues and Contributing +# User Feedback + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/java/README.md b/java/README.md index e554ab785..f099a2f22 100644 --- a/java/README.md +++ b/java/README.md @@ -1,13 +1,13 @@ Java is a registered trademark of Oracle and/or its affiliates. -# Issues and Contributing +# User Feedback + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/mongo/README.md b/mongo/README.md index 9dd964616..12b26e80f 100644 --- a/mongo/README.md +++ b/mongo/README.md @@ -19,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/mysql/README.md b/mysql/README.md index f62db9307..87023d5e1 100644 --- a/mysql/README.md +++ b/mysql/README.md @@ -18,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/nginx/README.md b/nginx/README.md index 73047dd26..70742fcfb 100644 --- a/nginx/README.md +++ b/nginx/README.md @@ -46,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/node/README.md b/node/README.md index c2a045cfb..68ccd0fda 100644 --- a/node/README.md +++ b/node/README.md @@ -23,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/perl/README.md b/perl/README.md index 144dab878..41ad650e0 100644 --- a/perl/README.md +++ b/perl/README.md @@ -23,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. - -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. diff --git a/postgres/README.md b/postgres/README.md index 2bf3e7306..fcccdc280 100644 --- a/postgres/README.md +++ b/postgres/README.md @@ -19,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/python/README.md b/python/README.md index 51461bdf3..db5054a0b 100644 --- a/python/README.md +++ b/python/README.md @@ -34,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/rails/README.md b/rails/README.md index c0581bfaa..52074cf57 100644 --- a/rails/README.md +++ b/rails/README.md @@ -28,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/redis/README.md b/redis/README.md index f90816675..202a4c038 100644 --- a/redis/README.md +++ b/redis/README.md @@ -40,14 +40,14 @@ Using this method means that there is no need for you to have a Dockerfile for y -# Issues and Contributing +# User Feedback + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/ruby/README.md b/ruby/README.md index e69f4b090..017012717 100644 --- a/ruby/README.md +++ b/ruby/README.md @@ -21,14 +21,14 @@ This image includes multiple `ONBUILD` triggers so that should be all that you n ## 3. start the ruby app container docker run -it --name some-ruby-app my-ruby-app -# Issues and Contributing +# User Feedback + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/ubuntu/README.md b/ubuntu/README.md index a6f793a77..19a3bb0a6 100644 --- a/ubuntu/README.md +++ b/ubuntu/README.md @@ -75,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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. diff --git a/wordpress/README.md b/wordpress/README.md index 609d4a75d..017c27b9e 100644 --- a/wordpress/README.md +++ b/wordpress/README.md @@ -22,14 +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 + +## Issues 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). -If you want to contribute, 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. +## Contributing -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 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. 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.