mplsmitch
commented
2 years ago I think the governance is really important to the project, but it's long and nobody reads it. For anyone who's interested, here's the document that covers the current governance development. Right now the governance text on the README is serving as both the guard rails for the project, and as instructions on how to contribute. I think we'd be better served by separating these. The governance needs some additional detail, and the instructions on how to contribute needs to be simplified and floated up where it will be seen, not buried in the governance.
Governance changes should be subject to a vote As it's currently written, only changes to gbfs.md are subject to a vote. In practice we have always held votes when making changes to governance, it's just never been put in writing. To better facilitate this, the text of the governance should be moved off the README and into its own file, for example: governance.md. Separating it from the README will make it easier to track changes to the governance over time. The README can still contain a brief overview of the change process, with a link to the full governance. Better definition of voting classes The current governance defines 2 classes of voters, producers and consumers, but there's not much detail around what makes one a producer or consumer. I'd like to see a 3rd class defined of contributor which I would define a anyone who has had a PR go through the voting process and become part of a release. As it is, we have a number of people who have made significant contributions to the spec ( myself for example) who are neither producing or consuming GBFS data and are unable to vote. There's also nothing in the current governance to cover voting on behalf of an organization. I think it's been assumed that only one vote per organization would count toward the 3 vote requirement but that's something that should be in writing. Release process When the current governance was written we hadn't developed a release process so it implies that when a vote passes the changes immediately go into RC status. In practice this isn't how it's worked. Changes have been grouped to limit the number and frequency of releases. I think the governance should give authority to the Maintainer (MobilityData) to determine when to create release candidates so long as they follow the guidelines. Now that we have a process, we should define that the master branch is a draft of the next release whereas Git tags mark canonical release versions. When votes pass, changes can be merged into the master immediately, but but it may take time before they are part of a RC. MobilityData's role should be defined MobilityData's role as the Maintainer of the project should be defined to provide assurance to users of the specification that it will remain open and free to use in the future, and that development will continue as the shared mobility industry evolves.
mobilitydataio
josee-sabourin
Hi GBFS community!
I’m Sergio, Community Facilitator for Shared Mobility at MobilityData.
We have heard the community’s interest in opening the discussion around the GBFS governance to reflect the community-driven nature of the spec. MobilityData has recently become the new home of the GBFS repository and moving forward we want to guarantee a collaborative environment to keep GBFS a community oriented spec. Considering this, we’re opening this Issue to hear your thoughts, ideas and suggestions to improve the governance process.
With this discussion we want to solidify our role as a support for the community to be the true driving force of the spec, while also discussing any relevant changes that could help reflect this in the GBFS governance.
How can you help? Let us know how you think we can build a better, more dynamic and collaborative environment together for the spec to be carried forward. A good place to start is to have a look at the existing documentation for the current governance.
We want solutions coming from the community, for the community, thus we would love to hear from you!