> 2. Governance: One of the challenges that free and open-source > projects face is the impact of governance on their community members: > while FOSS licenses assure access to source code, that doesn't > guarantee a successful project. A governance model can help ensure > that the project is run in a professional, disciplined, and equitable > manner. Good governance lets the community engage in discourse and > provides a transparent mechanism for arbitration in the hopefully rare > circumstances in which it is necessary. > > Some attributes that are necessary for good governance include: > meritocracy, transparency of process, open access to anyone who has > demonstrated the skills to contribute, and a means to ensure a balance > of control so that no one special interest wrests control of either > the discourse or the decision-making. > > A draft proposal for a governance model for Sugar Labs has been posted > to the wiki (Please see > http://wiki.sugarlabs.org/go/SugarLabs:Governance). Community input > and feedback is important: please help us get this done properly. Feel > free to make corrections and comments in the wiki or on the IAEP list. >
In general, I like what I see. I think somewhat more (and somewhat less) specific governance needs to be specified from what I see so far. Not all of these need to be addressed in a temporary working governance document, but do need to be addressed in permanent governance documents, and those need to exist in finite time, and ratified by the membership. Clearly, if we're to go the Software Freedom Conservancy route, some of the legal boilerplate overhead one finds in documents such as the Gnome Foundation bylaws Bylaws are not needed. (http://foundation.gnome.org/about/bylaws.pdf). But some other issues should be covered are not currently in the governance document: for example: o how the governance document is modified; what determines quorum for such actions o how decisions are appealed o how notice is given of decisions o 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.... o what to do about removing/recalling members/board members; it is the board that matters most here). o how vacancies are filled o limits on board membership by employer o how money is disbursed. Again, many of these issues don't matter when things are working well; but if/when disputes arise, having mechanisms for fixing the problem in advance removes much of the heat from the system. Establishing procedures people find transparent and fair in the middle of controversy is very difficult. Some particular critiques: 1) I don't think so many (or maybe any) committees need to be hard-wired in the governance document, particularly at the current size of the project. Instead, I'd recommend making it clear that the oversight board can form committees, and how they can be dissolved. Using the list that exists as examples of what sort of things are envisioned is fine, of course. In Gnome, for example, when I was serving on the board there was no standing community committee; but each conference (organized by different sets of people in different parts of the world) had its own organizing committee that started up before the event, and ran somewhat over; IIRC, the BOD in that case just selected the group holding Guadec and got occasional reports of how the organization of the meeting was proceeding, as part of the BOD oversight role. We found in X.org that getting rid of committees that weren't doing anything was a headache (along with the overhead we had in the bylaws for choosing those committee members). We had an elected technical board which ended up not doing anything; getting rid of it was a headache as it was enshrined in the bylaws, which then had to be amended, which was a PITA. 2) Specifying that meetings be "online" is a mistake; there will likely be times that other sorts of meetings take place of the oversight board, and you don't want to make that impossible. 3) The decision panel mechanism seems cumbersome, and fraught with political danger; if people don't believe the oversight board is being fair, they should get rid of the oversight board. There is the (possible) issue of how to evaluate technical decisions in dispute if the board ends up less technical than many projects (which might in fact be the long term outcome we'd like to see in Sugar). Some mechanism that permits the board to delegate decision authority (or solicit advice) may be useful. It might just be the same committee mechanism, if committees are easy to establish/de-establish. In a (technical) meritocracy, often many of the people *best* able to judge the technical merits of technical controversy end up serving on the board, and I think it a mistake to forbid oversight board members from serving on such committees. In short, while there may be circumstances where such a panel is needed, I suspect as currently proposed, the decision panel being enshrined in governance is a mistake; and we can use the general committee mechanism to handle the cases where it may be needed. - Jim -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
