Governance
As the number of stakeholders who share a common interest in the future of OneBusAway continues to grow, it's important to establish some guidelines for the general governance of the project. We want a governance structure that is lightweight, that doesn’t involve a lot of extra administrivia, but that gets the job done (in particular, that gives transit agencies contemplating using OneBusAway confidence in the project). The governance model should accommodate two different purposes:
- furthering OneBusAway as a stable platform that transit agencies can use
- providing a platform for additional research in transit traveler information systems
We think these can be quite compatible -- there should be a stable core system, and experimental additions that build on it. When the experiments are successful and tested they can be added to the core. This will help keep the project vibrant, among other things.
At the OneBusAway project meeting, held adjacent to TRB in Washington DC in January 2013, the group decided to move to a slightly more formal governance structure with a board of directors. This is described in a OneBusAway governance document. The current board members are (in alphabetical order) Sean Barbeau (University of South Florida), Alan Borning (University of Washington), De Meyers (Sound Transit), and Kari Watkins (Georgia Tech). There are two additional slots awaiting members representing other transit agencies using OneBusAway.
The rest of this document concerns how technical decisions are made. Normally, these will continue to be made by the developers active on that part of the project, although ultimate authority rests with the board. In the longer term, there may be a number of separate technical projects (as with the Apache project), for example, for the server, the app for a particular mobile device, and so on; but for now, there is a single project, with the associated mailing list https://groups.google.com/group/onebusaway-developers.
OneBusAway has one simple goal in mind:
- Provide useful software that increases the usability of public transit.
However, doing that effectively is not so simple. The code and algorithms that make up OneBusAway are important, but the human element is important too. With that in mind, here are some specific goals to consider for project governance:
- Develop new features without negatively impacting existing users.
- Balance the needs of all OneBusAway stakeholders.
- Make project direction, both present and future, transparent.
We can hopefully achieve these goals through the guidelines described in the remainder of this document.
There are lots of decisions that need to be made about the project at any given time. Some may be uncontroversial ("should I fix this minor but annoying bug?"). Others might need more discussion ("We should convert all the server code to Python!"). OneBusAway follows a simple consensus-based decision making model for technical decisions. When faced with a decision, the project stakeholders will have an open discussion on the developer mailing list and attempt to reach a consensus decision. Consensus is typically reached when someone says "I think we've reached the following consensus on the issue..." and no one disagrees.
There may be times when consensus cannot be reached on an issue. In these situations, the board will make a decision, after consulting with all the relevant stakeholders. However, whenever possible technical decisions should be made through consensus.
Most communication about development of OneBusAway should take place on the OneBusAway Developer Mailing List:
https://groups.google.com/group/onebusaway-developers
It's a good idea to have most discussions about OneBusAway on the list, even when the discussion is between just two developers, because it makes the decision making process more transparent and provides an archive for developers in the future.
One important area for communication and project transparency is outlining where the project is heading in terms of new features and changes. Towards that end, it's a good idea for active developers to periodically outline what they are actively hoping to work on in the coming weeks. Similarly, the main project stakeholders should attempt to periodically come together and agree on a common roadmap for the project.
Having commit access to the OneBusAway codebase and documentation is an important responsibility and an acknowledgement that we believe a developer is making meaningful contributions to the project. The general path to receiving commit access generally involves two steps:
- Participating in discussion on the developer mailing list.
- Contributing a few reviewed commits to the codebase.
For specific details on performing a release, see Release Management.
We will attempt to stick to the open-source model of "release early, release often", which creates a tighter connection between the efforts of developers and the needs of users. Fixing a bug or two is more than enough reason to cut a release.
OneBusAway uses a standard "major.minor.revision" versioning scheme. Here are some general guidelines for deciding which version number to increment when performing a release.
- Major - Increment this for major changes in functionality or architecture that indicate not only a break with backwards compatibility but a major milestone in the project. Used rarely
- Minor - Increment this for changes that break backwards-compatibility for existing users (eg. change an external API or the transit data bundle format).
- Revision - Bug fixes or small changes that add functionality without breaking backwards-compatibility for existing users.
Through this scheme, we can provide more transparency to users about the impact of a new release.
It's also critical to provide detailed release notes outlining what has changed in a given release. Again, these notes will provide transparency to users about the impact of a new release.