Voting Rules

Voting Rules

Summary

This document describes how the OpenRosa Work group determines its voting membership, eligible voters, standards progression, and makes decisions on OpenRosa Stanrdards/APIs. In brief, the committee votes on proposals on the OpenRosa mailing list. Proposals are available for review for one week, and a single veto is sufficient to delay progress though ultimately a majority of members can pass a proposal. Once passed, the Standard can be in one of 4 stages based on how many technologies have implemented and deployed the standard. The summary of the minimal requirements to reach a 1.0 standard are that at least two groups need agree to want to deploy a standard, and at least two technologies need to implement that standard in live deployments.

Detailed Process

  • Standards/APIs are written up and submitted on the OpenRosa-workgroup list for discussion and voting, by any interested party, not just voting members.
  • Standards/APIs need to be available for review for at least one week before a final decision can be made.
  • Eligible Voting (see definition below) members may vote "+1" to indicate support for the proposal and a willingness to support implementation.

Eligible Voting (see defiition below):

  • Members may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days.
  • A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicate mild support, but has no effect.
  • Anyone may comment on proposals on the list, but only voting members will be counted.
  • A Standard/API will be accepted if it receives +2 (including the proposer) and no vetos (-1).
  • If a Standard/API is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all voting members (not just eligible voting members) indicating +1 is sufficient to pass it.
  • Upon completion of discussion and voting the proposer should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed).
  • The Workgroup Chair is responsible for facilitating discussion of proposals, and is responsible for keeping track of who is a voting member.
  • Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee.
  • The chair adjudicates in cases of disputes about voting.

When is a Vote Required?

  • To approve a new Standard/API.
  • Before any changes that could cause backward compatibility issues or changes the published API.
  • Anything that might be controversial.

General membership:

Anyone can join the workgroup and participate in proposals and discussions. However, they will be a non-voting member.

Current Members

Voting Membership requirements:

To be a voting member of the OpenRosa workgroup, you must be actively supporting a live deployment of an OpenRosa technology. To apply for membership, simply e-mail the the list with details of your live deployment, and have at least one voting member e-mail the list back as verification that the project is in fact live.

Standard / API progression:

An API will be marked as 1.0 when it has passed ratification ( Greater than +2 votes with no -1s).

Updated

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.