| 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 |
| | 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 |
| 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. |
| | 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. |
| 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 == |
| | 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 == |
| 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. |
| | 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 | 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. |
