Update README.md#contributing to Correspond with New Release Flow #3554
Description
Description
README.md#contributing currently states the following:
#### Contributing
If you would like to contribute to the project. Please follow these steps to submit a contribution:
* Comment on the Github issue (or create one if one does not exist) and let us know that you're working on it.
* Fork the project (if you have not already) or rebase your fork so that it is up to date with the current repository's '_**development**_' branch
* Create a new branch in your fork. This will ensure that you are able to work at your own pace and continue to pull in any updates made to this project.
* Make your changes in the new branch
* When you have finished your work, make sure that your version of the '_**development**_' branch is still up to date with this project. Then merge your new branch into your '_**development**_' branch.
* Then create a new Pull Request (PR) from your branch to this project's '_**development**_' branch in GitHub
* The project team will then review your PR and communicate with you to convey any additional changes that would ensure that your work adheres to our guidelines.
See the [Contribution Guide](https://github.com/DMPRoadmap/roadmap/blob/development/CONTRIBUTING.md) on the Wiki for more details.
Given our newly proposed release flow, and departure from using a development branch, this will need to be updated.
For example, #3553 follows our Contributing guide (i.e. the development branch is used as both the base and PR target branch), but as development only drifts further from main, PRs like this one (i.e. that follow the existing contributing guide) will only become more difficult to merge.
Proposed Solution
Because we are replacing development with short-lived next-release/vX.y.Z branches, we can't really specify a specific next-release/ branch for outside contributors to base their branches off of and point their PRs at. next-release/ branches only exist during the preparation of a release and are regularly created and removed, so they are not a stable or predictable base or target for external contributors.
It might make the most sense to simply update the document to instruct users to base their branches off of main and point their PRs there as well. From there, reviewers could potentially edit the PR to target the appropriate next-release/ branch (or even merge the changes into main).