|10||At-Large Governing Board Members|
|11||Expanding and Contracting the Governing Board|
|13||Technical Appeals Process|
The OpenJDK Community is an association of developers who collaborate upon open-source implementations of present and future versions of the Java Platform, Standard Edition, as deﬁned by the Java Community Process, and upon closely-related projects. The goal of these Bylaws is to foster the long-term health and growth of the Community by enabling and encouraging its members to act in an open, transparent, and meritocratic manner.
The OpenJDK Community is structured as a set of Groups and a set of Projects, overseen by the OpenJDK Lead and a non-executive Governing Board.
The OpenJDK Lead is responsible for the overall technical direction and activities of the major efforts within the Community, and for the openness and transparency of the development process. The OpenJDK Lead sits on the Governing Board.
The Governing Board oversees the structure, operation, and overall health of the Community. It upholds and maintains these Bylaws, resolves procedural disputes, and ensures that sufﬁcient infrastructure is available to Community members. The Governing Board has no direct authority over technical or release decisions.
A Participant is an individual who has subscribed to one or more OpenJDK mailing lists. A Participant may post messages to a list, submit simple patches, and make other kinds of small contributions.
A Contributor is a Participant who has signed the Oracle Contributor Agreement, or who works for an organization that has signed that agreement or its equivalent and makes contributions within the scope of that work and subject to that agreement. Only a Contributor may submit anything larger than a simple patch.
An OpenJDK Member is a Contributor who has demonstrated a history of signiﬁcant contributions to the Community. OpenJDK Members may propose new Groups and are eligible to vote on new Projects, new OpenJDK Members, and new At-Large members of the Governing Board.
Many of the actions deﬁned in these Bylaws are approved or ratiﬁed by a group of individuals using one of the following voting methods:
Lazy Consensus — No voters object during a deﬁned period of time. The individual proposing the action must respond in a timely fashion to all questions and objections raised during the voting period. If a voter objects then a reason for the objection must be given and a good-faith effort must be made to resolve it.
The OpenJDK Lead may, in exceptional circumstances, choose to overrule an unresolved objection; such a decision may be appealed to the Governing Board.
As an optimization, if all eligible voters approve before the voting period ends then the action is approved at that time.
Three-Vote Consensus — Three voters approve and no voters object during a deﬁned period of time. If there are fewer than three eligible voters then all voters must approve. Otherwise this method is identical to Lazy Consensus.
Simple Majority — More of those voting approve than object, and at least three voters approve or all voters approve if there are fewer than three eligible voters.
Two-Thirds Majority — At least twice as many of those voting approve than object, and at least three voters approve or all voters approve if there are fewer than three eligible voters.
Unanimous Consent — All of those voting approve.
The Simple Majority and Two-Thirds Majority methods have corresponding Absolute variants in which the phrase “of those voting” is replaced by “of those eligible to vote.”
A Group is a collection of Participants who engage in open conversation about a common interest. That interest may be in the creation, enhancement, or maintenance of a speciﬁc body of code or it may lie in other areas, e.g., quality, documentation, or advocacy.
Groups may have web content and one or more mailing lists. Groups do not have code repositories of their own but they may Sponsor Projects, which do.
Any OpenJDK Member may propose the creation of a new Group or the dissolution of an existing Group. The Governing Board may approve the creation of a new Group by a Simple Majority vote; it may dissolve an existing Group by a Two-Thirds Majority vote.
The initial set of Groups, when these Bylaws take effect, will be the current set of Groups in the OpenJDK Community.
Groups are expected to operate in an open, transparent, and meritocratic manner. Their alignment with these principles will be monitored by the Governing Board.
A Group Member is a Contributor who has demonstrated a history of signiﬁcant contributions to a particular Group and, as a result, has been granted Membership in that Group. A Member of a Group has write access to the Group’s web content and ﬁle repositories.
An existing Member of a Group may nominate any Contributor to be a new Member of that Group. Such nominations are approved by a two-week Lazy Consensus of the existing Group Members.
A Group Lead is an OpenJDK Member who is responsible for directing and coordinating the Group’s activities. A Group’s Lead has:
The authority to Sponsor Projects;
The obligation to act as a contact point for the Group and to look after the Group’s mailing lists and web content; and
The obligation, once per quarter, to publish a written report summarizing the recent activities of the Group.
A Group’s Lead may delegate selected obligations, but not authorities, to other Group Members as desired.
When a Group is created its initial Group Lead is nominated by the proposing OpenJDK Member and approved by a Simple Majority of the Governing Board.
If a Group Lead resigns or departs then a new Group Lead may be nominated by any OpenJDK Member. The nomination must be approved by a Simple Majority of the then-current Group Members and ratiﬁed by a Simple Majority of the Governing Board.
A motion to remove a Group Lead may be raised by any OpenJDK Member. The motion must approved by a Two-Thirds Majority of the then-current Group Members and ratiﬁed by a Simple Majority of the Governing Board.
The Governing Board may, in exceptional circumstances, remove a Group Lead by a Two-Thirds Majority vote.
Any procedural decision by a Group’s Lead may be appealed to the Governing Board.
A Project is a collaborative effort to produce a speciﬁc artifact, which may be a body of code, or documentation, or some other material. Projects may range in scope from small features to entire JDK releases.
A Project may have web content, one or more code repositories, and one or more mailing lists.
Any Contributor may propose the creation of a new Project. If supported by at least one Group Lead, whose Group will Sponsor the Project, and approved by a two-week Lazy Consensus of the OpenJDK Members, then the Project will be created.
A Group’s Lead may declare that Group to be a Sponsor of an existing Project. The Members of a Group that is Sponsoring a Project may decide, by a two-week Lazy Consensus vote, to withdraw that Sponsorship.
If a Project loses all of its Sponsoring Groups then it is dissolved. A Project’s Committers may decide, by a two-week Lazy Consensus vote, to request explicitly that the Project be dissolved. The Governing Board may, in exceptional circumstances, dissolve a Project by a Two-Thirds Majority vote.
When a Project is dissolved its materials are archived. A dissolved Project may be re-created by being re-proposed.
The initial set of Projects, when these Bylaws take effect, will be the current set of Projects in the OpenJDK Community.
Projects are expected to operate in an open, transparent, and meritocratic manner. Their alignment with these principles will be monitored by the Governing Board.
New releases of Java SE Platform implementations are Projects, though particularly large ones. Such JDK Release Projects may only be proposed by the OpenJDK Lead and may only be Sponsored by the Governing Board. The OpenJDK Lead is the Project Lead for all JDK Release Projects. Every OpenJDK Member will have the opportunity to propose features for inclusion in JDK Release Projects, and decisions about which features to include will be made in a transparent manner.
A Project Author is a Contributor who has been granted the right to create changesets intended to be pushed into the Project’s code repositories but does not have the right to push such changesets directly.
A Project Committer is a Project Author who has been granted direct push access to the Project’s code repositories.
An existing Committer of a Project may nominate any Contributor to be a new Committer to that Project. Such nominations are approved by a two-week Lazy Consensus of the existing Project Committers.
A Project Lead is a Committer who is responsible for directing and coordinating the Project’s activities. A Project’s Lead has:
Full authority over all technical matters relating to the Project;
The authority to appoint and remove Project Authors who are not also Project Committers;
The obligation to act as a contact point for the Project and to look after the Project’s mailing lists, web content, and code repositories.
The obligation, once per quarter, to publish a written report summarizing the recent activities of the Project.
A Project’s Lead may delegate selected obligations, but not authorities, to other Project Committers as desired.
Project Leads are nominated by the Group Leads of a Project’s Sponsoring Groups and chosen by Unanimous Consent of those Group Leads. If agreement amongst these Group Leads cannot be reached then the OpenJDK Lead selects one of the nominees; this decision may be appealed to the Governing Board.
The Governing Board may, in exceptional circumstances, remove a Project Lead by a Two-Thirds Majority vote.
Any procedural decision by a Project’s Lead may be appealed to the Governing Board.
Any Group Member or Project Committer may be nominated to be an OpenJDK Member by an existing OpenJDK Member and approved by a two-week Three-Vote Consensus of the existing OpenJDK Members.
A motion to remove an OpenJDK Member may be raised by any OpenJDK Member; it must be approved by a Two-Thirds Majority vote of all OpenJDK Members.
The Governing Board may, in exceptional circumstances, remove an OpenJDK Member by a Two-Thirds Majority vote.
OpenJDK Membership expires automatically after one year, but will be renewed upon request. A request for renewal must be received within one year of expiration.
The OpenJDK Members’ Group consists of all OpenJDK Members. The OpenJDK Lead is its Group Lead.
The initial set of OpenJDK Members, when these Bylaws take effect, will be those individuals previously voted into Group Membership.
The Governing Board manages the structure and operation of the OpenJDK Community.
The Governing Board consists of ﬁve individuals:
The Governing Board is a Group, with the Chair as its Lead. This allows the Governing Board to Sponsor Projects.
The Governing Board is, in part, a legislative body: It is empowered to revise these Bylaws to reﬁne existing processes, to deﬁne new processes, and to dispose of processes that are no longer required. Any revision of these Bylaws must be approved by an Absolute Two-Thirds Majority of the Governing Board.
The Governing Board is also, in part, a judiciary body: It is empowered to resolve any procedural disputes which may arise within the Community. Any procedural decision made by an individual, as described in these Bylaws, may be appealed to the Governing Board. If the Governing Board decides to hear an appeal then its judgement must be approved by a Simple Majority vote.
The Governing Board is not an executive body: It has no direct authority over technical or release decisions; that authority is held by the OpenJDK Lead.
Governing Board votes may be conducted in person or via teleconference. Votes may also be conducted asynchronously, via e-mail or similar mechanisms, in which case the voting period shall be seven calendar days unless otherwise stated in the call for votes, but in any case not less than 48 hours.
The Governing Board shall meet at least once per calendar quarter, either in person or via teleconference.
The Governing Board shall conduct an annual review of all of the Community’s Groups and Projects, dissolving any such that are determined to have become inactive.
A meeting of the Governing Board is considered quorate if a majority of its members are present. In the case of an asynchronous vote a majority of members must declare themselves present before the end of the voting period, even if they do not vote.
The At-Large members of the Governing Board are chosen by a vote of the OpenJDK Members. At-Large members serve for a term of one calendar year, starting on the ﬁrst day of April each year.
During a two-week nomination period any OpenJDK Member may nominate an individual who does not currently hold an appointed Governing Board seat to ﬁll one of the At-Large seats. That individual need not already be an OpenJDK Member. An OpenJDK Member may make more than one such nomination.
During a two-week voting period, commencing shortly after the nomination period, the new At-Large members are chosen from the set of nominees by a vote of all OpenJDK Members.
If there are no more nominees than there are open seats then each nominee must be approved by a Simple Majority of voting Members. If any seat remains empty after this process then a new election will be held to ﬁll it.
If an At-Large member resigns mid-term, with at least two months remaining in the term, then a special election is held to ﬁll that seat for the remainder of the term.
The initial At-Large members of the Governing Board, when these Bylaws take effect, shall be appointed by mutual agreement of the Chair and the Vice-Chair.
The Governing Board shall never consist of fewer than ﬁve individuals, and it shall always include a Chair, a Vice-Chair, an OpenJDK Lead, and at least two At-Large seats as described above.
The Governing Board may, by an Absolute Two-Thirds Majority vote, add or remove both appointed and At-Large Governing Board seats.
An individual may be nominated to a new or newly-empty appointed seat by any Governing Board member, and is approved by a Simple Majority of the Governing Board.
Once per calendar quarter, and one week prior to that quarter’s scheduled meeting of the Governing Board, the OpenJDK Lead shall publish a written report summarizing recent activities in the Community. This report should include:
A summary of notable recent activities of Groups and Projects, including noteworthy procedural decisions;
A list of Projects that have made major state changes such as publishing a release, integrating into a JDK Release Project, or submitting or completing a JSR;
A list of Projects that should, in the OpenJDK Lead’s opinion, be considered for inclusion in a future JDK Release Project and its corresponding Umbrella JSR;
An assessment of the openness and transparency of the development process and its supporting infrastructure; and
Statistics on committer activity, bug-ﬁx rates, and Community growth.
If a Governing Board member objects in good faith to a technical or release decision made by the OpenJDK Lead then that decision may be appealed via the following process.
The objecting Board member and the OpenJDK Lead will each nominate a neutral third-party technical expert to arbitrate the decision. These two arbiters will together agree on a suitable third neutral expert to join them in creating an Arbitration Panel of three individuals. These experts need not be OpenJDK Members or even Participants.
Within two weeks of the selection of the Panel the objecting Board member will submit to the Panel and the OpenJDK Lead a written description, not to exceed 1,000 words, of the objection.
Within two weeks of the objecting Board member’s submission the OpenJDK Lead will submit to the Panel a written rebuttal, also not to exceed 1,000 words, describing the rationale behind the decision and the way in which it is reasonable.
Within two weeks of the OpenJDK Lead’s rebuttal the Panel will render a decision, made by an Absolute Simple Majority vote. The Panel may, during its deliberations, consider any other information it deems appropriate and may consult with other individuals as necessary.
Both the written submissions and the judgment of the Panel will be published as soon as they are available unless the Panel, on petition from the objecting Board member or OpenJDK Lead, determines that publication is not in the best interest of the OpenJDK Community.
Only three unsuccessful appeals by any particular Governing Board member are permitted in any twelve-month period.