diff --git a/guidelines/commit_and_pr_text.md b/guidelines/commit_and_pr_text.md
new file mode 100644
index 0000000000..37e52fbb01
--- /dev/null
+++ b/guidelines/commit_and_pr_text.md
@@ -0,0 +1,62 @@
+# Motivation
+Our changelogs (reviewed by users/customers) are autogenerated from PR titles and git commit text.  The better this information is, the more we help our customers.  This information also helps:
+
+* reviewers understand changes
+* current+future team members understand the history of changes
+* patch managers understand risk/importance
+* when hunting for regressions, helps us better understand what is/isn’t likely to be a cause.
+
+# PR Metadata
+
+__PR title:__ Bug NNNN: A short sentence with capitalization and no period or the Jira tag for the issue “Feature TEAM-XXX:”
+
+* Try to describe the problem the user sees, rather than the code change you are doing
+  * I.e. “Console does not work when user clicks X” instead of “Fix drawer notification integration with underlying controller”
+* Prefix bug fixes with the bug number, “Bug XXXXX:” 
+  * (capitalize bug, space, number, then colon)
+* Do not let your PR title get truncated/wrapped into the description
+* Additional prefixes like what release the PR applies to are allowed, but they will be stripped from the changelog (the changelog for 4.4 doesn’t need to say “release-4.4” 
+  * Changelog strips anything between square brackets that has no spaces - i.e. [release-4.4] is stripped but [release 4.4] would not be
+    
+
+__PR description:__  Additional context reviewers need to understand your PR
+
+* Why was this change needed?
+* What changes are being made?  
+* Reference to any prior work(other PRs) or follow up work that will be needed.
+
+[Canonical PR text example](https://github.com/openshift/openshift-apiserver/pull/69)
+
+# Git Commit Best practices
+
+## Number of Commits
+
+Give careful consideration to the commits in your PR.  Multiple commits may make sense, but should each have a clear, logical, independent function.  Careful commit structure within a PR makes it easier to review the PR, easier to revert the PR if necessary, easier for someone doing “git blame” to follow the set of involved changes, and encourage smaller “chunks of work” (if it’s multiple commits, think about whether it should also be multiple PRs)
+
+Valid reasons to have separate commits:
+
+* Separating implementation work from generated code or vendor updates
+* Separating api work from implementation
+* Moving files around in a refactor (do the file move in one commit, edit the files in the second commit, so that the edits stand out in the commit diff)
+* Temporarily adding additional commits in response to reviewer feedback so reviewers can easily see how their feedback was addressed.  These commits should be squashed prior to merging.
+
+Invalid reasons to have separate commits
+* Separating tests+implementation
+* Committing+pushing your work each day/hour (use amend instead, or at least ensure you squash before merging).
+** use `git commit --fixup` and `git rebase -i --autosqash ...` to squash when you're getting ready to submit the PR
+
+## Git Commit text
+
+__First line:__  An english language sentence with capitalization, no period, max 50 characters
+
+__Additional information:__  Why was this change needed?  What is the gist of the change?
+
+* Almost every commit should have more than just a single line descriptor.  If you are making a commit with no additional information, you should think twice about whether you've really provided enough information that another developer can understand the intent of the commit.
+* Wrap lines at 72 characters, barring exceptions for links or other content that can't be wrapped.
+* If the commit fixes a bug, describe in detail the problem that was observed that led up to this change
+* Describe alternatives considered and why this change is the best one to make now, if applicable
+* Add all relevant references to the commit text, including other commits, bugs, PRs, or other links that help explain or understand the change. Note however that you should minimize amending a commit with github references, as it will generate a lot of noise on reference issues or PRs. Instead, consider adding commits while iterating on a PR and squashing them once before merging.
+* Consider including a tl;dr summary at the end of the commit text
+
+[Canonical commit text example](https://github.com/openshift/origin/commit/d7a7ff790f87ae14ad106f2256ebafc1e7c91949)
+