OpenJDK GB Minutes: 2007/7/17

[Mark Reinhold]

Attached please find the minutes of the second meeting of the Governance
Board.  The minutes are also available on the web:

    http://openjdk.java.net/groups/gb/2007-07-17.html

To answer an obvious question: These meetings were held way back in July;
why are the minutes only being published today?  Summer vacations, busy
schedules, and a series of unforeseeable non-work calamities conspired to
induce this delay.  As Chair of the GB I will endeavor to produce minutes
in a more timely fashion going forward.

Respectfully submitted,
- Mark

-------------- next part --------------

OpenJDK Governance Board Minutes: 2007/7/17
Mark Reinhold <mr at sun.com>

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.

[end]