From 716407623a549ad10711f0b16da8c20050ff8935 Mon Sep 17 00:00:00 2001 From: Joe Ferguson Date: Tue, 5 Aug 2014 15:47:02 -0600 Subject: [PATCH] Run gen-docs for postgres --- postgres/README.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/postgres/README.md b/postgres/README.md index 6df49f63a..02b430b76 100644 --- a/postgres/README.md +++ b/postgres/README.md @@ -18,3 +18,29 @@ 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 + +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.