ReleaseGuidelines updates to reflect OMF process and 12 week dev cycle (

#453)

* clarified language/links for meeting announcements and removed 'beta' label on release process
* OMF recommendation on (non)adoption of RCs
* Further clarification on RC process
* Clarification on official release
* Point to wiki for status/anticipated timeline
* capturing Release Candidate -> Official Release process
* enumerate steps to create a Release Candidate
* enumerate steps to go from Release Candidate -> Official Release
* new Issue template for Release Candidate Review
* adjust language for out-of-phase hotfixes

.github/ISSUE_TEMPLATE/release-candidate-review.md

@@ -0,0 +1,18 @@
+---
+name: Release Candidate Review
+about: Request OMF review of a Release Candidate
+title: Review Release Candidate [X.Y.Z]
+labels: admin
+assignees: jfh01
+
+---
+
+### Summary
+
+The Release Candidate for MDS `X.Y.Z` has been submitted: <https://github.com/openmobilityfoundation/mobility-data-specification/releases/tag/X.Y.Z-rc>
+
+Please use this issue to track Technology Council and OMF Board feedback and/or requested changes.
+
+### Action Item
+
+Please close this Issue upon OMF Board Approval to indicate that the Release Candidate may be made official.

CONTRIBUTING.md

@@ -1,7 +1,9 @@
 # MDS Contributor Guidelines
+
 MDS is an evolving specification with a regular release cycle. Please review the [MDS Release Guidelines](ReleaseGuidelines.md) to understand the release process.
 
 ## Who can contribute
+
 MDS is an open specification and anyone can contribute to its development. Because MDS supports a growing ecosystem of mobility services, policies, and tools, there are some key stakeholders whose participation is particularly encouraged:
 
 * **Public agencies:** As licensing authority and regulator, public agencies are the ultimate customers for MDS and the data flowing through it. The public agency role is to ensure that MDS effectively supports program management and offers a flexible foundation for policy implementation. Public agencies of all levels of technical capacity are encourage to participate in the evolution of MDS, whether by submitting pull requests and issues, or simply by providing feedback during release cycles.
@@ -11,16 +13,19 @@ MDS is an open specification and anyone can contribute to its development. Becau
 * **Public agency software partners:** Serve as a key bridge between public agencies and mobility service providers by offering tools that turn MDS data into useful insights. The public agency software partners help ensure that MDS will enable real-world product development, reflects the needs of their public agency customers, and encourages private investment in the MDS ecosystem.
 
 ## How to contribute
+
 Contributions should be offered through GitHub issues and pull requests. Please review the [MDS Release Guidelines](ReleaseGuidelines.md) for details on the release process, schedule, and communications channels.
 
 In general, you may open an issue or make a pull request at any time. Once the issue or pull request is associated with a particular Milestone, it will be included for review within the process for that release.
 
 All contributors must agree to the Open Mobility Foundation's [Individual Contributor License Agreement](http://members.openmobilityfoundation.org/wp-content/uploads/2019/06/Individual-CLA.pdf) (ICLA) and [Participation Policies](https://members.openmobilityfoundation.org/wp-content/uploads/2019/06/OMFParticipationPolicies.pdf). Pull requests will not be merged without a signed ICLA. If a contributor is working on behalf of a company or other organization, that organization must also agree to the [Entity Contributor License Agreement](https://members.openmobilityfoundation.org/wp-content/uploads/2019/06/Entity-CLA.pdf) (ECLA). These agreements clarify the intellectual property status of work that is contributed to OMF projects. They apply to all contributions, including source code, documentation, and comments.
 
 ## What belongs in MDS
+
 MDS is a tool to facilitate data exchange between mobility service providers, public agencies, and public agency software partners. Although providers are often required to support MDS as part of mobility permits or policies, MDS is intended as a neutral mechanism for information exchange. It is not intended to force or foreclose any specific policy options that a public agency may choose to pursue.
 
 MDS is built as an interface between local governments and mobility service providers. Access to MDS APIs should be restricted, and is not intended to directly support public consumption or consumer-facing applications.
 
 ## Participation Policies and Code of Conduct
+
 See our [CODE OF CONDUCT page](CODE_OF_CONDUCT.md).