Updates to CONTRIBUTING.md

Closes gh-22892

CONTRIBUTING.md

@@ -7,8 +7,8 @@ First off, thank you for taking the time to contribute! :+1: :tada:
 * [Code of Conduct](#code-of-conduct)
 * [How to Contribute](#how-to-contribute)
   * [Discuss](#discuss)
-  * [Create a Ticket](#create-a-ticket)
-  * [Ticket Lifecycle](#ticket-lifecycle)
+  * [Create an Issue](#create-an-issue)
+  * [Issue Lifecycle](#issue-lifecycle)
   * [Submit a Pull Request](#submit-a-pull-request)
 * [Build from Source](#build-from-source)
 * [Source Code Style](#source-code-style)
@@ -28,56 +28,55 @@ If you have a question, check Stack Overflow using
 [this list of tags](https://spring.io/questions), organized by Spring project.
 Find an existing discussion, or start a new one if necessary.
 
-If you find an issue, perform a search in the
-[GitHub issue tracker](https://github.com/spring-projects/spring-framework/issues), using a few different keywords.
-If you find discussions related to your issue either past or current, read them as it helps you learn about the issue
-and helps us make a decision on the issue.
+If you believe there is an issue, search through
+[existing issues](https://github.com/spring-projects/spring-framework/issues) trying a
+few different ways to find discussions, past or current, that are related to the issue.
+Reading those discussions helps you to learn about the issue, and helps us to make a
+decision.
 
 
-#### Create a Ticket
+#### Create an Issue
 
 Reporting an issue or making a feature request is a great way to contribute. Your feedback
-and the conversations that result from it provide a continuous flow of ideas. 
+and the conversations that result from it provide a continuous flow of ideas. However,
+before creating a ticket, please take the time to [discuss and research](#discuss) first.
 
-Before you create a ticket, please take the time to [research first](#discuss).
+If creating an issue after a discussion on Stack Overflow, please provide a description
+in the issue instead of simply referring to Stack Overflow. The issue tracker is an
+important place of record for design discussions and should be self-sufficient.
 
-If creating a ticket after a discussion on Stack Overflow, please provide a self-sufficient description in the ticket, independent of the details on Stack Overflow. We understand this is extra work, but the issue tracker is an important place of record for design discussions and decisions that can often be referenced long after the fix version — for example to revisit decisions, to understand the origin of a feature, and so on.
+Once you're ready, create an issue on
+[GitHub](https://github.com/spring-projects/spring-framework/issues).
 
-Once you're ready, create a ticket in the [GitHub issue tracker](https://github.com/spring-projects/spring-framework/issues).
-
-#### Ticket Lifecycle
+#### Issue Lifecycle
 
 When an issue is first created, it is flagged `waiting-for-triage` waiting for a team
-member to triage it. Within a day or two, the issue will then be reviewed, and the team
-may ask for further information if needed. Based on the findings, the issue is either
-assigned a fix version or declined.
+member to triage it. Once the issue has been reviewed, the team may ask for further
+information if needed, and based on the findings, the issue is either assigned a target
+milestone or is closed with a specific status.
 
-When a fix is ready, the issue is closed and may still be re-opened. Once a fix is
-released, the issue can't be reopened. If necessary, you will need to create a new,
-related ticket with a fresh description.
+When a fix is ready, the issue is closed and may still be re-opened until the fix is
+released. After that the issue will typically no longer be reopened. In rare cases if the
+issue was not at all fixed, the issue may be re-opened. In most cases however any
+follow-up reports will need to be created as new issues with a fresh description.
 
 #### Submit a Pull Request
 
-You can contribute a source code change by submitting a pull request.
-
 1. If you have not previously done so, please sign the
-[Contributor License Agreement](https://cla.pivotal.io/sign/spring). You will also be reminded
-automatically when you submit a pull request.
+[Contributor License Agreement](https://cla.pivotal.io/sign/spring). You will be reminded
+automatically when you submit the PR.
 
-1. Should you create a ticket first? The answer is no. Just create the pull request and use
-the description to provide context and motivation, as you would for an issue. If you want
-to start a discussion first or have already created an issue, once a pull request is created,
-we will close the issue as superseded by the pull request, and the discussion of the issue
-will continue under the pull request.
+1. Should you create an issue first? No, just create the pull request and use the
+description to provide context and motivation, as you would for an issue. If you want
+to start a discussion first or have already created an issue, once a pull request is
+created, we will close the issue as superseded by the pull request, and the discussion
+about the issue will continue under the pull request.
 
 1. Always check out the `master` branch and submit pull requests against it
 (for target version see [settings.gradle](settings.gradle)).
 Backports to prior versions will be considered on a case-by-case basis and reflected as
 the fix version in the issue tracker.
 
-1. Use short branch names, preferably based on the GitHub issue (e.g. `22276`), or
-otherwise using succinct, lower-case, dash (-) delimited names, such as `fix-warnings`.
-
 1. Choose the granularity of your commits consciously and squash commits that represent
 multiple edits or corrections of the same logical change. See
 [Rewriting History section of Pro Git](https://git-scm.com/book/en/Git-Tools-Rewriting-History)
@@ -88,7 +87,8 @@ for the description, followed by the issue fixed, e.g. `Closes gh-22276`. See th
 [Commit Guidelines section of Pro Git](https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines)
 for best practices around commit messages, and use `git log` to see some examples.
 
-1. List the GitHub issue number in the PR description.
+1. If there is a prior issue, reference the GitHub issue number in the description of the
+pull request.
 
 If accepted, your contribution may be heavily modified as needed prior to merging.
 You will likely retain author attribution for your Git commits granted that the bulk of