Changes between Version 6 and Version 7 of BOINC_Governance_Document_v2


Ignore:
Timestamp:
09/25/17 08:28:41 (7 months ago)
Author:
knreed
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BOINC_Governance_Document_v2

    v6 v7  
    1 = BOINC Project Governance =
    2 September 12, 2017
    3 
    4 = 1. Overview =
    5 BOINC is an open-source middleware system for volunteer computing, originally developed at UC Berkeley.  BOINC is a meritocratic, consensus-based project.  Anyone can join the BOINC community and contribute to the project in various ways. Those who consistently make positive contributions, as recognized by other contributors and users, can then become part of the decision-making process.  This document describes the structures and processes governing these activities.
    6 
    7 == 1.1 Mission ==
    8 The general goal of the project is to maintain and develop BOINC in a way that:
    9 
    10  * Reflects the needs and interests of its community.
    11  * Is “sustainable”, i.e. does not depend on any one person, group, or funding source, and which allows and encourages volunteer participation.
    12 
    13 Specific goals include:
    14 
    15  * Distribute an “official” version of the BOINC source code, and a revision history with branches corresponding to public releases.
    16  * Ensure that the BOINC software is modified as needed to work correctly with new versions of operating systems and virtualization software, new GPUs and other coprocessors, and new versions of server software such as Linux, PHP, Apache, and MySQL.
    17  * Maintain a “public web site” (currently https://boinc.berkeley.edu) where volunteers can learn about volunteer computing, download the client software in installer form, and get support. The web site will also have instructions for people wanting to contribute to the project, and will describe the governance structure of the project, including the current version of this document.
    18  * Ensure that the BOINC documentation is available online and is maintained.
    19  * Maintain the process of internationalizing (translating) the BOINC software.
    20  * Ensure that future development of BOINC proceeds coherently according to architectural plans agreed upon by the community.
    21 
    22 = 2. Roles and responsibilities =
    23 In the following discussion, it is important to note that people may belong to one or more categories.  For example, someone can be a committer and a PMC member.  In another case, someone might only be a PMC member.  In all cases, one person only gets one vote on issues even if they have multiple roles.
    24 
    25 == 2.1 Users ==
    26 “Users” are people who use BOINC in some way.  Examples include:
    27 
    28  * “Volunteers” run the BOINC client software, contributing processing power and storage capacity to computing projects.
    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 == #a2.4ProjectManagementCommittee
    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 === #a2.4.1PMCChair
    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 == #a2.5OfficialRecord
    115 The official list of committers and members of the PMC shall be maintained at [http://boinc.berkeley.edu/trac/wiki/ProjectGovernance 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 = #a3.Communicationchannels
    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 ​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 = #a4.Contributionprocesses
    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 ​https://boinc.berkeley.edu/dev/forum_index.php]), project forums (see project list: [https://boinc.berkeley.edu/projects.php ​https://boinc.berkeley.edu/projects.php]) or on the BOINC mailing lists ([https://boinc.berkeley.edu/trac/wiki/EmailLists ​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/ ​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 ​https://boinc.berkeley.edu/dev/forum_index.php] and post in the "How to Contribute" forum.
    142 
    143 == 4.1 Technical Contributions == #a4.1TechnicalContributions
    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 ​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 ​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 [http://boinc.berkeley.edu/trac/wiki/Development_Workflow Development_Workflow])
    152 
    153 If you are reporting a bug or requesting a feature, make sure you review the [http://boinc.berkeley.edu/trac/wiki/Development_Workflow Development_Workflow] before you submit it.
    154 
    155 = 5. Decision processes = #a5.Decisionprocesses
    156 == 5.1 Voting Processes == #a5.1VotingProcesses
    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 === #a5.1.1ConsensusVoting
    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 === #a5.1.2MajorityVoting
    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 == #a5.2Committerdecisions
    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 == #a5.3PMCdecisions
    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 === #a5.3.1Decisionswherespecialvotingproceduresaremandatory
    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 PMC 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 === #a5.3.2Othervotingdecisions
    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.
     1= This document has been moved to !https://github.com/BOINC/boinc-policy/blob/master/Governance.md =