Governance Board Minutes: 2007/7/17

The second meeting of the OpenJDK Governance Board took place via conference call on Tuesday, 17 July 2007 at 16:00 UTC, with the following agenda:

1 Timeline for work
2 Definition of quorum
3 Constitutional principles (cont’d)
4 Conclusion and administrivia
5 Summary of principles

All GB members were present: Doug Lea, Fabiane Nardon, Dalibor Topic, Simon Phipps, and Mark Reinhold.

The intent of these minutes is to capture the conversational flow of the GB’s discussion and also to record agreed-upon resolutions. If you are interested only in the latter then search for the word “AGREED” throughout the text.

1 Timeline for work

Mark opened this topic by observing that, according to the OpenJDK Charter, the Interim Governance Board will dissolve on 8 May 2008, one year after it was created. This duration was intentionally written into the Charter so as to motivate the GB to complete its constitutional work in a timely fashion. The work could, theoretically, go on for longer than a year, but in order to get the Community fully up and running it’d be far better to finish sooner rather than later.

Mark then suggested that the GB aim to have a draft Constitution by February or March of 2008, with a ratification election shortly thereafter, so that there’s a good chance that the work can be finished before the GB dissolves.

Simon proposed the more aggressive goal of having a draft document ready in December, saying that ratification is a very tricky problem, and we’ll need plenty of time to discuss it and define the process. Dalibor agreed, and said that November would be even better so that there would be six months for the discussion and the process.

Simon elaborated on the OpenSolaris experience, in which that GB didn’t publicly define and discuss the constitutional ratification process until after their Constitution was written. The initial OpenSolaris GB, like the initial OpenJDK GB, was appointed rather than elected. It had intended that the first elected OpenSolaris GB should review the Constitution and, if any mistakes were found, correct them and then re-ratify the resulting revised Constitution. This intention was, however, not widely communicated, and as a result the ratification process was highly contentious because many people thought the initial Constitution was defective.

Simon went on to say that, in terms of bootstrapping, the thinking in the OpenSolaris GB was that it first had to define freestanding rules by which the constitution could be changed, decree that they were in force, and then run the ratification process according to those rules.

Reflecting on these experiences, Simon suggested that one of the first deliverables for this GB should be an initial definition of the ratification process. That would allow plenty of time for open discussion and revision, so that by the time the ratification process actually begins it will be widely understood and trusted.

Simon then proposed a high-level timeline, which after some discussion became:

October 2007 Draft of ratification process
December 2007 Draft of entire Constitution
January-March 2008 Discussion period
April 2008 Ratification vote

It was then unanimously

AGREED To adopt the above timeline for the work of this GB.

2 Definition of quorum

Mark stated that he’d prefer not to run these GB meetings using formal rules of order, but even so we should agree upon the definition of a quorum. An easy answer would be to say that everyone must be present, but that could lead to intractable scheduling problems as we move from the summer vacation season into the busier parts of the year.

Doug suggested that all-but-one might be a suitable compromise. Fabiane agreed. Dalibor agreed and proposed further distinguishing between decision-making meetings and brainstorming sessions, saying that all-but-one should be required for decision making but any number would be suitable for brainstorming.

Simon argued against this proposal. His view, based on past experience, is that when the total number of members is small then a formal vote should require that all members be present, though discussions need only require three.

Mark observed that, although GB members are always free to speak with one another, if a brainstorming meeting is held then it should still be taken at least somewhat seriously, and in particular minutes should be generated even if no decisions are made.

Dalibor suggested raising the discussion quorum back to four, on the basis that two members absent is nearly half the membership of this small group, and that it’s easier to keep everyone in sync if most members are present for on-the-record discussions.

The GB then unanimously

AGREED Formal votes shall require all members to be present.
AGREED On-the-record discussions shall require at least four members to be present.

3 Constitutional principles (cont’d)

The constitutional principles discussion then resumed, with Mark proposing

P8 The number of roles in the Community should be minimized.

Mark observed that some open-source communities tend to create lots of structure with lots of different roles, usually with little tangible benefit. The OpenJDK Constitution should define as few roles as possible, and not allow new roles to be created gratuitously. There was general agreement on this point.

Mark then proposed his final principle:

P9 Decisions at all levels should be made by informal consensus, calling votes only when absolutely necessary.

Mark elaborated that this principle should apply not only to the GB but to all other bodies in the Community that need to make decisions. He said that his proposal of this principle was driven partly by his perception of the decision-making practices of some other open-source communities, and in particular those of the Apache Software Foundation, to be overly formal and not all that conducive to constructive collaboration.

Simon argued that Mark’s perception was incorrect, saying that in fact the Apache model works quite well because, although it is precisely defined, it’s treated as lazy consensus most of the time and, further, casting a negative (-1) vote is not seen as a blocking move but rather as volunteering to solve a problem that you’ve identified. In actual use the Apache system is very relaxed and lightweight and, in Simon’s opinion, about as close as possible to facilitating casual consensus while still having the rigor required to resolve difficult disputes. He explained that this was consistent with Roy Fielding’s view, expressed to the OpenSolaris GB, that the role of the constitution is to act as the boundary to acceptable behavior; most people operate far away from the boundary, but if you don’t define the boundary then when boundary conditions occur you’re left with no guidance.

Simon went on to say that it’s important that we not simply to adopt the voting rules of Apache, or indeed those of any other existing community, for use in OpenJDK, precisely because of this common kind of misperception. It’s difficult to understand how a community’s decision-making rules work unless you’ve been part of that community, so the OpenJDK Community should develop and evolve its own set of rules, in accordance with its own needs and style.

Mark replied that he was happy to have his perception of the Apache model corrected, and that he agreed that what Simon had said made sense.

