| 31 | | * “Project admins” operate BOINC-based computing projects (academic science projects, hobbyist projects, commercial projects). They run the project’s servers, maintain its web site, and develop and deploy its applications. |
| 32 | | * “Add-on developers” create and operate systems that, although not part of BOINC, interact with it through its various APIs. Examples include: Account managers (such as BAM! And GridRepublic) Statistics web sites (such as BoincStats and BOINC All-Project Stats) GUIs such as BOINCTasks Branded versions of BOINC (such as HTC Power to Give, Samsung Power Sleep, and Intel Progress Thru Processors) |
| 33 | | * Leaders of BOINC teams. |
| 34 | | |
| 35 | | Anyone can be a user. The project asks its users to participate in the project and community as much as possible, for example by: |
| 36 | | |
| 37 | | * Evangelizing about the project (e.g. by web links or word of mouth) |
| 38 | | * Informing the community of strengths and weaknesses of BOINC’s products |
| 39 | | * Users may contribute in other ways, as described below. |
| 40 | | |
| 41 | | == 2.2 Contributors == |
| 42 | | |
| 43 | | |
| 44 | | “Contributors” are people who contribute in concrete ways to BOINC, other than by computing for a BOINC-based project. Forms of contribution include: |
| 45 | | |
| 46 | | * Programming |
| 47 | | * Testing and bug reporting |
| 48 | | * Writing and editing documentation |
| 49 | | * Doing translations for a particular language |
| 50 | | * Identifying and defining new software requirements |
| 51 | | * Providing “customer support” by answering questions from volunteers and contributors |
| 52 | | * Providing infrastructure (servers, hosting of email lists) |
| 53 | | * Financial support, such as paying the salary of other contributors |
| 54 | | |
| 55 | | In some forms of contribution, such as programming and documentation, contributors submit changes by developing code in branches and submitting them as pull requests for review by committers (see the next section). As contributors gain experience, their reputation within the community will increase. Contributors can nominate themselves or other people to the PMC as potential committers. |
| 56 | | |
| 57 | | == 2.3 Committers == |
| 58 | | “Committers” are contributors who have shown, via a sequence of positive contributions, their value to the project. Committers facilitate the software development process both by contributing code themselves and also by mentoring contributors to help them become more effective contributors. Only committers can merge a pull request into the master branch and they should only do so through the process defined in Section 4. Committers have voting rights in the consensus process as it pertains to proposed design changes and to the reviews of pull requests. They contribute to discussion and approval of the software development process as documented in Section 4. |
| 59 | | |
| 60 | | Each committer will be associated with one or more “areas” of the project: |
| 61 | | |
| 62 | | * Software development and maintenance |
| 63 | | * Translation system |
| 64 | | * Testing and release management |
| 65 | | * Documentation |
| 66 | | * BOINC web site, including News items |
| 67 | | * Support |
| 68 | | * Infrastructure (e.g. setting up and maintaining email lists and Github repository; maintaining BOINC web server) |
| 69 | | |
| 70 | | Depending on the committer’s area(s), they will be given specific privileges such as: |
| 71 | | |
| 72 | | * Commit access to the source code repository |
| 73 | | * Write access to the documentation Wikis |
| 74 | | * Write access to the public web site |
| 75 | | * Moderator status on project message boards |
| 76 | | |
| 77 | | Committers are expected to: |
| 78 | | |
| 79 | | * Read the communication channels relevant to their area(s) |
| 80 | | * Subscribe to pull request notifications within github (https://help.github.com/categories/notifications/) |
| 81 | | * Review bug reports and features and make sure that they are valid and contain sufficient detail to implement |
| 82 | | * Review proposed solutions to bugs and feature requests |
| 83 | | * Prioritize bug reports and features so that contributors and other developers know which issues are most important and in need of contribution |
| 84 | | * Review pull requests and merge code when appropriate |
| 85 | | * Identify contributors who would be helpful as committers; nominate these contributors to the PMC via the PMC email distribution list for consideration |
| 86 | | |
| 87 | | == 2.4 Project Management Committee == |
| 88 | | |
| 89 | | |
| 90 | | The Project Management Committee (PMC) is a group of community members who have consistently and significantly contributed to the project, for example by |
| 91 | | |
| 92 | | * Directly contributing in any of the ways listed in Section 2.2 |
| 93 | | * Operating a related system, such as an account manager, that is used by a significant number of volunteers |
| 94 | | * Operating a BOINC project with a significant number of volunteers |
| 95 | | * Contributing significant resources to the project, for example by paying the salary of a contributor |
| 96 | | |
| 97 | | The functions of the PMC are: |
| 98 | | |
| 99 | | * Decide on the strategic directions of the project |
| 100 | | * Decide issues of intellectual property (copyright, licensing) and other legal issues |
| 101 | | * Review and vote on nominated committers |
| 102 | | * Decide on PMC membership |
| 103 | | * Decide on the set of “approved” projects and account managers |
| 104 | | * Modify the governance policies of the project as needed |
| 105 | | |
| 106 | | PMC members are expected to actively participate in these processes, by |
| 107 | | |
| 108 | | * Reading the PMC email lists (see below) |
| 109 | | * Participating in votes (see below) |
| 110 | | |
| 111 | | === 2.4.1 PMC Chair === |
| 112 | | |
| 113 | | |
| 114 | | The “PMC Chair” is a member of the PMC, elected by the PMC to take this role. The chair has the following responsibilities: |
| 115 | | |
| 116 | | * Ensure that votes are taken on issues that require votes |
| 117 | | * Ensure that the activities of the BOINC community are in agreement with this document and established procedures |
| 118 | | * Schedule monthly meetings of the PMC |
| 119 | | |
| 120 | | The Chair remains in that role until they retire or the PMC votes to remove them. He or she has no additional authority beyond that of other PMC members. |
| 121 | | |
| 122 | | == 2.5 Official Record == |
| 123 | | The official list of committers and members of the PMC shall be maintained at ProjectGovernance. This page shall also clearly list the email address of the PMC public email list with instructions on how someone can subscribe to the list. |
| 124 | | |
| 125 | | 3. Communication channels |
| 126 | | |
| 127 | | The project will provide communication channels for various purposes: PMC public email list, used for: Requests to be a submitter Requests to be a PMC member Project-level discussion PMC private email list, used for sensitive issues, such as discussion of potential new committers, or legal matters that can’t be discussed in public. It is not used for project management or planning Issue tracking system, for bugs and development requests (https://github.com/BOINC/boinc/issues) Volunteer message boards, for support requests and responses Project admin email list, for announcements and discussion related to the BOINC server software and other issues related to BOINC-based computing projects Email lists for specific contribution areas, such as software development, testing, and translations Except for the PMC private email list, all of these channels will be publicly readable and writeable. |
| 128 | | |
| 129 | | 4. Contribution processes |
| 130 | | |
| 131 | | Anyone can contribute to BOINC. There are multiple ways to contribute to BOINC: Help other users by answering questions on the BOINC forums (https://boinc.berkeley.edu/dev/forum_index.php), project forums (see project list: https://boinc.berkeley.edu/projects.php) or on the BOINC mailing lists (https://boinc.berkeley.edu/trac/wiki/EmailLists) Add or maintain documentation to the BOINC wikis Add or maintaining translations of BOINC Participate in the Alpha testing of software releases (https://boinc.berkeley.edu/alpha/) Make a technical contribution If you need help getting started, then please visit https://boinc.berkeley.edu/dev/forum_index.php and post in the "How to Contribute" forum. 4.1 Technical Contributions The process of making technical or code contributions is the same for everyone, regardless of whether they are a contributor, committer or PMC member. You can contribute by doing the following: Read the BOINC developer information (https://boinc.berkeley.edu/trac/wiki/SoftwareDevelopment) to learn about the BOINC system Find something that needs to be implemented in BOINC: Review the Project (https://github.com/BOINC/boinc/projects) associated with the area of BOINC in which you want to contribute Issues that have been reviewed and are ready for implementation are listed under Longterm or TODO Issues with a higher priority for implementation are listed under TODO Follow the software development process that BOINC uses (See Software Development Process) If you are reporting a bug or requesting a feature, make sure you review the Software Development Process before you submit it. |
| 132 | | |
| 133 | | 5. Decision processes |
| 134 | | |
| 135 | | 5.1 Voting Processes Because one of the fundamental aspects of accomplishing things within the BOINC framework is doing so by consensus, it is necessary to determine whether consensus has been reached. This is done by voting. There are a few types of items that require a vote: Whether or not to fix a bug or implement a feature request (documented and voted on as an issue on github) The design of a proposed feature or bug fix (documented and voted on within the relevant issue on github) A change in code or configuration to the system (documented and voted on as a pull request on github) General availability of stable releases (documented and voted on in the boinc_alpha mailing list) Procedural and other issues Other commiter votes not otherwise identified above will be voted on in the boinc_dev mailing list Other PMC votes not otherwise identified above will be voted on in the boinc_adm or private boinc_pmc mailing lists as deemed appropriate by the PMC Chair. Votes on design reviews, pull requests, and general availability of a stable release shall use the consensus voting process. Procedural and other issues shall always follow the majority voting process. 5.1.1 Consensus Voting Consensus voting consists of a 7 day review period. During this time anyone can review and discuss the item. At the end of the 7 day period, if there is at least one "Yes" vote for an item (apart from the vote of the person who created the item) and zero "No" votes, then the vote shall be deemed as having passed. A vote of "No" shall not be valid unless it is accompanied by a detailed explanation of the objection to the item. It is preferable to suggest an alternative implementation if possible. If discussion cannot remove the concerns that resulted in the "No" vote, then the vote shall be deemed as having failed. If the vote fails, but the original proposer of the item still believes that the item is worth pursuing, they can appeal to the PMC. The PMC shall consider the appeal at their next regularly scheduled meeting and will use Majority Voting to determine the outcome. 5.1.2 Majority Voting Majority voting requires that at least 2/3rds of eligible voters cast a vote and, of those who cast a vote, a majority must approve the item. 5.2 Committer decisions Committers can vote on issues surrounding the technical infrastructure of the project and the code base itself. This includes voting to determine if a reported bug, feature request, proposed design, or pull request should be accepted. Committers are encouraged to review and participate in the discussion of any of these items, but they are also expected to know when it is advisable to get help from other committers who are stronger in the technology involved or have more experience in the area of application under consideration. Committers are expected to understand the Development Workflow and Client Release Process and their associated guidelines before voting to approve. |
| 136 | | |
| 137 | | Committers are expected to subscribe to notifications from github in order to be aware of proposals under consideration. Committers should make a reasonable attempt to respond quickly if they are personally asked to review an item. Since most decisions that committers are involved in will use consensus voting, it is important for them to try to remain aware of proposed items. 5.3 PMC decisions Three specific types of decisions by the PMC must be made by majority voting (see below). For all other types of decisions, the PMC will start decision making using the consensus voting with PMC members voting. If consensus voting fails to reach agreement, the chair or the person who called the vote can request that a majority vote occurs to determine the outcome. 5.3.1 Decisions where voting is mandatory Decisions of the following types must be made by a special vote of the PMC: Intellectual property issues, e.g. those involving copyright and licensing of BOINC code Other legal and financial decisions PMC membership Selection of the PMC chair Changes to the project governance structure (i.e. changes to this document) Votes can be called by any PMC member. The voting process is: A vote is announced on the PMC public list, phrasing the issue as a yes/no decision Discussion of the issue (by the entire community) takes place on the PMC public list. Sensitive discussion among PC members uses the PMC private list PMC members cast their votes publicly (by email on the PMC public list, or perhaps on a suitable web-based voting system) Votes on these issues are decided by agreement of at least 75% of responding voters. The vote will be final when there is agreement of at least 75% of PMC members, or when 14 days have passed since the vote was called. If there is not agreement of at least 75% of responding voters, no action is taken on the issue 5.2.5 Other voting decisions Other decisions that require a PMC vote (such as committer requests not handled by consensus) will use a process similar to the above, except that only a majority (greater than 50% of responding voters) is required to make a decision, and votes are final 7 days after being called. |
| | 29 | * “Project admins” operate BOINC-based computing projects (academic science projects, hobbyist projects, commercial projects). They run the project’s servers, maintain its web site, and develop and deploy its applications. |
| | 30 | * “Add-on developers” create and operate systems that, although not part of BOINC, interact with it through its various APIs. Examples include: Account managers (such as BAM! And GridRepublic) Statistics web sites (such as BoincStats and BOINC All-Project Stats) GUIs such as BOINCTasks Branded versions of BOINC (such as HTC Power to Give, Samsung Power Sleep, and Intel Progress Thru Processors) |
| | 31 | * Leaders of BOINC teams. |
| | 32 | |
| | 33 | Anyone can be a user. The project asks its users to participate in the project and community as much as possible, for example by: |
| | 34 | |
| | 35 | * Evangelizing about the project (e.g. by web links or word of mouth) |
| | 36 | * Informing the community of strengths and weaknesses of BOINC’s products |
| | 37 | * Users may contribute in other ways, as described below. |
| | 38 | |
| | 39 | == 2.2 Contributors == |
| | 40 | “Contributors” are people who contribute in concrete ways to BOINC, other than by computing for a BOINC-based project. Forms of contribution include: |
| | 41 | |
| | 42 | * Programming |
| | 43 | * Testing and bug reporting |
| | 44 | * Writing and editing documentation |
| | 45 | * Doing translations for a particular language |
| | 46 | * Identifying and defining new software requirements |
| | 47 | * Providing “customer support” by answering questions from volunteers and contributors |
| | 48 | * Providing infrastructure (servers, hosting of email lists) |
| | 49 | * Financial support, such as paying the salary of other contributors |
| | 50 | |
| | 51 | In some forms of contribution, such as programming and documentation, contributors submit changes by developing code in branches and submitting them as pull requests for review by committers (see the next section). As contributors gain experience, their reputation within the community will increase. Contributors can nominate themselves or other people to the PMC as potential committers. |
| | 52 | |
| | 53 | == 2.3 Committers == |
| | 54 | “Committers” are contributors who have shown, via a sequence of positive contributions, their value to the project. Committers facilitate the software development process both by contributing code themselves and also by mentoring contributors to help them become more effective contributors. Only committers can merge a pull request into the master branch and they should only do so through the process defined in Section 4. Committers have voting rights in the consensus process as it pertains to proposed design changes and to the reviews of pull requests. They contribute to discussion and approval of the software development process as documented in Section 4. |
| | 55 | |
| | 56 | Each committer will be associated with one or more “areas” of the project: |
| | 57 | |
| | 58 | * Software development and maintenance |
| | 59 | * Translation system |
| | 60 | * Testing and release management |
| | 61 | * Documentation |
| | 62 | * BOINC web site, including News items |
| | 63 | * Support |
| | 64 | * Infrastructure (e.g. setting up and maintaining email lists and Github repository; maintaining BOINC web server) |
| | 65 | |
| | 66 | Depending on the committer’s area(s), they will be given specific privileges such as: |
| | 67 | |
| | 68 | * Commit access to the source code repository |
| | 69 | * Write access to the documentation Wikis |
| | 70 | * Write access to the public web site |
| | 71 | * Moderator status on project message boards |
| | 72 | |
| | 73 | Committers are expected to: |
| | 74 | |
| | 75 | * Read the communication channels relevant to their area(s) |
| | 76 | * Subscribe to pull request notifications within github (https://help.github.com/categories/notifications/) |
| | 77 | * Review bug reports and features and make sure that they are valid and contain sufficient detail to implement |
| | 78 | * Review proposed solutions to bugs and feature requests |
| | 79 | * Prioritize bug reports and features so that contributors and other developers know which issues are most important and in need of contribution |
| | 80 | * Review pull requests and merge code when appropriate |
| | 81 | * Identify contributors who would be helpful as committers; nominate these contributors to the PMC via the PMC email distribution list for consideration |
| | 82 | |
| | 83 | == 2.4 Project Management Committee == |
| | 84 | The Project Management Committee (PMC) is a group of community members who have consistently and significantly contributed to the project, for example by |
| | 85 | |
| | 86 | * Directly contributing in any of the ways listed in Section 2.2 |
| | 87 | * Operating a related system, such as an account manager, that is used by a significant number of volunteers |
| | 88 | * Operating a BOINC project with a significant number of volunteers |
| | 89 | * Contributing significant resources to the project, for example by paying the salary of a contributor |
| | 90 | |
| | 91 | The functions of the PMC are: |
| | 92 | |
| | 93 | * Decide on the strategic directions of the project |
| | 94 | * Decide issues of intellectual property (copyright, licensing) and other legal issues |
| | 95 | * Review and vote on nominated committers |
| | 96 | * Decide on PMC membership |
| | 97 | * Decide on the set of “approved” projects and account managers |
| | 98 | * Modify the governance policies of the project as needed |
| | 99 | |
| | 100 | PMC members are expected to actively participate in these processes, by |
| | 101 | |
| | 102 | * Reading the PMC email lists (see below) |
| | 103 | * Participating in votes (see below) |
| | 104 | |
| | 105 | === 2.4.1 PMC Chair === |
| | 106 | The “PMC Chair” is a member of the PMC, elected by the PMC to take this role. The chair has the following responsibilities: |
| | 107 | |
| | 108 | * Ensure that votes are taken on issues that require votes |
| | 109 | * Ensure that the activities of the BOINC community are in agreement with this document and established procedures |
| | 110 | * Schedule monthly meetings of the PMC |
| | 111 | |
| | 112 | The Chair remains in that role until they retire or the PMC votes to remove them. He or she has no additional authority beyond that of other PMC members. |
| | 113 | |
| | 114 | == 2.5 Official Record == |
| | 115 | The official list of committers and members of the PMC shall be maintained at ProjectGovernance. This page shall also clearly list the email address of the PMC public email list with instructions on how someone can subscribe to the list. |
| | 116 | |
| | 117 | = 3. Communication channels = |
| | 118 | The project will provide communication channels for various purposes: |
| | 119 | |
| | 120 | * PMC public email list, used for: |
| | 121 | * Requests to be a submitter |
| | 122 | * Requests to be a PMC member |
| | 123 | * Project-level discussion |
| | 124 | * PMC private email list, used for sensitive issues, such as discussion of potential new committers, or legal matters that can’t be discussed in public. It is not used for project management or planning |
| | 125 | * Issue tracking system, for bugs and development requests (https://github.com/BOINC/boinc/issues) |
| | 126 | * Volunteer message boards, for support requests and responses |
| | 127 | * Project admin email list, for announcements and discussion related to the BOINC server software and other issues related to BOINC-based computing projects |
| | 128 | * Email lists for specific contribution areas, such as software development, testing, and translations |
| | 129 | |
| | 130 | Except for the PMC private email list, all of these channels will be publicly readable and writable. |
| | 131 | |
| | 132 | = 4. Contribution processes = |
| | 133 | Anyone can contribute to BOINC. There are multiple ways to contribute to BOINC: |
| | 134 | |
| | 135 | * Help other users by answering questions on the BOINC forums (https://boinc.berkeley.edu/dev/forum_index.php), project forums (see project list: https://boinc.berkeley.edu/projects.php) or on the BOINC mailing lists (https://boinc.berkeley.edu/trac/wiki/EmailLists) |
| | 136 | * Add or maintain documentation to the BOINC wikis |
| | 137 | * Add or maintaining translations of BOINC |
| | 138 | * Participate in the Alpha testing of software releases (https://boinc.berkeley.edu/alpha/) |
| | 139 | * Make a technical contribution |
| | 140 | |
| | 141 | If you need help getting started, then please visit https://boinc.berkeley.edu/dev/forum_index.php and post in the "How to Contribute" forum. |
| | 142 | |
| | 143 | == 4.1 Technical Contributions == |
| | 144 | The process of making technical or code contributions is the same for everyone, regardless of whether they are a contributor, committer or PMC member. You can contribute by doing the following: |
| | 145 | |
| | 146 | * Read the BOINC developer information (https://boinc.berkeley.edu/trac/wiki/SoftwareDevelopment) to learn about the BOINC system |
| | 147 | * Find something that needs to be implemented in BOINC: |
| | 148 | * Review the Project (https://github.com/BOINC/boinc/projects) associated with the area of BOINC in which you want to contribute |
| | 149 | * Issues that have been reviewed and are ready for implementation are listed under Longterm or TODO |
| | 150 | * Issues with a higher priority for implementation are listed under TODO |
| | 151 | * Follow the software development process that BOINC uses (See [wiki:Development_Workflow]) |
| | 152 | |
| | 153 | If you are reporting a bug or requesting a feature, make sure you review the [wiki:Development_Workflow] before you submit it. |
| | 154 | |
| | 155 | = 5. Decision processes = |
| | 156 | == 5.1 Voting Processes == |
| | 157 | Because one of the fundamental aspects of accomplishing things within the BOINC framework is doing so by consensus, it is necessary to determine whether consensus has been reached. This is done by voting. |
| | 158 | |
| | 159 | There are a few types of items that require a vote: |
| | 160 | |
| | 161 | * Whether or not to fix a bug or implement a feature request (documented and voted on as an issue on github) |
| | 162 | * The design of a proposed feature or bug fix (documented and voted on within the relevant issue on github) |
| | 163 | * A change in code or configuration to the system (documented and voted on as a pull request on github) |
| | 164 | * General availability of stable releases (documented and voted on in the boinc_alpha mailing list) |
| | 165 | * Procedural and other issues |
| | 166 | * Other committer votes not otherwise identified above will be voted on in the boinc_dev mailing list |
| | 167 | * Other PMC votes not otherwise identified above will be voted on in the boinc_adm or private boinc_pmc mailing lists as deemed appropriate by the PMC Chair. |
| | 168 | |
| | 169 | Votes on design reviews, pull requests, and general availability of a stable release shall use the consensus voting process. |
| | 170 | |
| | 171 | Procedural and other issues shall always follow the majority voting process. |
| | 172 | |
| | 173 | === 5.1.1 Consensus Voting === |
| | 174 | Consensus voting consists of a 7 day review period. During this time anyone can review and discuss the item. At the end of the 7 day period, if there is at least one "Yes" vote for an item (apart from the vote of the person who created the item) and zero "No" votes, then the vote shall be deemed as having passed. |
| | 175 | |
| | 176 | A vote of "No" shall not be valid unless it is accompanied by a detailed explanation of the objection to the item. It is preferable to suggest an alternative implementation if possible. |
| | 177 | |
| | 178 | If discussion cannot remove the concerns that resulted in the "No" vote, then the vote shall be deemed as having failed. |
| | 179 | |
| | 180 | If the vote fails, but the original proposer of the item still believes that the item is worth pursuing, they can appeal to the PMC. The PMC shall consider the appeal at their next regularly scheduled meeting and will use Majority Voting to determine the outcome. |
| | 181 | |
| | 182 | === 5.1.2 Majority Voting === |
| | 183 | Majority voting requires that at least 2/3rds of eligible voters cast a vote and, of those who cast a vote, a majority must approve the item. |
| | 184 | |
| | 185 | == 5.2 Committer decisions == |
| | 186 | Committers can vote on issues surrounding the technical infrastructure of the project and the code base itself. This includes voting to determine if a reported bug, feature request, proposed design, or pull request should be accepted. Committers are encouraged to review and participate in the discussion of any of these items, but they are also expected to know when it is advisable to get help from other committers who are stronger in the technology involved or have more experience in the area of application under consideration. Committers are expected to understand the Development Workflow and Client Release Process and their associated guidelines before voting to approve. |
| | 187 | |
| | 188 | Committers are expected to subscribe to notifications from github in order to be aware of proposals under consideration. Committers should make a reasonable attempt to respond quickly if they are personally asked to review an item. Since most decisions that committers are involved in will use consensus voting, it is important for them to try to remain aware of proposed items. |
| | 189 | |
| | 190 | == 5.3 PMC decisions == |
| | 191 | Certain specific types of decisions by the PMC must be made by a special voting procedure (see below). |
| | 192 | |
| | 193 | === 5.3.1 Decisions where special voting procedures are mandatory === |
| | 194 | Decisions of the following types must be made by a special vote of the PMC: |
| | 195 | |
| | 196 | * Intellectual property issues, e.g. those involving copyright and licensing of BOINC code |
| | 197 | * Other legal and financial decisions |
| | 198 | * PMC membership |
| | 199 | * Selection of the PMC chair |
| | 200 | * Changes to the project governance structure (i.e. changes to this document) |
| | 201 | |
| | 202 | Votes can be called by any PMC member. The special voting process is: |
| | 203 | |
| | 204 | * A vote is announced on the PMC public list, phrasing the issue as a yes/no decision |
| | 205 | * Discussion of the issue (by the entire community) takes place on the PMC public list. Sensitive discussion among PC members uses the PMC private list |
| | 206 | * PMC members cast their votes publicly (by email on the PMC public list) |
| | 207 | * Votes on these issues are decided by agreement of at least 75% of responding voters. The vote will be final when there is agreement of at least 75% of PMC members, or when 14 days have passed since the vote was called. |
| | 208 | * If there is not agreement of at least 75% of responding voters, no action is taken on the issue |
| | 209 | |
| | 210 | === 5.3.2 Other voting decisions === |
| | 211 | |
| | 212 | |
| | 213 | For all other types of decisions that require a PMC vote, the PMC will start decision making using the consensus voting with PMC members voting. If consensus voting fails to reach agreement, the chair or the person who called the vote can request that a majority vote occurs to determine the outcome. |
