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.

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

GBFS Governance Working Document and Release Cycles #556

Closed
josee-sabourin opened this issue Oct 24, 2023 · 1 comment · Fixed by #579
Closed

GBFS Governance Working Document and Release Cycles #556

josee-sabourin opened this issue Oct 24, 2023 · 1 comment · Fixed by #579

Comments

@josee-sabourin
Copy link
Contributor

josee-sabourin commented Oct 24, 2023

In 2020 MobilityData revised the GBFS Governance Process, since then we have noticed some elements of confusion and ambiguity. At the 2023 North American Workshop in New York City, we worked on a revision document to begin keeping track of all of things that need more attention.

MobilityData would like to open this discussion to the broader community for feedback. You can find the working document here that is open for comment. This document will remain the source of truth for changes until a PR is opened, and this issue is closed.

While the entire governance process is up for review, there are some key questions we would like some feedback on:

  1. What should the conditions be for blocking a proposal? Currently, one person is able to block a proposal, should the threshold be higher?
  2. The frequency of releases - We are seeing the official release v3.0 being blocked until a release and adoption v3.0-RC2 (and other changes in v3.0-RC), the release of v3.0-RC2 is blocked because more and more breaking proposals are being opened - which is great! That said, we would like to create a release timeline and release cycle that is predictable. We would like to propose distinct periods in which we accept proposals for a version, with a cut off date. The intention is for producers and consumers to be well aware ahead of time when a new version will be released, to help them better plan their work. Currently, MAJOR versions are released no more than once every 12 months. We propose to choose a specific date, for example the 1st of a chosen month, where at that point no more changes will be accepted, and the voting period begins for all remaining open PRs (and any required discussion periods). At that point, everyone can expect a MAJOR version to be released by the end of that month, every year. We would do the same with MINOR versions, say every 6 months, which would mean 2 releases a year, one MINOR and one MAJOR.

Please let us know what you think about these changes in this thread or in the document linked above! (Here again for your convenience).

Thank you in advance!

@richfab
Copy link
Contributor

richfab commented Jan 3, 2024

A PR has been opened: #579
You are all welcome to continue the discussion in the PR.
Thanks!

@richfab richfab closed this as completed Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants