Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reorganize Governance and README #521

Merged
merged 4 commits into from
Aug 2, 2023
Merged

Reorganize Governance and README #521

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
88c311f
Reorganize governance
Jul 12, 2023
16ce878
Merge branch 'master' into governance-20230707
josee-sabourin Jul 12, 2023
a1082d1
Change NABSA links to MobilityData
josee-sabourin Aug 2, 2023
02b085e
seven -> 7
josee-sabourin Aug 2, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 15 additions & 35 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,8 @@ Documentation for the General Bikeshare Feed Specification, a standardized data

## Table of Contents
* [What is GBFS?](#what-is-gbfs)
* [Get Involved](#get-involved)
* [How to Participate](#how-to-participate)
* [Current Version](#current-version-recommended)
* [Governance & Overview of the Change Process](#governance--overview-of-the-change-process)
* [Guiding Principles](#guiding-principles)
* [Specification Versioning](#specification-versioning)
* [Systems Catalog - Systems Implementing GBFS](#systems-catalog---systems-implementing-gbfs)
Expand All @@ -27,12 +26,22 @@ The specification has been designed with the following concepts in mind:
* Do not provide information whose primary purpose is historical

The data in the specification contained in this document is intended for consumption by clients intending to provide real-time (or semi-real-time) transit advice and is designed as such.
## Get Involved
GBFS is an open source project developed under a consensus-based governance model. Contributors come from across the shared mobility industry, public sector, civic technology and elsewhere. Comments or questions can be addressed to the community by [opening an issue](https://github.com/NABSA/gbfs/issues). Proposals for changes or additions to the specification can be made through [pull requests](https://github.com/NABSA/gbfs/pulls). <br /><br/>
Questions can also be addressed to the community via the [public GBFS Slack channel](https://share.mobilitydata.org/slack) or to the shared mobility staff at MobilityData: [sharedmobility@mobilitydata.org](mailto:sharedmobility@mobilitydata.org)

## How to Participate
GBFS is an open source project developed under a consensus-based governance model. Contributors come from across the shared mobility industry, public sector, civic technology and elsewhere. GBFS is not owned by any one person or organization. The specification is not fixed or unchangeable. As the shared mobility industry evolves, it is expected that the specification will be extended by the GBFS community to include new features and capabilities over time. <br/><br> Comments or questions can be addressed to the community by [opening an issue](https://github.com/MobilityData/gbfs/issues). Proposals for changes or additions to the specification can be made through [pull requests](https://github.com/MobilityData/gbfs/pulls). Questions can also be addressed to the community via the [public GBFS Slack channel](https://bit.ly/mobilitydata-slack) or to the shared mobility staff at MobilityData: [sharedmobility@mobilitydata.org](mailto:sharedmobility@mobilitydata.org).
If you are new to engaging with the community on this repository, firstly welcome! Here is a brief overview of how to contribute to the specification:
* Anyone can raise an issue.
* Anyone can open a pull request - make sure PRs in line with our [Guiding Principles](#guiding-principles).
* If you are wanting to open a pull request but don't know how, MobiilityData is happy to help. Get in touch at [sharedmobility@mobilitydata.org](mailto:sharedmobility@mobilitydata.org).
* Discussions on pull requests must be a minimum of 7 calendar days.
* Votes are open for a total of 10 calendar days, anyone can vote.
* A successful vote must have at least 3 votes, not including the pull request author.
* A successful vote must include a vote from a GBFS producer and a GBFS consumer.

Find a real-world example of the governance in action [here](https://github.com/MobilityData/gbfs/pull/454). For a more in depth look at the change and contribution process, go to [governance.md](https://github.com/MobilityData/gbfs/blob/master/governance.md).

### Project Roadmap
MobiltyData has compiled a [project roadmap](https://github.com/NABSA/gbfs/wiki/Project-Roadmap) with a list of major features, changes and other work coming up in the near future.
MobiltyData has compiled a [project roadmap](https://github.com/MobilityData/gbfs/wiki/Project-Roadmap) with a list of major features, changes and other work coming up in the near future.

## Current Version *(Recommended)*
| Version | Type | Release Date | Status | JSON Schema | Release Notes |
Expand Down Expand Up @@ -87,35 +96,6 @@ Examples of non-breaking changes include:
* There is no strict limitation on the frequency of MAJOR releases, but the GBFS community aims to limit MAJOR releases to no more than one a 12 month period. To limit releases, multiple breaking changes SHOULD be batched together in a single release.
* There is no guideline to limit the number of MINOR releases. MINOR changes may be applied at any time. MINOR changes MAY be batched together in single release or released immediately, based on the needs of the community.
* GBFS documentation will include a list of current and supported MAJOR and MINOR versions. Supported versions SHALL NOT span more than two MAJOR versions. Past versions that are beyond the two most recent MAJOR versions will be deprecated 180 days after the latest MAJOR version becomes official.
## Governance & Overview of the Change Process
GBFS is an open specification, developed and maintained by the community of producers and consumers of GBFS data.
The specification is not fixed or unchangeable. As the shared mobility industry evolves, it is expected that the specification will be extended by the GBFS community to include new features and capabilities over time. If you are new to engaging with the community on this repository, firstly welcome! Please identify which organization you represent when posting.

To manage the change process, the following guidelines have been established.

* Anyone can propose a change.
* A change is proposed by opening a Pull Request (PR) at the GBFS GitHub repository. The proposer becomes “The Advocate”. Comments and feedback from the GBFS community are received to iterate on the proposed change. Discussion lasts for as long as necessary to address questions and revisions, but must be at least 7 calendar days.
* After 7 calendar days, The Advocate can call for a vote. Should The Advocate not call a vote or respond to comments from the community for a period of 30 full calendar days, anyone in the community can call for a vote. Vote lasts the minimum period sufficient to cover 10 full calendar days. Voting ends at 23:59:59 UTC. The vote announcement must conform to this template:
* *I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on X.<br /> Please vote for or against the proposal, and include the organization for which you are voting in your comment. <br /> Please note if you can commit to implementing the proposal.*
* The person calling for the vote should announce the vote in the [GBFS Slack channel](https://share.mobilitydata.org/slack) with a link to the PR. The message should conform to this template:
* *A vote has been called on PR # [title of PR] (link to PR). This vote will be open for 10 full calendar days, until 11:59PM UTC on X. Please vote for or against the proposal on GitHub.*
* MobilityData will both comment on the PR on GitHub and send a reminder in the GBFS Slack channel when there are 2 calendar days remaining on the vote. The reminder should conform to this template:
* Slack: <br />*Voting on PR # [title of PR] (link to PR) closes in 2 calendar days. Please vote for or against the proposal on GitHub.*
* GitHub:<br />*Voting on this PR closes in 2 calendar days. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Please note if you can commit to implementing the proposal.*
* Once a vote is called, a "Vote Open" label will be added to the PR. After the 2 day reminder, the label will be replaced with "Vote Closing Soon", once the vote is closed, the label will become either “Vote Passed” or “Voted Failed” depending on the vote outcome.
* A vote passes if there is unanimous consensus with at least 3 votes in favor.
* At least one of these votes MUST be from a producer and at least one MUST be from a consumer.
* The producer and consumer votes MUST come from stakeholders other than The Advocate.
* MobilityData serves as facilitator but does not vote on proposed changes.
* Votes against a proposal can stop a proposal from passing if they provide a specific reason for voting against and contain actionable feedback.
* The Advocate should cancel a vote and restart the process if significant changes are made to the proposal after stakeholders have voted.
* Should the vote fail, The Advocate can choose to continue work on the proposal with the feedback received and restart the governance process, or abandon the proposal by closing the Pull Request. Another interested member of the community can take over the proposal if they feel the addition is valuable.
* When a vote passes, the change is placed into Release Candidate (RC) status. The change remains in RC status pending implementation.
* Implementation requirements are that at least 1 producer and 1 consumer implement the changes.
* The implementors MUST be stakeholders other than The Advocate.
* Once implemented successfully, the change is merged into an official current release.
* Editorial changes as well as items that are not found in [gbfs.md](https://github.com/NABSA/gbfs/blob/master/gbfs.md) do not need to be voted on. Extensions that include new capabilities and features MUST be voted on.
* Issues and pull requests will be considered stale after 120 days, at which point participants will be notified via comment. Should they wish to keep the discussion open, it is the responsibility of the participants to re-engage in the conversation. If there is no re-engagement, the issue or pull request will be closed 60 days after the stale date.

## Guiding Principles
To preserve the original vision of GBFS, the following guiding principles should be taken into consideration when proposing extensions to the spec:
Expand Down
31 changes: 31 additions & 0 deletions governance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
## Governance Process

GBFS is an open specification, developed and maintained by the community of producers and consumers of GBFS data.
The specification is not fixed or unchangeable. As the shared mobility industry evolves, it is expected that the specification will be extended by the GBFS community to include new features and capabilities over time. If you are new to engaging with the community on this repository, firstly welcome! Please identify which organization you represent when posting.

To manage the change process, the following guidelines have been established.

* Anyone can propose a change.
* A change is proposed by opening a Pull Request (PR) at the GBFS GitHub repository. The proposer becomes “The Advocate”. Comments and feedback from the GBFS community are received to iterate on the proposed change. Discussion lasts for as long as necessary to address questions and revisions, but must be at least 7 calendar days.
* After 7 calendar days, The Advocate can call for a vote. Should The Advocate not call a vote or respond to comments from the community for a period of 30 full calendar days, anyone in the community can call for a vote. Vote lasts the minimum period sufficient to cover 10 full calendar days. Voting ends at 23:59:59 UTC. The vote announcement must conform to this template:
* *I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on X.<br /> Please vote for or against the proposal, and include the organization for which you are voting in your comment. <br /> Please note if you can commit to implementing the proposal.*
* The person calling for the vote should announce the vote in the [GBFS Slack channel](https://mobilitydata-io.slack.com) with a link to the PR. The message should conform to this template:
* *A vote has been called on PR # [title of PR] (link to PR). This vote will be open for 10 full calendar days, until 11:59PM UTC on X. Please vote for or against the proposal on GitHub.*
* MobilityData will both comment on the PR on GitHub and send a reminder in the GBFS Slack channel when there are 2 calendar days remaining on the vote. The reminder should conform to this template:
* Slack: <br />*Voting on PR # [title of PR] (link to PR) closes in 2 calendar days. Please vote for or against the proposal on GitHub.*
* GitHub:<br />*Voting on this PR closes in 2 calendar days. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Please note if you can commit to implementing the proposal.*
* Once a vote is called, a "Vote Open" label will be added to the PR. After the 2 day reminder, the label will be replaced with "Vote Closing Soon", once the vote is closed, the label will become either “Vote Passed” or “Voted Failed” depending on the vote outcome.
* A vote passes if there is unanimous consensus with at least 3 votes in favor.
* At least one of these votes MUST be from a producer and at least one MUST be from a consumer.
* The producer and consumer votes MUST come from stakeholders other than The Advocate.
* MobilityData serves as facilitator but does not vote on proposed changes.
* Votes against a proposal can stop a proposal from passing if they provide a specific reason for voting against and contain actionable feedback.
* The Advocate should cancel a vote and restart the process if significant changes are made to the proposal after stakeholders have voted.
* Should the vote fail, The Advocate can choose to continue work on the proposal with the feedback received and restart the governance process, or abandon the proposal by closing the Pull Request. Another interested member of the community can take over the proposal if they feel the addition is valuable.
* When a vote passes, the change is placed into Release Candidate (RC) status. The change remains in RC status pending implementation.
* Implementation requirements are that at least 1 producer and 1 consumer implement the changes.
* The implementors MUST be stakeholders other than The Advocate.
* Once implemented successfully, the change is merged into an official current release.
* Editorial changes as well as items that are not found in [gbfs.md](https://github.com/MobilityData/gbfs/blob/master/gbfs.md) do not need to be voted on. Extensions that include new capabilities and features MUST be voted on.
* Issues and pull requests will be considered stale after 120 days, at which point participants will be notified via comment. Should they wish to keep the discussion open, it is the responsibility of the participants to re-engage in the conversation. If there is no re-engagement, the issue or pull request will be closed 60 days after the stale date.