In turn Simon replied that he actually agrees with this proposed principle, it’s just that it’s important to recognize the need to have some rigor behind the notion of “informal consensus” so that when it fails there is something upon which to fall back.

At this point Doug asked for clarification as to what kinds of decisions this principle is meant to apply. Mark replied that it should be universally applicable, from low-level things like code reviews, to feature and release decisions, and on up to higher-level community-governance sorts of decisions such as recognizing new community members, creating new groups and projects, electing GB members, and ratifying and revising the Constitution.

Simon gave the example of a recent vote in the Apache Harmony project which used the second-most relaxed style of that community’s four voting styles to come to a decision on building a regression-testing framework. A vote on a more serious issue in Apache, e.g., modifying the constitution, would use a more rigorous voting style that requires a longer review period and restricts whose votes are actually counted. In an Apache discussion anyone who wants to can vote, and even though only some votes count it’s unusual for a vote to complete without all of the negative votes having been discussed, regardless of who cast them. Every kind of decision in the Apache community is made using one of their four voting styles, each of which has a different level of rigor and places different responsibilities upon voters.

It was generally AGREED that this principle should be adopted, revised thusly:

P9 Decisions at all levels should be made by informal consensus whenever possible, but there should also be rigorous voting rules upon which to fall back when informal consensus fails.

The discussion then turned to Fabiane’s proposals, the first of which was

P10 Leaders of Community groups should participate in Community-wide decisions.

Mark noted that this principle seems to imply that community-wide decisions would be made not by everyone in the community who has a vote but rather just by the leaders of the community’s groups. Fabiane indicated that having everyone vote could lead to problems of scale in a large community, and that it made sense to her to have group leaders with some sort of privileged vote.

In reply Mark observed that identifying the leader, or leaders, of a group can actually be a bit of a problem. The social dynamic within the Sun JDK team is that there’s not a well-defined leader for every group, and in fact there are some groups whose social nature is such that if you tried to identify a leader then their members would get very upset.

Doug agreed that trying to identify people as leaders does invite social friction, and it’d be nice to avoid that, but somebody has to be in charge of some things.

Mark agreed, and explained further that this is why the interim rules for Groups and Projects use the concept of a Moderator rather than that of a leader. A Moderator is more of a contact point and coordinator rather than someone with some extra kind of decision authority that goes beyond those of the members of the group.

Dalibor asked Fabiane how this works in the java.net Tools Community, which she herself co-leads. Fabiane replied that in java.net each community has a leader, or set of leaders. When a java.net-wide decision needs to be made, e.g., on whether to approve the creation of a new community, the community leaders are the ones who vote. Each community has its own rules on how to select its leaders. People don’t fight to be community leaders; usually it’s a matter of finding someone who will accept the position.

Mark suggested that this issue be tabled for now, suspecting that whether or not we need strong group leaders with special voting privileges will become clearer over time as we develop a better sense of the sorts of community-wide decisions that will be made.

Fabiane agreed to this. Doug noted that probably the best thing we can do is arrange things so that natural group leaders, or moderators, can emerge on their own and have the freedom of action they need in order to be effective.

OPEN ISSUE Should the Constitution grant special powers to identified leaders of community groups? Should community-wide decisions be made by group leaders rather than by all participants with appropriate voting rights?

Fabiane’s next suggestion was that the Constitution will have to define processes for creating and dissolving groups, projects, and other kinds of Community entities. It was agreed that this will be necessary.

Fabiane’s third suggestion had been discussed and agreed earlier, as P3.

Fabiane’s next proposed principle was

P11 Participation in the Community shall be free of charge.

She said that she thinks this idea is pretty obvious yet important to make clear, since some communities that she’s worked in do require payment for participation. Everyone agreed to this principle.

Fabiane’s final principle was:

P12 All decision-making processes and discussions should be as transparent as possible.

She clarified that she didn’t mean to suggest that the entire community should be involved in every decision, but rather that it must be possible for everyone to see what decisions are being made at every level, and why, and be able to voice their opinions in order to try to influence them even if they don’t themselves have a vote. This principle was readily agreed to, given that it echoed the resolutions adopted earlier with regard to the working style of the GB itself.

This concluded the GB’s two-part discussion of constitutional principles.

4 Conclusion and administrivia

To move forward, Mark suggested that a useful way to start thinking about the Constitution as a document would be to list all of the concepts that we think we need to define and then start drafting definitions so that we can consider the relationships between them. This can largely be done in e-mail, with GB meetings called only as needed.

After additional discussion, and confirmation in e-mail, it was

AGREED The GB members shall hold one hour open, at 0800 Pacific time every Thursday, for a potential GB conference call. Any member may call an actual meeting during this hour by giving two days’ notice to the membership. If no such notice is given then no meeting will be held.

At this point the GB adjourned.

5 Summary of principles

In its first two meetings the GB membership AGREED to the following initial, though non-exhaustive, set of constitutional principles:

P1 The Governance Board is a legislative and judiciary body; it is not an executive.
P2 Community participants are individuals, not corporations.
P3 The investments made by the employers of Community participants should be acknowledged publicly.
P4 Community privileges are granted on the basis of proven merit, as judged by peers; they are not granted on the basis of one’s employer.
P5 One need not have proven merit in order to start participating in the Community.
P6 Community privileges do not last forever.
P7 Community governance is distinct from project governance.
P8 The number of roles in the Community should be minimized.
P9 Decisions at all levels should be made by informal consensus whenever possible, but there should also be rigorous voting rules upon which to fall back when informal consensus fails.
P11 Participation in the Community shall be free of charge.
P12 All decision-making processes and discussions should be as transparent as possible.