Jasig Voting Policies

Jasig Voting and decision practices are based on Apache Foundation policies, with some exceptions--mostly owing to the differences in the project governance model.

Voting

Voting is done on the Jasig mailing lists. Anyone on the list is welcome to cast a vote. However only active committers, and, in some cases, members of the project steering committee, are considered binding. Not all action items require voting. (See action item types below.)

Each vote can be made in one of three flavors:

+1 Yes, agree, or the action should be performed.

±0 Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental effects if too many people abstain.

-1 No.

Many decisions are made through lazy approval, an announcement that "silence means assent".

An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetoes. On issues where consensus is required.

A -1 vote counts as a veto.
All vetoes must include an explanation of why the veto is appropriate. A veto with no explanation is void.
No veto can be overruled. Discussion and communication with the voter is the appropriate way to resolve a veto.
Voters intending to veto an action item should make their opinions known to the group immediately, so that the problem can be remedied as early as possible.

An action item requiring majority approval must receive at least 3 binding +1 votes and more +1votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes).

All other action items are considered to have lazy approval until someone votes -1, after which point they are decided by either consensus or a majority vote, depending upon the type of action item.

Action Item Types

Long Term Plans

Strategic planning is the responsibility of the steering committee. It is expected that plans are developed in close communication with the community and are publicly announced and made available for comment as early as possible. Examples of strategic planning in the uPortal project are the decision to drop support for the Aggregated Layout Manager in 3.0 and the decision to drop IChannel support in 3.3. Each of these decisions was made with plenty of opportunity for feedback and suggestions from the community at large. There is no voting on long term plans but rather wide discussion to reach broad support in the community.

Short Term Plans and Product changes

Short term plans are announcements that the project lead or a developer is planning to work on a particular set of documentation or code files, with the implication that other developers should avoid them or try to coordinate their changes. Announcing short term plans is also a way to get feedback on alternate methods for accomplishing the goal. Short term plans and product changes should be accompanied by JIRA issues. Short term plans may be subject to lazy approval or voted on using consensus approval. For short term plans, only committer votes are binding.

Release Plans

A release plan includes determining which features will be included and what dates are anticipated. The release plan is developed by the project lead in conjunction with the steering committee. The release plan should be shared with the community as early as possible. A release plan is subject to lazy approval or consensus vote. Committer and project steering committee votes are binding.

Priority Setting

The steering committee cannot unilaterally set priorities for the project since in most cases they don't control resources. However the binding voters may set priorities by majority when a vote is requested by a resource. Committer and project steering committee votes are binding.

New Committers

New committers are proposed on the appropriate project developer list. Approval is by consensus. Only committer votes are binding. Authors and developers of other types of contributions, such as marketing materials, documentation, testing are not subject to voting but should be overseen by the project steering committee.

Steering Committee Membership

Project Steering committees are composed of developer representatives and other project stakeholders. Elections for steering committee membership are conducted during the annual Jasig election cycle. Like board members, project stakeholders are elected by secret ballot by the Jasig membership at large. Developer representatives are nominated on the appropriate developer list and approved by majority vote. While all community members are encouraged to cast advisory votes, only committer votes are binding .

Browser not supported