[Evergreen-governance-l] ***SPAM*** RE: Be sure to do this

[Watson, Sylvia]

Dan and Galen,

Please let me know if you didn't get this e-mail through the group list serve as well as personally.  I have had difficulty sending e-mails to the group as a whole in the past.

Governance group:

Attached is the first draft of the proposed Governance Rules.  I solicited comments from Dan and Galen, some of which have already been incorporated.  The following comments that I have pasted into this e-mail are the comments that warrant further discussion.
Thanks,
Sylvia Watson
Indiana State Library


Dan's comments:


Dan was concerned about the way membership is set up:



"... that's very different from the contribution/meritocracy-driven

approach taken by other software foundations, like:

  * the Apache Software Foundation (see paragraph 2 of

http://www.apache.org/foundation/ ),

  * Sugar Labs (see "Sugar Labs Membership" on

http://wiki.sugarlabs.org/go/Sugar_Labs/Governance ),

  * Python Software Foundation (http://www.python.org/psf/membership/ )

  * Django Software Foundation (see "How can I join the DSF?" at

http://www.djangoproject.com/foundation/faq/ - although I suspect

there's some attempt to prevent too many members from being able to

join)"



[board](Composition)



a) The software world moves quickly, and during the first years of the

Foundation I would suggest that elections be held annually. Particularly

if there's a meritocracy component to becoming an Evergreen Member; it

becomes an incentive to contribute to the project. In all likelihood,

Board Members will be re-elected unless they've been negligent or doing

a bad job, in which case we want them turfed (politely) at the next

opportunity. I fear that stretching the term to two years increases the

chance that it won't be possible to do that politely.



d) Can one Board Member represent more than one of the categories? For

example, if I was to serve as a board member I could satisfy four

categories:



  * academic library

  * library that is a member of an Evergreen consortium

  * library that is located outside of the States

  * vendor



I understand that there is a desire to have broad representation on the

board, but I worry that having categories and limits might be overly

complex (for example: would board members have to be nominated to

represent just one of those categories?) and for not necessarily much

gain, if the Evergreen Members are the ones determining who shall make

up the board.



[This isn't really an issue because the Nominations and Membership development Committee reviews the candidates and recommends a ballot on which there would be broad representation.  However, it is an issue if people don't like that the Nominations and Membership Development Committee will be selecting the default group of candidates.  It is provided that others can run against the slate from the floor.]


[board] (Term)



I'm not sure why there is a cap on serving as a Board Member. Again, an

effective membership should be able to vote out Board Members who are

doing a bad job, and if a Board Member is doing a good or great job in a

more-or-less thankless position, why wouldn't we want to be able to keep

re-electing that person to that position?




Standing Committees



i) I would strike the Technology Committee from the list, particularly

if the membership is institution-based and not individual-based, but

even if the membership was entirely contribution/meritocracy-driven. The

forum for development of code must not be left up to a committee, or

we're dead. If the developers are not openly communicating with each

other and working out the best technical solutions on a day-to-day

basis, we're dead. I would go so far as to say that setting up a

Technology Committee "responsible for reviewing and recommending

updates, changes, and patches to the Evergreen code" would in one stroke

alienate the existing developer base.


I'm still conflicted about institutional vs. individual membership, and

still not sure how to resolve it. Obviously KCLS has contributed

massively in terms of providing funds for Evergreen development - but

then both Jason Stephenson and Thomas Berezanksy from MVLC step up and

contribute some significant patches to Evergreen. I want to encourage

both kinds of contributions to the community, but doing it strictly at

the institutional level with a single member rep per institution doesn't

seem to capture or encourage the significance of individual

contributions to the project.



I also worry about the Oversight Board being the only ones who can

approve memberships. Shouldn't the members themselves be the ones who

approve members? Perhaps, given that members have the power to revoke

membership, they should have the reciprocal ability to grant membership.

And then the Board would just be a means of expediting membership

application, rather than having unique powers.


Galen's comments:


I share many of Dan's concerns, and won't repeat all of them here.  I agree with him membership should be primarily individual, but obviously we will need to balance that with the the fact that users of Evergreen are primarily institutions.  If we follow the Sugar Labs model, which counts running a Sugar deployment as a significant contribution, we could extend the metaphor so that any library running Evergreen in production would be able to name a member.  I would consider libraries whose Evergreen installation is hosted by somebody else to count under that model, i.e., they would also be eligible to name a member.


1.2 - I can see the foundation having a legitimate role as *an* aggregation point for funding, but I do not think that it should contemplate setting itself up as a the *only* centralization point. [this concern has already been addressed, but it is necessary to include the comment so that the following comment can be read in context]



What I would suggest as an alternative is that the foundation consider using its fund-raising ability to certain kinds of contribution tasks that are necessary but can often end up in the background, such as testing, user interface design and usability testing, accessibility design, and translations.



I strongly agree with Dan that a technology committee should not be included at this time, at least as currently described.  That is not the say that there are not issues of concern regarding how development happens in Evergreen, but the developers who are actively contributing need to be able to work and experiment freely and openly.  To the extent that changes are needed, in the short term they are mostly about increasing transparency and communication; a committee which would inevitably be perceived as being imposed upon the developers would not facilitate that.



[Galen also commented that he wanted to ensure that membership applications will be evaluated more frequently than annually.  This will occur under the current set-up for admitting members, but could change if we have the membership vote on membership applications.]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/mailman/private/evergreen-governance-l/attachments/20100827/79ed52c4/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ESF Governance Rules 8.27.2010.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 46358 bytes
Desc: ESF Governance Rules 8.27.2010.docx
Url : http://list.georgialibraries.org/mailman/private/evergreen-governance-l/attachments/20100827/79ed52c4/attachment-0001.bin