Talk:Sugar Labs/Governance

DRAFT?

Maybe time to remove "DRAFT" from the page?

Other examples

Please list links to other OSS projects governance documents that may serve as examples of what to do (or what not to do)

OSS Governance documents

• http://foundation.gnome.org/about/

Books discussing OSS projects

Links to books (articles) that may make interesting background reading

• http://producingoss.com/
  • Karl Fogel, who has worked on the development teams of CVS, GNU Emacs and Subversion, and is also the writer of “Open Source Development with CVS”—has introduced an extremely comprehensive project guide that will change the way people begin and think about open source projects.

• http://www.dreamingincode.com/
  • Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. The story of Mitch Kapor's Chandler project.

Document length

This is a pretty long and complex document for a first pass at governance of a small project. Most of the details (of becoming a member, having specific committees, or contributing as an organization) could more simply be left on their own pages, and the core gov documents reduced to a few dozen lines. +sj + 03:50, 11 June 2008 (UTC)

I've moved some of the details to subpages. --Walter 16:43, 12 June 2008 (UTC)

Decision panels

This seems to be the most controversial topic:

One the one hand:

As the instigator of this Decision Panel business, I should attempt to clarify the idea. My goal is to make serving on the Oversight Board as unappealing as possible. Ideally, it should be _difficult_ to find seven people willing to serve on the Oversight Board. As such, the document specifies that members of the Oversight Board _cannot_ decide controversial issues. It also specifies that members of the Oversight Board _must_ act as secretaries, taking minutes for every meeting of every committee. Oversight Board members are also prohibited from voting in any of the committee meetings, even though they must attend to take minutes (that's been part of the draft from the beginning). I hope this will be a very frustrating experience for members of the Oversight Board.

I am a firm believer that the worst people to give power are those who want it. The Oversight Board, as described so far, has the responsibility of keeping Sugar Labs running smoothly, but almost no power to decide the interesting issues. This makes me very happy, as the Oversight Board is therefore most likely to attract people who are interested only in keeping Sugar Labs running, not pushing a particular personal agenda, even a technical agenda. My hope is that people will be elected based on a history of being calm, focused, personable, and reasonable, not on the basis of any platform (they don't have the power to execute it) or technical knowledge (they can't use it).

I would much rather keep the technical experts _out_ of governance until a technical decision must be made that requires domain-specific expert knowledge. Most technical decisions should be made on the mailing lists anyway; only issues that must be decided in order for work to continue, and on which the community is otherwise deadlocked, should be escalated to a Decision Panel. I expect the Oversight Board to be concerned almost exclusively with the mundane details of managing finances and partnerships, making sure the communications channels are open, etc. I do not want the Oversight Board to be a Court of Last Resort.

I still favor the presence of the Decision Panels section in the draft, but that's not surprising. I see it as an easy lightweight system for moving political issues away from the Oversight Board. I welcome other perspectives.

--Ben

On the other hand:

Why would anyone volunteer for such service? We'd get what it encourages: unmotivated people who don't really care, except for the political power of appointing people, and the *inevitable* recognition they get as part of the oversight board. They won't have the respect of the community either; as written, board members can't serve on decision panels, and therefore can't make any of the "important decisions", presuming the board actually follows the bylaws and appoints a decision panel. And it has a built in disincentive for creating committees and delegating (something we want to encourage, not discourage): the requirement that the board members act as secretaries, causing a yet larger time sink by board members.

The board member can hide behind "the appointed committee" and absolve themselves of blame.

So this separates authority from responsibility. Anything controversial is by its nature something where each vote a board member makes can be held accountable for, and either recalled immediately or voted out at the next election, if appropriate. Hopefully these votes occur very seldom; decisions should normally be being made below the board level, and the board only have to resolve disputes where the call is close. "The buck stops here" needs to be true for the board.

It's hard enough to get people to do the grunt work to serve on boards in these projects. You want the right people who are fully invested in that project's success. We have to have some confidence that the electorate will elect sane people: I point to Gnome being sensible enough to *not* elect RMS to its board (he ran several years), and the fact that on the X.org board, we had trouble to get enough good candidates to get some of the people off the board who were *not* serving for the right reasons (in my opinion).

--Jim

Feedback and views:

Ben has identified some very good points about not giving power to those who are seeking it (.. and thus likely to abuse it). However, I agree with Jim that the Board cannot be relegated to do secretarial work. The process of selecting board members should be transparent, and as democratic as possible, but once in place it should be trusted to make substantial decisions - of course with the checks and balances (like the referendum on controversial issues.) I like the point Jim makes about accountability. I think the Board should have some dedicated full time support staff to help with the routine work. Admitted that in such voluntary-community projects paying for services is an issue but at the same time we should not be utilizing high powered resources for something that can be done by a less experienced person who is willing to do it as a job but not exciting enough to volunteer for.

--Tariq

Membership

I think that GNOME's membership criteria that you've borrowed here is a bit lower than I like. In Ubuntu, we use "significant and sustained" which basically boils down to having been around for at least a couple months and being able to get at least 2-3 endorsements from current members that say, "yeah, she's done quite a bit of good work." This is good because it makes membership more likely to be real stakeholders and also creates an incentive to long-term significant contributions.

I also like the idea of automatic expiration each year. If folks can't be bothered to at least reply to an email once a year (you'd be surprised how often this happens in Ubuntu) they probably shouldn't be voting either.

