docs: explain PR conventions a bit more (#20332)

We have conventions around title and content of bug and feature PRs that we didn't explain clearly enough in the contributing guide.

Clarify a little more.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Author: rix0rrr

CONTRIBUTING.md

@@ -326,12 +326,17 @@ $ yarn watch & # runs in the background
   [conventionalcommits](https://www.conventionalcommits.org).
   * The title must begin with `feat(module): title`, `fix(module): title`, `refactor(module): title` or
     `chore(module): title`.
+  * Titles for `feat` and `fix` PRs end up in the change log. Think about what makes most sense for users reading the changelog while writing them.
+    * `feat`: describe the feature (not the action of creating the commit or PR, for example, avoid words like "added" or "changed")
+    * `fix`: describe the bug (not the solution)
   * Title should be lowercase.
   * No period at the end of the title.
 
-* Pull request message should describe _motivation_. Think about your code reviewers and what information they need in
+* Pull request body should describe _motivation_. Think about your code reviewers and what information they need in
   order to understand what you did. If it's a big commit (hopefully not), try to provide some good entry points so
   it will be easier to follow.
+  * For bugs, describe bug, root cause, solution, potential alternatives considered but discarded.
+  * For features, describe use case, most salient design aspects (especially if new), potential alternatives.
 
 * Pull request message should indicate which issues are fixed: `fixes #<issue>` or `closes #<issue>`.