ReleaseGuidelines updates to reflect OMF process and 12 week dev cycle

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).

ReleaseGuidelines.md

@@ -10,6 +10,7 @@ MDS will see regular updates and new [releases][mds-releases]. This document des
   * [Project Meetings](#project-meetings)
   * [Roles](#roles)
   * [Schedule](#schedule)
+  * [Approval by the Open Mobility Foundation](#approval-by-the-open-mobility-foundation)
   * [Communication and Workflow](#communication-and-workflow)
 * [Branch Mechanics](#branch-mechanics)
 * [Checklist](#release-checklist)
@@ -46,16 +47,14 @@ At this early stage, MDS will be moving relatively quickly with an eye toward st
 
 For now, MDS will maintain *two concurrent (MINOR) versions* (e.g. if `0.3.0` were the current version, the `0.2.x` series would continue to receive maintenance in addition to `0.3.x`).
 
-
 ## Release Process
+
 The sections below define the release process itself, including timeline, roles, and communication best practices.
 
-> **The process defined below currently being piloted with the MDS `provider` API only. Proposed changes to the `agency` API will be continue to be reviewed on an ad hoc basis.**
+### Project Meetings
 
->**It is our intent to maintain a level of coordination between the technical direction of `agency` and `provider`. As such, proposed changes to either API will be reviewed to ensure they do not create unnecessary duplicative functionality, introduce confusion about which API should be used for a given purpose, or prevent the reconciliation of data between the two APIs (for example: using data from `provider` to cross-validate data received via `agency`).**
+* Web conference work sessions will posted to the [MDS-Announce mailing list][mds-announce] and on the [MDS wiki](https://github.com/openmobilityfoundation/mobility-data-specification/wiki). Each working group typically meets every two weeks.
 
-### Project Meetings
-* Web conference and in person work sessions will posted to the [MDS-Announce mailing list](https://groups.google.com/a/groups.openmobilityfoundation.org/forum/#!forum/mds-announce). Meetings generally occur monthly.
 * The meeting organizer can use the [meeting template](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-Conference-Template) to prepare for project meetings. Use the [template markup code](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-Conference-Template/_edit) to create the next scheduled wiki meeting page before the meeting. Include the how to join the meeting and agenda details. Posting the agenda before the meeting has the added benefit that project contributors can propose agenda items.
 
 ### Goals
@@ -71,36 +70,56 @@ The sections below define the release process itself, including timeline, roles,
 * _Regular review of release process to ensure it is serving the needs of the community._
 
 ### Roles
+
 * **contributors** - Anyone making pull requests, opening issues, or engaging in technical discussion around implementation of features.
+
 * **maintainers** - Project maintainers have commit privileges in the main MDS repository and are responsible for implementing changes such as merging of pull requests and the creation of release branches.
-* **release partner** - Review changes when consensus cannot be reached and make final release inclusion recommendations to maintainers for approval.
 
-As of March 2019, LADOT and the City of Santa Monica are the project maintainers and Remix is the release partner.
+* **working group steering committees** - Review changes when consensus cannot be reached and make final release decision about what changes should be included in a release.
+
+See the [MDS wiki](https://github.com/openmobilityfoundation/mobility-data-specification/wiki) for additional information on the working groups.
 
 ### Schedule
 
-MDS operates on a six-week release cycle for both major updates (0.x) and patches (0.x.y). In general, major updates (0.x) are expected no more than once per quarter. The release cycle is broken down as follows:
+MDS operates on an approximately twelve-week release cycle for both major updates (0.x) and patches (0.x.y). In general, major updates (0.x) are expected no more than twice per year. The release cycle is broken down as follows:
 
-**week 1 - proposals**
+#### Weeks 1-3: Proposals
 
 Contributors submit proposals for inclusion in the release cycle in the form of pull requests and issues tagged. If known, note what release you intended a proposal for in its description. Maintainers will tag appropriate pull requests and issues with the Milestone for the upcoming release. Proposals should come with enough explanation to allow all stakeholders to understand intent and implementation strategy.
 
-**weeks 2-4 - consensus building, refinement, and implementation**
+#### Weeks 4-9: Consensus building, refinement, and implementation
 
-Contributors will provide feedback on proposals. Where possible, discussion will happen via GitHub. Weekly calls will support dialog around more complex or controversial issues. By the end of week 4, all active proposals must be in the form of a pull request. Proposals can be withdrawn or split apart for inclusion in future releases.
+Contributors will provide feedback on proposals. Where possible, discussion will happen via GitHub. Weekly calls will support dialog around more complex or controversial issues. By the end of week 9, all active proposals must be in the form of a pull request. Proposals can be withdrawn or split apart for inclusion in future releases.
 
-**week 5 - decision making**
+##### Weeks 10-11: Decision making
 
-The week will start with an in-person/web conference work session for all contributors to review and discuss current proposals. Goal is to achieve consensus where possible, or to clearly articulate areas of disagreement where not. Minor changes may be accepted at this stage if they bring contributors to consensus.
+These weeks will start with an web conference work session for all contributors to review and discuss current proposals. Goal is to achieve consensus where possible, or to clearly articulate areas of disagreement where not. Minor changes may be accepted at this stage if they bring contributors to consensus.
 
-At the conclusion of week 5, the release partner will review all items for which consensus was not reached and provide a recommended release plan to maintainers for approval. Any remaining approved pull requests will be merged, and a maintainer or release partner will open a pull request containing release notes for the proposed release.
+During this period, the working group steering committees will review all items for which consensus was not reached and decide on a final release plan. Any remaining approved pull requests will be merged, and a maintainers or working group steering committees will open a pull request containing release notes for the proposed release.
 
-**week 6 - release**
+#### Week 12: Release
 
 Documentation will be updated, release notes will be merged, a tag will be created and `master` updated to point to it, and the new version will be formally released. See [Release Checklist](#release-checklist) for details about the release process.
 
+### Approval by the Open Mobility Foundation
+
+Once a release is finalized by the working groups it will be considered a "release candidate" until it has been approved as an official deliverable by the Open Mobility Foundation. The OMF bylaws refer to this as a "Working Group Approved Deliverable (WGAD)."
+
+The process for full OMF approval is detailed in Section 5.4 of the OMF bylaws, the latest version of which can be found [here](https://www.openmobilityfoundation.org/resources/). In summary:
+
+1. The release candidate/WGAD will be provided to the OMF Technology Council for review and comment at least 75 days prior to the desired date of board approval.
+
+1. The Technology Council will issue a report and/or recommendation for the Board of Directors within 60 days.
+
+1. The Board of Directors will have a minimum of 30 days to review the Technology Council recommendation before taking a vote on the release candidate/WGAD.
+
+1. Upon approval by the Board of Directors, the release will become an official deliverable of the OMF and will be marked as such in GitHub and on the OMF web site.
+
+While it is the intent of the OMF to have concerns, questions, and issues addressed during the regular working group release process, it is possible that the Technology Council or Board of Directors may request modifications to a release candidate/WGAD prior to official approval. If this situation occurs, the release candidate will be sent back to the working group(s) for additional changes after which it can be resubmitted to the Technology Council and Board of Directors.
+
 ### Communication and Workflow
-The release announcements and process schedule will be communicated via [`mds-announce`][mds-announce] Google Group. People wishing to stay informed should join the group for updates. Timing of web conference and in person work sessions will be communicated via mds-announce as well.
+
+The release announcements and process schedule will be communicated via [MDS-Announce mailing list][mds-announce]. People wishing to stay informed should join the group for updates. Timing of web conference and in person work sessions will be communicated via MDS-Announce as well.
 
 The following best practices are intended to create clarity around each release cycle:
 
@@ -172,7 +191,6 @@ When non-breaking changes are merged to `dev`, it's generally necessary for a ma
 
   Next, create a PR with the release branch (in this case, `0.3.x`) as its `base`. Once that PR has been approved, merge the PR into the release branch as usual.
 
-
 ## Release Checklist
 
 The following steps **must** be followed for **every** release of MDS:
@@ -249,7 +267,7 @@ The following steps **must** be followed for **every** release of MDS:
 1. Post a release announcement to [`mds-announce`](mailto:mds-announce@groups.openmobilityfoundation.org), copying the [release notes](ReleaseNotes.md) created earlier and linking to the [GitHub release][mds-releases].
 
     ```email
-    From:    mds-announce@groups.openmobilityfoundation.org 
+    From:    mds-announce@groups.openmobilityfoundation.org
     To:      mds-announce@groups.openmobilityfoundation.org  
     Subject: MDS 1.2.3 Release