Merge branch 'main' into function_based_path_utils

CONTRIBUTING.md

@@ -42,7 +42,9 @@ Please don't surprise us with a big out-of-the-blue pull request (PR). Preferabl
 
 If you have never made a PR before, there are excellent GitHub tutorials to familiarize you with the concepts and steps like the [GitHub Bootcamp](https://help.github.com/categories/bootcamp/).
 
-When you are ready to make a PR, please adhere to the following guidelines:
+Most PRs will need to be reviewed by at least one member of the OpenSim Dev Team. The Dev Team is a Team within the opensim-org GitHub organization. Dev Team members are listed [here](https://github.com/orgs/opensim-org/teams/dev-team/members).
+
+When you are ready to make a PR, please adhere to the guidelines below. 
 
 1. To help the people who review your pull request, include a detailed description of what changes or additions the PR includes and what you have done to test and verify the changes. Reference the existing Issue (or set of Issues) that documents the problem the PR is adressing (e.g., use ``#<issue_number>`` ). Also, please make sure detailed information about the commits is easily available.
 
@@ -54,11 +56,13 @@ When you are ready to make a PR, please adhere to the following guidelines:
 
 5. Updates to comments, Doxygen, compiler compatibility, CMake files, or continuous integration files must be reviewed by at least one member of the Dev Team before being merged. The original author or the reviewer(s) may merge the pull request.
 
-6. Any other changes to the code require review by one member of the Dev Team, and manual testing by one member of the Dev Team. If the pull request involves adding a new class or performing a major object/algorithm refactor, one of these reviewers must be an Owner. The Owners and Dev Team are Teams within the opensim-org GitHub organization. Dev Team members are listed [here](https://github.com/orgs/opensim-org/teams/dev-team/members). Owners can be determined from [this list](https://github.com/orgs/opensim-org/people). The first reviewer determines if a second reviewer is required for the pull request to be accepted; you may also suggest whether the pull request should require one or two reviewers. You or the reviewers may merge the pull request once the reviewers accept the pull request. 
+6. Any other changes to the code require review by one member of the Dev Team, and manual testing by one member of the Dev Team. A reviewer may determine that a second reviewer from the Dev Team is required for the pull request to be accepted; you may also suggest whether the pull request should require one or two reviewers. You or the reviewers may merge the pull request once the reviewers accept the pull request.
+
+7. If your pull request involves adding a new class or performing a major object or algorithm refactor, the Dev Team can assist with assigning appropriate reviewers. 
 
-7. As the changes introduced by your pull request become finalized throughout the review process, you should decide if your changes warrant being mentioned in the change log. If so, update the [CHANGELOG.md](https://github.com/opensim-org/opensim-core/blob/master/CHANGELOG.md) with an additional commit to your pull request.
+8. As the changes introduced by your pull request become finalized throughout the review process, you should decide if your changes warrant being mentioned in the change log. If so, update the [CHANGELOG.md](https://github.com/opensim-org/opensim-core/blob/master/CHANGELOG.md) with an additional commit to your pull request.
 
-8. CI must be run for all changes, except Matlab tests and examples, non-Doxygen markdown files, and non-Doxygen comments. CI tests must pass before merge, unless the author and reviewer(s) deem the failures unrelated to the change.
+9. CI must be run for all changes, except Matlab tests and examples, non-Doxygen markdown files, and non-Doxygen comments. CI tests must pass before merge, unless the author and reviewer(s) deem the failures unrelated to the change.
 
 A few additional practices will help streamline the code review process. Please use tags (i.e., @user_name) and quoting to help keep the discussion organized. Please also call for a meeting or Skype call when discussions start to stagnate. In addition, we recommend getting input on your interface design before implementing a major new component or other change.