[Governance] New GTFS Schedule Governance Proposal

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,55 @@
+<!--USE THIS TEMPLATE AS A REFERENCE AND MODIFY AND REMOVE SECTIONS TO BEST FIT YOUR PROPOSAL-->
+
+## Summary
+<!--Provide a brief summary of this proposal and the changes it introduces.-->
+
+## Describe the Problem
+<!--Describe what you are trying to achieve. If this is linked to an existing issue, please provide the issue link.--> 
+
+## Use Cases
+<!--Share examples of the scenarios you want the proposal to address, e.g., GTFS-Fares v2 makes it possible to display the cost of a monthly pass. Include visuals of how this change will appear to riders, if applicable.--> 
+
+## Proposed Solution
+<!--Provide a clear and concise description of the intended change.--> 
+
+## Type of change
+
+<!--Please select the relevant change type.--> 
+
+GTFS Schedule
+- [ ] Functional Change
+- [ ] Non-Functional Change
+- [ ] Documentation Maintenance
+
+GTFS Realtime
+- [ ] Specification Change
+- [ ] Specification Change (Experimental Field)
+
+## Additional Information
+<!--Include any relevant background, context, or supporting details that may help reviewers understand the rationale behind this proposal. This could include links to discussions, technical documentation, or related proposals.-->
+
+## Proposed Discussion Period
+<!--Please specify a minimum estimated discussion period length based on the scope of the proposed change.* 
+- *Example: “I recommend reserving at least one month for discussion to ensure everyone has sufficient time to discuss the proposal.”-->
+
+## Testing Details
+<!--If applicable, confirm the identity of the Consumer(s) and Producer(s) who will test the changes in the Pull Request comment section and document them below.-->
+
+- Consumer(s): <!--List the entities that will consume the data and test the proposed change.-->
+- Producer(s): <!--List the entities that will produce the data and test the proposed change.-->
+- Estimated Testing Period: <!--Specify the duration for testing.-->
+
+## Proposal Update Tracker 
+<!--Track changes to this Pull Request post over time, including edits and updates to the proposal. Regularly update this section to summarize major points discussed in the PR, ensuring a clear record of key decisions and modifications.-->
+
+| Date       | Update Description |
+|------------|--------------------|
+| (YYYY-MM-DD) | (Brief description of the update) |
+
+## Checklist
+
+- [ ] I have read and understood the [GTFS Change process](https://github.com/google/transit/tree/master/gtfs/Governance/change-process.md).
+- [ ] I have read and understood the [GTFS Guiding Principles](https://github.com/google/transit/tree/master/gtfs/Governance/guiding-principles.md). 
+- [ ] I understand the [Role of Advocate and the Responsibilities](https://github.com/google/transit/tree/master/gtfs/Governance/roles.md) attached to it. 
+- [ ] I have signed the [Contributor License Agreement (CLA)](https://cla.developers.google.com/about/google-individual).
+- [ ] I have ensured that this proposal is not covered by an existing Pull Request.

CONTRIBUTING.md

@@ -9,11 +9,11 @@
 
 The GTFS Specification is not set in stone. Instead, it is an open specification developed and maintained by the community of transit agencies, developers, and other stakeholders who use GTFS. It is expected that this community of producers and consumers of GTFS data will have proposals for extending the spec to enable new capabilities.
 
-To formalize this process, we've established the GTFS Governance framework, which includes the Specification Amendment Process.
+To formalize this process, we've established the following GTFS Governance frameworks:
 
--   [GTFS Schedule - Specification Amendment Process](https://github.com/google/transit/blob/master/gtfs/CHANGES.md)
+-   [GTFS Schedule - Governance Framework](/gtfs/Governance/introduction.md)
 
--   [GTFS Realtime - Specification Amendment Process](https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md)
+-   [GTFS Realtime - Governance Framework](gtfs-realtime/CHANGES.md)
 
 ## Before you contribute
 Before we can use your code, you must sign the

gtfs/CHANGES.md → gtfs/Governance/CHANGES.md

@@ -1,3 +1,9 @@
+>**Governance Framework Transition**
+>- **As of July 7, 2025**, all new Pull Requests are subject to the **[new GTFS Schedule Governance Framework](introduction.md)**.
+>- Pull Requests opened **before July 7, 2025** will continue to follow the **Former Governance** outlined in this section.
+>   - This includes the following PRs: [567](https://github.com/google/transit/pull/567), [561](https://github.com/google/transit/pull/561), [556](https://github.com/google/transit/pull/556), [546](https://github.com/google/transit/pull/546), [545](https://github.com/google/transit/pull/545), [533](https://github.com/google/transit/pull/533), [515](https://github.com/google/transit/pull/515), [502](https://github.com/google/transit/pull/502), [498](https://github.com/google/transit/pull/498), [483](https://github.com/google/transit/pull/483), [423](https://github.com/google/transit/pull/423).
+>- Once all PRs opened prior to July 7, 2025 are resolved, this page and the process outlined in it will be fully deprecated.
+
 The GTFS Specification is not set in stone. Instead, it is an open specification developed and maintained by the community of transit agencies, developers, and other stakeholders who use GTFS. It is expected that this community of producers and consumers of GTFS data will have proposals for extending the spec to enable new capabilities. To help manage that process, the following procedures and guidelines have been established.
 
 ### Specification amendment process
@@ -6,7 +12,7 @@ The official specification, reference and documentation are written in English.
 1. Create a git branch with update of all relevant parts of protocol definition, specification and documentation files (except for translations).
 1. Create pull request on https://github.com/google/transit. Pull request must contain an extended description of the patch. The creator of the pull request becomes the _advocate_.
 1. Once pull request is registered, it must be announced by its advocate in the [GTFS Changes mailing list](https://groups.google.com/forum/#!forum/gtfs-changes), including a link to the pull request. Once announced, the pull request is considered a proposal.  The pull request should also be edited to contain a link to the Google Groups announcement so they can easily be cross-referenced.
-  	- Since the advocate is a contributor, they must sign the [Contributor License Agreement](../CONTRIBUTING.md) before pull request can be accepted.
+  	- Since the advocate is a contributor, they must sign the [Contributor License Agreement](../../CONTRIBUTING.md) before pull request can be accepted.
 1. The discussion of the proposal follows. Pull request comments should be used as the sole discussion forum.
   	- The discussion lasts for as long as the advocate feels necessary, but must be at least 7 calendar days.
   	- The advocate is responsible for timely update of the proposal (i.e. pull request) based on the comments for which they agree to.
@@ -28,7 +34,7 @@ The official specification, reference and documentation are written in English.
   	- If the advocate continues the work on proposal then a new vote can be called for at any point in time.
 1. Any pull request remaining inactive for 30 calendar days will be closed. When a pull request is closed, the corresponding proposal is considered abandoned. The advocate may reopen the pull request at any time if they wish to continue or maintain the conversation.
 1. If the proposal is accepted:
-  	- Google is committed to merging the voted upon version of the pull request (provided that the contributors have signed the [CLA](../CONTRIBUTING.md)), and performing the pull request within 5 business days.
+  	- Google is committed to merging the voted upon version of the pull request (provided that the contributors have signed the [CLA](../../CONTRIBUTING.md)), and performing the pull request within 5 business days.
   	- Translations must not be included into the original pull request.
     Google is responsible for eventually updating relevant translations into supported languages, but pure translation pull requests from the community are welcome and will be accepted as soon as all editorial comments are addressed.
 1. The final result of the pull request (accepted or abandoned) should be announced on the same Google Groups thread where the pull request was originally announced.