-
Notifications
You must be signed in to change notification settings - Fork 99
New Governance
- Mission of ActivitySim
- Roles & Responsibilities
- Project Management Committee
- Decision Making
- Communication Channels
The creation and maintenance of an advanced, open-source, activity-based travel behavior modeling software based on best software development practices for distribution at no charge to the public.
The primary purpose of this endeavor is to unify the best practices in activity-based travel models for transportation policy analysis and reducing the cost of ownership for public agencies.
ActivitySim is a meritocracy with the following roles:
A user is someone that uses ActivitySim. They contribute by providing feedback to developers in the form of bug reports and feature suggestions. Users participate by helping other users.
A developer is any user who contributes to a project in the form of code or documentation. They take extra steps to participate in a project, are active in the online development discussion, provide patches, documentation, suggestions, and criticism.
A committer is a developer that was given write access to the code repository.
A funder is an organization who contributes at least $35,000 in the past 12 months to the ActivitySim Development Fund managed by the AMPO Research Foundation. The Fund is used to pay for software development, including project administration and documentation as needed, and can be performed by Developers and/or Committers.
PMC membership is based on merit. Until December 31, 2021, merit is determined by contributions of funds to the ActivitySim Development Fund, and thus the initial PMC members are the funders. Ultimately, the PMC will evolve to include developers or committers that are elected due to merit based on the contributions of code to support the evolution of the project and demonstration of commitment to the project. PMC members have write access to the code repository, the right to vote for the community-related decisions and the right to propose an active user for committership. The PMC as a whole is the entity that controls the project, nobody else. In particular, the PMC must vote on any formal release of their project's software products. The PMC makes the decisions, not the individual committers.
The PMC chair is a PMC member whose sole additional responsibility is to manage PMC voting. This includes announcing votes, setting timeframes for votes, identifying the type of approval required (if not readily apparent), ensuring that a quorum is established as required by the type of approval, and adjudicating disputes about the validity of vetoes.
The PMC contractor is the lead organization contracting with the AMPO Research Foundation to provide ActivitySim software development, project administration and documentation services.
Initially, the group of PMC members are the funders. Ultimately, the PMC will evolve to include developers or committers. PMC members can be as active as they choose, with no pressure from the project. People can be quiet and speak up occasionally when they see a topic that motivates them enough to contribute to the discussion or to cast a vote. Individual PMC members do not need to be involved in every aspect of the project. As a group, the PMC will maintain sufficient oversight.
The responsibilities of the PMC include:
- Be familiar with these project guidelines
- Support oversight of the commit log messages and ensure that the codebase does not have copyright and license issues, and that the project is heading in the desired direction.
- Support oversight of the development community resources to ensure that the open development ideals are upheld. Resolve license disputes regarding products of the project, including other supporting software that is re-distributed.
- Develop and managing a roadmap for new features and product enhancements that will be considered for each product release, determining release plans and approving official releases..
- Guide the direction of the project.
- Strive for and help to facilitate a harmonious productive community.
- Nominate new PMC members and committers.
- Support maintenance of the project's shared resources, including the codebase repository, issue management, websites.
- Speak on behalf of the project.
- Maintain these and other guidelines of the project.
The PMC can discuss certain issues in private. However, every effort is made to conduct all discussions in public.
Membership of the PMC is by invitation only and must receive consensus approval of the PMC members. The PMC elects a chair by simple majority. This chair is empowered to make determinations in breakdown situations and those requiring unanimous consensus, if this consensus cannot be reached within timeframe.
A PMC member is considered "emeritus" by their own declaration, e.g. perhaps personal reasons. Please send a note to the PMC and we will follow up to request acknowledgement of the Board. An emeritus member may request reinstatement to the PMC. Such reinstatement is subject to consensus approval of the PMC members. Membership of the PMC can be revoked by unanimous consensus of PMC members (other than the member in question).
At the direction of the PMC, the PMC contractor may act on behalf of the PMC.
- Joe Castiglione, SFCTA (Chair)
- Stefan Coe, PSRC
- Wu Sun, SANDAG
- Guy Rousseau, ARC
- Lisa Zorn, MTC
- Jilan Chen, SEMCOG
- Alex Bettinardi, Oregon DOT
- Dennis Farmer, Met Council
When new people are committed and consistent, PMC members will discuss each case to ensure that the PMC is in agreement. The private vote among the PMC is to enable a frank discussion and so that we do not conduct public discussions about people. Ultimately, new committers should ideally also become new PMC members as well. Otherwise they do not have a binding vote and so we would create classes of committers. When invited, a new committer is permitted to choose not to be on the PMC.
Different types of decisions require different forms of approval. This section defines how voting is performed, the types of approval, and which types of decision require which type of approval. Most day-to-day operations do not require explicit voting - just get on and do the work. See the "Lazy approval" type described below.
Certain actions and decisions regarding the project are made by voting by PMC members. Where necessary (e.g. discussion and vote about specific people to be new committers) PMC voting may take place in confidence. Presentation and discussion of the proposal should have happened prior to the vote. Voting is carried out via GitHub? Votes are expressed using one of the following symbols
| Vote Type | Description |
|---|---|
| +1 | "Yes," "Agree," or "the action should be performed." |
| -1 | “No,” “Disagree,” or “the action should not be performed.” On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action. |
| Abstain | People can abstain from voting. They can either remain silent or express their reason. |
Different actions require different types of approval:
| Approval Type | Approval Requirement |
|---|---|
| Consensus | Majority of PMC “+1” votes and no PMC vetoes |
| Lazy majority | Majority of PMC “+1” votes |
| Lazy approval | Implicit allowance unless a “-1” PMC vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained. |
| ⅔ majority | ⅔ of PMC “+1” votes |
| Unanimous consensus | All PMC “+1” votes |
A valid veto cannot be over-ruled, it can only be withdrawn by its issuer. Any veto must be accompanied by reasoning and be prepared to defend it. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid. In case of disputes about whether a veto is valid, then opinion of the PMC chair is final. If you disagree with a valid veto, then you must engage the person casting the veto to further discuss the issues. The vetoer is obliged to vote early and to then work with the community to resolve the matter. If a veto is not withdrawn, the action that has been vetoed must be reversed in a timely manner.
This section describes the various actions which are undertaken within the project, the corresponding approval required for that action, and those who have binding votes over the action.
| Action | Description | Application | Binding votes |
|---|---|---|---|
| Code change | A change made to a codebase of the project by a committer. This includes source code, documentation, website content, etc. | Lazy approval | PMC |
| Release plan | Defines the timetable and actions for a release. A release plan cannot be vetoed (hence lazy majority). | Lazy majority | PMC |
| Product release | When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. A release cannot be vetoed (hence lazy majority). | Lazy majority | PMC |
| Adoption of new codebase | When the codebase for an existing, released product is to be replaced with an alternative codebase. | ⅔ majority | PMC |
| Creation of new sub-project | When a new sub-project within an existing code base is to be created | ⅔ majority | PMC |
| New committer | When a new committer is proposed for the project. | Consensus approval | PMC |
| New PMC member | When a new member is proposed for the PMC. | Consensus approval | PMC |
| Select PMC chair | When a new PMC chair is required | Consensus approval | PMC |
| Reinstate emeritus member | An emeritus PMC member can be reinstated. | Consensus approval | PMC (excl member in question) |
| Committer removal | When removal of commit privileges is sought. | Unanimous consent | PMC (excl member in question, if applicable) |
| PMC member removal | When removal of a PMC member is sought. | Unanimous consent | PMC (excl member in question) |
| Determine whether another vote should be in confidence | When decisions necessitate privacy | Consensus approval | PMC (excl member in question, if applicable) |
Votes are normally open for a period of one to two weeks to allow all active voters time to consider the vote. If the vote has not achieved a quorum (the PMC chair decides if sufficient people have voted), then it can be extended for up to one additional month. If still no quorum, then the vote fails, and would need to be raised again later. Votes relating to code changes are not subject to a strict timetable, but should be made as timely as possible.
Discussion about the topic would have already happened in a [Proposal] thread to express the issues and opinions. The [Vote] thread is to ratify the proposal if that is felt to be necessary. The instigator shares the Vote proposal with the PMC. Describe the issue with no ambiguity and in a positive sense. Define the date and time for the end of the vote period. Votes are expressed using the voting symbols defined above. Voters can change their vote during the timeframe. At the end of the vote period, the instigator tallies the number of final votes and reports the results.
For breakdown situations and those requiring unanimous consensus, if this consensus cannot be reached within the extended timeframe, then the PMC Chair will make the ultimate decision.
The primary mechanism for communication is the project’s GitHub site. Anyone can participate, no matter what their time zone. A reliable searchable archive of past discussion is built. Oversight is enabled. Many eyes ensures that the project evolves in a consistent direction. Other communication channels may also be used, if only for a specific purpose and not permanently available. This policy ensures that solutions are available in the mailing list archives and enables people to respond at whatever time that they choose.
Private discussions are discouraged.