On Mon, 2008-06-09 at 11:07 -0400, Jim Gettys wrote: > > 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 > Walter, Jim I just looked at some other project's bylaws. The eclipse bylaws(1) cover a lot of the points raised by Jim.
Thanks Dfarning 1 http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10% 20Final.pdf _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar