Groups
Projects
TheOpenJDK Community isan association of developers who collaborate uponopen-sourceimplementations of present and future versions of the JavaPlatform, Standard Edition, as defined by theJava Community Process, and uponclosely-related projects. The goal of these Bylaws is to foster thelong-term health and growth of the Community by enabling andencouraging its members to act in an open, transparent, andmeritocratic manner.
These Bylaws wereratified on 28 June 2011.
The OpenJDK Community is structured as a set ofGroups, which are collections of individuals whoengage in open conversation about a common interest, and a set ofProjects, which arecollaborative efforts to produce specific artifacts. There areCommunity-widegeneralroles as well asrolesspecific to Groups and toProjects.
TheGoverning Boardmanages the structure and operation of the Community, monitoringits health relative to the principles set forth in the Preamble. Itupholds and maintains these Bylaws, resolves procedural disputes,and ensures that sufficient infrastructure is available. TheGoverning Board has no direct authority over technical or releasedecisions.
AParticipant is an individual who has subscribedto one or more OpenJDK mailing lists. A Participant may postmessages to a list, submit simple patches, and make other kinds ofsmall contributions.
AContributor is a Participant who has signed theOracle ContributorAgreement (OCA), or who works for an organization that hassigned that agreement or its equivalent and makes contributionswithin the scope of that work and subject to that agreement. AContributor may submit changes larger than a simple patch, maypropose newProjects, and maytake on various roles withinGroups and Projects.
If a Contributor’s employment situation changes such thatcontributions would no longer be covered by the OCA or itsequivalent then the Contributor must relinquish that role bynotifying theOpenJDKLead.
AnOpenJDK Member is a Contributor whohas demonstrated a history of significant contributions to theCommunity as recognized by a vote of the existing OpenJDK Members.An OpenJDK Member may propose new Groups, may lead a Group, and iseligible to vote on newProjects, new OpenJDK Members, and the selection ofnewAt-Large Members oftheGoverning Board.
TheOpenJDKLead is an OpenJDK Member, appointed by Oracle, who directs themajor efforts of the Community, which are new implementations ofthe Java SE Platform known asJDK Release Projects. The OpenJDK Leadis responsible for the openness and transparency of the developmentprocess used in those Projects and can also settle certain kinds ofprocedural disputes. The OpenJDK Lead sits on theGoverning Board.
Many of the actions defined in these Bylaws are approved orratified by a group of individuals using one of the followingvoting methods.
For all of the methods:
Votes take place over a period of two weeks, unless otherwisespecified.
Voters may change their votes at any time during a votingperiod. Only a voter’s most recent vote is counted.
The individuals participating in a vote must act in goodfaith.
The individual who proposes an action must respond in a timelyfashion to all questions and objections raised during the votingperiod.
Except where noted, all votes are to be conducted transparentlyon the appropriate public OpenJDK mailing list. All voters casttheir votes on that list, and the individual who calls a vote isresponsible for announcing the result at the end of the specifiedvoting period.
The Governing Board will monitor votes to ensure that theyproceed in accordance with these Bylaws. In exceptionalcircumstances the Board may invalidate an individual’s vote,invalidate the entire vote, or take some other unspecifiedaction.
Consensus voting These methods are used fordecisions that do not require the full attention of the set ofeligible voters.
In the consensus methods the possible votes are Yes, Veto, andAbstain.
AVeto must beaccompanied by a justification; a Veto without a justification isinvalid. If a Veto is raised then the voter who raised theveto and those who support the proposed action must work togetherto reach a mutually-agreeable resolution. If a Veto isresolved then the voter who raised the Veto must withdraw that voteby explicitly abstaining or by casting a Yes vote.
These Bylaws use two methods of consensus voting:
LazyConsensus — There are no vetoes.
Three-Vote Consensus — There areno vetoes, and at least three Yes votes or else unanimity if thereare fewer than three eligible voters.
As an optimization, if all eligible voters vote Yes before thevoting period ends then the action is approved at that time.
TheOpenJDK Lead may, inexceptional circumstances, choose to overrule an unresolved Veto;such a decision may be appealed to theGoverning Board.
Majority voting These methods are used forhigher-level decisions in which it is best to have the fullattention of many, if not nearly all, of the eligible voters.
In the majority methods the possible votes are Yes, No, andAbstain. A No vote is not a veto, it is simply a negative vote. ANo vote may be accompanied by a justification, but that is notrequired.
These Bylaws use two basic methods of majority voting:
Simple Majority — There are more Yesvotes than No votes.
Two-Thirds Majority — There are atleast twice as many Yes votes as No votes, and at least three Yesvotes or else unanimity if there are fewer than three eligiblevoters.
The majority methods have corresponding though rarely-usedAbsolutevariants:
Absolute Simple Majority —There are more Yes votes than No votes, and at least half (roundedup) of all eligible voters vote Yes.
Absolute Two-Thirds Majority— There are at least twice as many Yes votes as No votes, andat least two thirds (rounded up) of all eligible voters vote Yes orelse unanimity if there are fewer than three eligible voters.
AGroup is a collection ofParticipants who engage in openconversation about a common interest. That interest may be in thecreation, enhancement, or maintenance of a specific body of code orit may lie in other areas,e.g., quality ordocumentation.
Groups may have web content and one or more mailing lists.Groups do not have code repositories of their own but they maysponsorProjects, which do.
Groups are expected to operate in an open, transparent, andmeritocratic manner. Their alignment with these principles will bemonitored by theGoverningBoard.
AnyOpenJDK Member maypropose the creation of a new Group or the dissolution of anexisting Group. TheGoverning Board may approve the creation ofa new Group by aSimpleMajority vote; it may dissolve an existing Group by aTwo-Thirds Majority vote.
AGroupMember is aContributorwho has demonstrated a history of significant contributions to aGroup and, as a result, has been granted Membership in that Group.A Member of a Group has write access to the Group’s webcontent and file repositories.
A Member of a Group may nominate any Contributor to be a newMember of that Group. Such nominations are approved by aLazy Consensus of theGroup’s Members.
A Member of a Group may raise a motion to remove another of thatGroup’s Members. Such a motion must be approved by aTwo-Thirds Majorityof the Group’s Members, with the Member who is the subject ofthe motion abstaining.
AGroupLead is a Member of a Group and an OpenJDK Member who isresponsible for directing and coordinating that Group’sactivities. A Group’s Lead has:
The authority to sponsorProjects;
The obligation to act as a contact point for the Group and tolook after the Group’s mailing lists and web content; and
The obligation, once per quarter, to publish a written reportsummarizing the recent activities of the Group.
A Group’s Lead may delegate selected obligations, but notauthorities, to other of that Group’sMembers as desired. A Group’s Lead maydelegate all authorities to another of that Group’s Memberswho is also anOpenJDKMember, but only on a temporary basis.
Any procedural decision by a Group’s Lead may be appealedto theGoverningBoard.
When a Group is created its initial Group Lead is nominated bythe proposingOpenJDKMember and approved by aSimple Majority of theGoverning Board.
When a Group is created then its initial Group Lead, onceselected, appoints the initialMembers.
If a Group Lead resigns or departs then a new Group Lead may benominated by anyOpenJDKMember. The nomination must be approved by aSimple Majority of the Group’sMembers and ratified by a Simple Majority of theGoverning Board.
AnyOpenJDK Member mayraise a motion to remove a Group’s Lead. Such a motion mustbe approved by aTwo-Thirds Majority of the Group’sMembers, with the Group Lead abstaining, and ratified by aSimple Majority of theGoverning Board.
The Governing Board may, in exceptional circumstances, remove aGroup Lead by aTwo-Thirds Majority vote.
AProject is a collaborative effort toproduce a specific artifact, which may be a body of code, ordocumentation, or some other material. Projects may range in scopefrom small features toentire JDK releases.
A Project may have web content, one or more code repositories,and one or more mailing lists.
Projects are expected to operate in an open, transparent, andmeritocratic manner. Their alignment with these principles will bemonitored by theGoverningBoard.
AnyContributor maypropose the creation of a new Project. If supported by at least oneGroup Lead, whoseGroup willSponsor the Project, and approved by aLazy Consensus of theOpenJDK Members, then the Projectwill be created.
A Group’s Lead may declare that Group to be aSponsor of an existingProject. The Members of a Group that is Sponsoring a Project maydecide, byLazyConsensus, to withdraw that Sponsorship. A Project may havemore than one Sponsoring Group.
If a Project loses all of its Sponsoring Groups then it isdissolved. A Project’sCommitters may decide, byLazy Consensus, to request explicitly thatthe Project be dissolved. TheGoverning Board may, in exceptionalcircumstances, dissolve a Project by aTwo-Thirds Majority vote.
When a Project is dissolved its materials are archived. Adissolved Project may be re-created by being re-proposed.
JDK Release Projects New releases ofJava SE Platform implementations are Projects. Such Projects mayonly be proposed by theOpenJDKLead and may only be sponsored by theGoverning Board. The OpenJDK Lead is theProject Lead for all JDKRelease Projects. Every OpenJDK Member will have the opportunity topropose features for inclusion in JDK Release Projects, anddecisions about which features to include will be made in atransparent manner.
Availability ofSpecifications and Tests Insofar as a Project involves the useof specifications of, and tests for, the code being developed, thenall such material as may be required for aContributor to make timely and effectivecontributions to the Project should be made available in theProject’s repositories under the appropriateopen-sourcelicense when possible. If a relevant specification or test isnot available under such terms, and a contribution is refusedbecause it violates that specification or fails to pass that test,then those who require the use of that specification or test areobligated to explain the problem to the submitting Contributor andprovide reasonable assistance to help resolve it.
AnAuthor for aProject is aContributor whohas been granted the right to create changesets intended to bepushed into a specific Project’s code repositories, but doesnot have the right to push such changesets directly.
ACommitterto a Project is an Author who has been granted direct push accessto the Project’s code repositories.
A Committer to a Project may nominate anyContributor to be a new Committer to thatProject. Such nominations are approved by aLazy Consensus of the Project’sCommitters.
A Committer to a Project may raise a motion to remove another ofthat Project’s Committers. Such a motion must be approved byaTwo-ThirdsMajority of the Project’s Committers, with the Committerwho is the subject of the motion abstaining.
AReviewer fora Project is an experienced Committer who has the authority toapprove changesets destined for code repositories designated by theProject Lead as requiringformal change review. Projects that do not require any formalchange review will not have any Reviewers.
A Reviewer for a Project may nominate any of thatProject’s Committers to be a new Reviewer for that Project.Such nominations are approved by aThree-Vote Consensus of theProject’s Reviewers.
A Reviewer for a Project may raise a motion to revoke theReviewer role of another of that Project’s Committers, unlessthat Reviewer is the Project’s Lead. Such a motion must beapproved by aTwo-ThirdsMajority of the Project’s Reviewers, with the Reviewerwho is the subject of the motion abstaining.
AProjectLead is a Committer to that Project who is responsible fordirecting and coordinating the Project’s activities. AProject’s Lead has:
Full authority over all technical matters relating to theProject;
The authority to appoint and removeAuthors who are not alsoCommitters;
The authority to designate specific code repositories asrequiring formalchangereview;
The obligation to act as a contact point for the Project and tolook after the Project’s mailing lists, web content, and coderepositories.
The obligation, once per quarter, to publish a written reportsummarizing the recent activities of the Project.
A Project’s Lead may delegate selected obligations, butnot authorities, to other of that Project’sCommitters as desired. A Project’s Leadmay delegate all authorities to another of that Project’sCommitters, but only on a temporary basis.
Any procedural decision by a Project’s Lead may beappealed to theGoverningBoard.
A Project’s Lead is automatically considered to be aReviewer, and remains aReviewer even after leaving the Project Lead role.
When a Project is created, or when its Project Lead resigns ordeparts, candidates for a new Project Lead may be nominated by theGroup Leads of aProject’sSponsoringGroups. Such a nomination must beapproved by aThree-Vote Consensus of these GroupLeads. If agreement amongst these Group Leads cannot be reachedthen theOpenJDK Lead willselect one of the nominees; this decision may be appealed to theGoverning Board.
When a Project is created then its initial Project Lead, onceselected, appoints the initialAuthors,Committers, andReviewers.
AnyOpenJDK Member mayraise a motion to remove a Project’s Lead, unless the Projectis aJDK ReleaseProject. Such a motion must be approved by aTwo-Thirds Majority of theProject’s Committers, with the Project Lead abstaining, andratified by aSimpleMajority of theGoverning Board.
The Governing Board may, in exceptional circumstances, remove aProject Lead by aTwo-Thirds Majority vote.
AnyGroup Member orCommitter may be nominated tobe anOpenJDK Member by an existingOpenJDK Member. Such a nomination must be approved by aThree-Vote Consensus of theOpenJDK Members.
Any OpenJDK Member may raise a motion to remove another OpenJDKMember. Such a motion must be approved by aTwo-Thirds Majority of the OpenJDKMembers, with the Member who is the subject of the motionabstaining.
TheGoverning Boardmay, in exceptional circumstances, remove an OpenJDK Member by aTwo-Thirds Majorityvote.
Every OpenJDK Membership is subject to automaticExpiration after one year,but will be renewed upon request. A request for renewal must bereceived within one year of expiration. An OpenJDK Member whoseMembership has expired and not yet been renewed may not exercisethe privileges of Membership, except that roles requiring OpenJDKMembership may be retained.
If an OpenJDK Member’s employment situation changes suchthat contributions would no longer be covered by theOCA or its equivalent then the Member mustrelinquish theContributorrole by notifyingOpenJDKLead. At this point the Membership will be considered to haveexpired.
TheOpenJDK Members Group consists of allOpenJDK Members. TheOpenJDKLead is its Group Lead. The usual rules for dissolving Groups,adding and removing Group Members, and selecting and removing GroupLeads do not apply to the OpenJDK Members Group.
TheGoverning Board manages thestructure and operation of the OpenJDK Community.
The Governing Board consists of fiveContributors:
The Governing Board is, in part, a legislative body: It isempowered to revise these Bylaws to refine existing processes, todefine new processes, and to dispose of processes that are nolonger required. Any revision of these Bylaws must be approved byanAbsoluteTwo-Thirds Majority of theGoverning Board and then ratified by Two-Thirds Majority of OpenJDKMembers.
The Governing Board is also, in part, a judiciary body: It isempowered to resolve any procedural disputes which may arise withinthe Community. Any procedural decision made by an individual, asdescribed in these Bylaws, may be appealed to the Governing Board.If the Governing Board decides to hear an appeal then a proposedjudgement must be approved by aSimple Majority vote.
The Governing Board is not an executive body: It has no directauthority over technical or release decisions. That authority isheld, for any givenProject, bythat Project’sLead,and in particular by theOpenJDK Lead forJDK Release Projects.
The Governing Board is aGroup,with the Chair as its Lead. This allows the Governing Board tosponsor Projects. The usual rules for dissolving Groups, adding andremoving Group Members, and selecting and removing Group Leads donot apply to the Governing Board.
Meetings The Governing Board shall meet at leastonce per calendar quarter, either in person or via teleconference.Meeting minutes will be posted publicly, after being reviewed andapproved by the Governing Board.
The Governing Board may decide, by aSimple Majority vote, to hold a meeting orpart of a meeting inPrivate Session, in which case the publicmeeting minutes will only record any votes that were taken.
The Governing Board may also decide, by aSimple Majority vote, to hold anOpen Meeting towhich all OpenJDK Members are invited.
Votes Governing Board votes may be conducted duringmeetings. A meeting of the Governing Board is considered quorate ifa simple majority of its members are present; that is, more membersare present than absent.
Votes may also be conducted asynchronously, via e-mail orsimilar mechanisms, in which case the voting period shall be sevencalendar days unless otherwise stated in the call for votes, but inany case not less than 48 hours. In an asynchronous vote a majorityof members must declare themselves present before the end of thevoting period, even if they do not vote. An asynchronous vote isconducted transparently unless the Governing Board first votes, byaSimple Majority, toconduct it privately.
Observers The Governing Board may, by aSimple Majority vote, invitespecific individuals to attend Governing Board meetings asObservers. Such individuals need not beOpenJDK Members. Observers are welcome to both listen andcontribute to the conversation, but they do not have any votingrights. The Governing Board may remove an Observer by a SimpleMajority vote.
Quarterly Reports Once per calendarquarter, and one week prior to that quarter’s scheduledmeeting of the Governing Board, theOpenJDK Lead shall publish a written reportsummarizing recent activities in the Community. This report shouldinclude:
A summary of notable recent activities ofGroups andProjects, including noteworthy proceduraldecisions;
A list of Projects that have made major state changes such aspublishing a release, integrating into aJDK Release Project, or submitting orcompleting a JSR;
A list of Projects that should, in the OpenJDK Lead’sopinion, be considered for inclusion in a future JDK ReleaseProject and its corresponding Umbrella JSR;
An assessment of the openness and transparency of thedevelopment process and its supporting infrastructure; and
Statistics on committer activity, bug-fix rates, and Communitygrowth.
Annual Review The Governing Board shall conductan annual review of all of the Community’sGroups andProjects, dissolving any such that are determined tohave become inactive.
At-Large Members The At-Large Members of theGoverning Board are chosen by a vote of theOpenJDK Members. At-Large Members serve for aterm of one calendar year, starting on the first day of April eachyear.
During a two-week nomination period any OpenJDK Member maynominate an individual who does not currently hold an appointedGoverning Board seat to fill one of the At-Large seats. Thatindividual need not already be an OpenJDK Member. An OpenJDK Membermay make more than one such nomination.
During a two-week voting period, commencing shortly after thenomination period, the new At-Large Members are chosen from the setof nominees by a vote of all OpenJDK Members.
If there are no more nominees than there are open seats theneach nominee must be approved by aSimple Majority of voting Members. If anyseat remains empty after this process then a new election will beheld to fill it.
If there are more nominees than there are open seats then therequired number of At-Large Members will be selected from thenominees using theSingleTransferable Vote method with theMeekalgorithm.
If an At-Large Member resigns or departs mid-term, with at leasttwo months remaining in the term, then a special election will beheld to fill that seat for the remainder of the term.
Expansion and Contraction TheGoverning Board shall never consist of fewer than five individuals.It shall always include aChair, aVice-Chair, anOpenJDK Lead, and at least twoAt-Large seats as describedabove.
The Governing Board may, by anAbsoluteTwo-Thirds Majority vote, add or removeboth appointed and At-Large Governing Board seats.
Technical Appeals Process If aGoverning Board member objects in good faith to a technical orrelease decision made by theOpenJDK Lead then that decision may be appealedvia the following process.
An objection to a decision made by the OpenJDK Lead must beraised no later than two weeks after that decision.
Within two weeks of the initial objection, the objecting Boardmember and the OpenJDK Lead will each nominate a neutralthird-party technical expert to arbitrate the decision. Within twofurther weeks these two arbiters will together agree on a suitablethird neutral expert to join them in creating an Arbitration Panelof three individuals. These experts need not be OpenJDK Members oreven Participants.
Within two weeks of the selection of the Panel the objectingBoard member will submit to the Panel and the OpenJDK Lead awritten description, not to exceed 1,000 words, of theobjection.
Within two weeks of the objecting Board member’ssubmission the OpenJDK Lead will submit to the Panel and theobjecting Board member a written rebuttal, also not to exceed 1,000words, describing the rationale behind the decision and the way inwhich it is reasonable.
Within two weeks of the OpenJDK Lead’s rebuttal the Panelwill render a decision, made by anAbsoluteSimple Majority vote. The Panel may, duringits deliberations, consider any other information it deemsappropriate and may consult with other individuals asnecessary.
Both the written submissions and the judgment of the Panel willbe published as soon as they are available unless the Panel, onpetition from the objecting Board member or the OpenJDK Lead,determines that publication is not in the best interest of theOpenJDK Community.
Only three unsuccessful appeals by any particular GoverningBoard member are permitted in any twelve-month period.
Participants in theOpenJDK Community collaborate on code licensed under theGNU General PublicLicense (GPL) version 2 with the Classpath Exception and theOpenJDKAssembly Exception, and under other licenses approved by eithertheFree Software Foundation or theOpen Source Initiative.
The “OpenJDK” trademark is owned by OracleCorporation but will continue to be available for use by othersunder the terms of theOpenJDKTrademark Notice, or similar terms.
The data stored in any infrastructure provided for use byCommunity members must be made available by some means thatenables, without undue effort, the construction of a completefunctional clone of that infrastructure and its data as seen by theentire Community.
The OpenJDK Community has, since its inception in 2006, beenoperating under a set of informal guidelines forGroups andProjects. The followingchanges will be implemented when these Bylaws take effect:
The initial set ofGroups willbe the current set of Groups, with their existingGroup Members.
TheOpenJDK MembersGroup will be created, and the initial set ofOpenJDK Members will be thoseContributors previously voted intoGroup Membership. Each such new Membership will expire on theanniversary of the initial registration of that Member in theOpenJDK Community database.
The initial set ofProjectswill be the current set of Projects, with their existingCommitters.
The initialGroup Leads,Project Leads, andReviewers will be appointed bytheOpenJDK Lead.
The initialAt-LargeMembers of theGoverningBoard will be appointed by mutual agreement of theChair and theVice-Chair.