Governing Board Minutes: 2011/5/26
The OpenJDK Governing Board met via conference call on Thursday, 19 May 2011 at 15:00 UTC with the following agenda:
- Feedback on draft 9 of the Bylaws
- Ratification vote
- Bug database
- Summary of upcoming process work
All Board members were present: Jason Gartner, Doug Lea, Adam Messinger, Mike Milinkovich, and Mark Reinhold.
Two Observers were present at the start: John Duimovich and Andrew Haley. Georges Saab joined the call about ten minutes late.
The intent of these minutes is to capture the conversational flow of the Board’s discussion and also to record decisions. If you are interested only in the latter then search for the word “AGREED” throughout the text.
1. Feedback on draft 9 of the Bylaws
Mark reported that there had been little feedback, so far, on draft 9 of the Bylaws.
Mike asked if there had been any feedback beyond that on the gb-discuss mailing list; Mark said he’d received one comment privately. In reply Mike suggested that the Board should give more weight to public comments than to private comments. Andrew agreed, saying that we should encourage those sending private feedback to re-send it to the public list. Doug reminded the Board that some commenters prefer to remain anonymous since they don’t want it to be known that they’re thinking about becoming Contributors. Mark asked whether all private feedback should be ignored; Jason replied that since we’re doing all we can to be public and open, it’s only reasonable that people should provide feedback in the same manner.
At the end of this discussion the general sense of the Board was that public feedback is strongly preferred but private feedback should not be ignored.
Mark asked if the Board was concerned about the small amount of feedback received. Andrew noted that he was himself finding it difficult to set aside the time required to review the Bylaws in detail, so perhaps other reviewers just haven’t had the time yet. Adam thought it likely that the level of feedback reflects the reality of the OpenJDK Community: Most people would rather write code than worry about politics. Mike suggested reminding people, via e-mail, of the deadline for feedback; Mark agreed to send that later the same day.
2. Ratification vote
Mark presented the following graph of contributions over time, based upon the content of all the OpenJDK Mercurial repositories as of 2011/5/24:
16 | 94 89 73 57 14 | 98 94 77 61 12 | 103 99 83 67 10 | 108 105 93 73 8 | 114 112 98 78 5 | 129 127 112 88 4 | 135 131 116 94 2 | 163 159 144 127 1 | 180 176 158 143 -------------------- 4y 3y 2y 1y
In this graph the Y axis is the minimum number of unique nontrivial (i.e., non-merge, non-tag) changesets across all repositories. The X axis is time in years, going backwards from today (i.e., the leftmost column is the longest ago). The sample at (x, y) is the number of contributors who created at least y unique changesets over the past x years.
The Board discussed various durations and changeset-count thresholds, trying to come up with a combination that would tend to admit only serious contributors while not going so far as to limit the electorate to just those “old hands” who have been contributing from the start. It was eventually
AGREED: The Ratification Electorate will be composed of those Contributors who have created at least five unique nontrivial changesets in the OpenJDK Mercurial repositories in the two years preceding the start of the Ratification Vote.
The discussion then turned to the mechanics of the vote. Mark suggested that the simplest thing to do is an e-mail-based vote, using a restricted mailing list to which only members of the Electorate are allowed to post. He then asked whether individual votes should be public or private. It was quickly agreed that votes should be public, at least once the vote is over. Adam then suggested that votes should be public from the moment they’re cast, since keeping them secret until the end could theoretically give Oracle an information advantage. Mark agreed with Adam and so did Jason, pointing out that someone who wants to control when their vote becomes visible can just wait until the very end of the voting period. Hence it was
AGREED: Votes will be cast by sending e-mail to a public mailing list. Messages from anyone who is not a member of the Ratification Electorate will be discarded. Votes will be publicly visible at the time they are cast.
3. Bug database
Mike requested this agenda item in response to a related discussion on the general-discussion list. He wanted to know who should be allowed to submit bug reports, observing that he does not know of any open-source community that restricts the general public from submitting bugs, and that submitting bugs is a great way for new people to get started in a community.
Doug agreed with Mike, pointing out that some level of access control is inevitable, if only to combat spam and to conceal security bugs, but that otherwise he doesn’t want the system to have any hidden process obstructions such as those in the present closed system.
Adam agreed that outsiders should be able to submit bugs, but such bugs might not necessarily become public right away if they’re security bugs. Allowing only Contributors to submit bugs would be setting the bar too high, but making it open to absolutely anyone might be setting the bar too low.
Jason agreed on the need for a filtering process but said that otherwise the system should be as open as possible, arguing that we especially need to encourage “here’s a bug, and here’s a fix” reports from newcomers.
Mark observed that the OpenJDK Community does not itself ship end-user binaries, and wondered whether this would cause confusion. If someone finds a bug in their JRE should they submit it to Red Hat, to Oracle, to IBM, or to OpenJDK? Mike argued that as a multi-vendor community we should want all bugs to come to OpenJDK. John explained that if IBM customers submit bugs to IBM that are really in OpenJDK then IBM would refile them in OpenJDK. Andrew said that in that kind of situation at Red Hat they generally ask the filer to resubmit the bug upstream.
Mike argued that it should be possible to submit a bug without having to sign the OCA. Mark replied that he knew of no legal requirement for the OCA in that case.
By the end of the discussion the general sense of the Board was that:
One shouldn’t have to be a Contributor in order to submit or update a bug;
It’s okay to require a new bug submitter to agree to a terms-of-use document and provide e-mail contact information; and
Some amount of filtering and triage to reduce spam and keep security bugs concealed is acceptable.
4. Summary of upcoming process work
This topic was, yet again, deferred to the next meeting due to time constraints.
At this point the Board adjourned.