--Mako

I don't mind having tougher criteria for developers, but unlike Gnome, I think we need some way to get participation from users, e.g., classroom teachers in deployments, etc. To me, that is significant and sustained.

--Walter 16:53, 12 June 2008 (UTC)

Absolutely. There are lots of ways of contributing constructively and each should be recognized. I'm suggesting that there should be a common contribution threshold for membership -- whether it's software developers, content producers, teachers, whatever else, or any combination.

--Mako

To be a truly community based and perhaps a good 501c3 NonProfit, it has to serve the public good, and including those community members that are affected (i.e. users of the software, kids, teachers, family members, community members, not just developers), or underserved by the software/ product (those who don't get it, i.e. people without machines that will boot from USB/ CDR, and/or just learning what Sugar and SugarLabs/ OLPC is about), as inclusion makes a better product and better serves the public good.

Danceswithcars 14:24, 5 October 2009 (UTC)

Other open details

• how the governance document is modified; what determines quorum for such actions

through the referendum process

• how decisions are appealed

through the ombundman's office, direct communication to the committee or panel, and through the referendum process

• how notice is given of decisions

Email and posting of minutes in the wiki

• how do we adopt permanent governance regulations; as these currently are, they can at best be temporary until a membership exists and ratifies a more formal governance document...

We need to have a ratification process--Referendum #1

• what to do about removing/recalling members/board members; it is the board that matters most here).
• how vacancies are filled
• limits on board membership by employer
• how money is disbursed.
• how committees dissolve/end when they're no longer needed.

feedback from SFC

Note

Is this requirement too stringent to maintain? Consider making the required meeting frequency lower and say instead: The Oversight Board shall meet at least quarterly/monthly to discuss various topics pertaining to the regular activities of the Sugar Labs Project and Sugar. The Oversight Board expects to meet twice per month.

Seems to make sense. Quarterly is probably a good steady-state to aim for.

Note

Should the oversight board be able review/ratify the decision? The way this section is written now, the people elected by the members are not able to actively participate in the decision-making process. Why not allow the board to participate or at least ratify the final decision?

A ratification process seems reasonable, especially in light of having a mechanism (below) to override the decision.

Note

should the advisory board be allowed to listen in (perhaps but not participate in) the board meetings or otherwise be allowed to elect a representative for participation (voting or nonvoting) in the Oversight Board meetings? Should they have their own schedule/procedure for meetings?

Seems to make sense. And their input would be of value.

Note

as with the advisory committee, should we provide some formal way for the SIGs to provide input? For example, SIGs could have representation on the advisory committee or listen in on board meetings.

Ditto.

Note

is there an officially list already? Who gets to add contributors and are they ever removed? Is the Membership and Election Committee another committee of the Oversight Board without any voting members from the OB?

We need to bootstrap this. It seems a natural place to start is with contributors to Sugar, activity developers, and people active in the wiki and lists.

Note

can the membership override the Oversight Board under certain circumstance? For example, a 75% vote of all of the members?

Seems to go hand-in-hand with the idea of the OB ratification process.