GTFS and GTFS-realtime decision process

[ckraatz]

Summary

This PR seeks to correct terminology and other problems with decision points in GTFS-schedule and GTFS-realtime change processes. I'm open to feedback and discussion on this, and assure the community I do not take this topic lightly.

Describe the Problem

Currently, the GTFS and GTFS-realtime decision-making process includes the term "unanimous consensus" that is impossible to achieve because "unanimity" and "consensus" are two inherently different decision standards. Moreover, the perception that unanimity is or should be required leads to a small minority (possibly even just one contributor) having the ability to block consensus or progress that is generally favored by the GTFS community.

This hinders our ability to help the riders and agencies we're here to serve.

Use Cases

The changes in this PR would apply to all changes to GTFS-schedule and GTFS-realtime specs that are proposed after they are formally adopted.

Proposed Solution

• Replaces "unanimous consensus," an inherently self-contradictory term, with "consensus" in some instances and "qualified majority" in other instances.
• Lowers the bar for testing proposed changes, while keeping a reasonably high bar for formal adoption.
• Defines "consensus" in the Guiding Principles of both GTFS-schedule and GTFS-realtime, as well as specifying how a contributor can declare their reservations/objections in a consensus process.

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

GTFS Realtime

• Specification Change
• Specification Change (Experimental Field)

Additional Information

Proposed Discussion Period

Given the scale and scope of these proposals, I expect we'll need a month of discussion. I don't expect much more time than that to yield new feedback, ideas or observations.

Testing Details

N/A

Proposal Update Tracker

Date	Update Description
(YYYY-MM-DD)	(Brief description of the update)

Checklist

• I have read and understood the GTFS Change process.
• I have read and understood the GTFS Guiding Principles.
• I understand the Role of Advocate and the Responsibilities attached to it.
• I have signed the Contributor License Agreement (CLA).
• I have ensured that this proposal is not covered by an existing Pull Request.

[gcamp]

The new governance didn't even have one proposal go through the full process, can we at least wait to test the new governance before changing it again?

[ckraatz]

@gcamp we don't really need to wait to go through the new governance process to know that "unanimous consensus" is as impossible to achieve as 110% yes votes.

I would be OK with applying only the changes proposed to GTFS-realtime, which has the same problem and hasn't had any updates to governance in a very long time.

As soon as a proposal reaches the "unanimous consensus" point and someone is unwilling to consent, the community won't have the benefit of clarity. Do we need "unanimous consent" (currently, no), "consensus" (currently, no), or "80% majority" (currently, yes in some instances).

[github-actions]

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.