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

Amy Terlaga terlaga at biblio.org
Mon Aug 30 10:05:56 EDT 2010


On this:

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.

 

 

I had the same reaction to this stipulation.  When we were working on the
COSUGI bylaws (the merger of SirsiDynix's two user groups), we were also
interested in broad representation. However, we used phrasing that didn't
make this kind of representation mandatory.  I think we used the word
"preferred."  Since this is all volunteer, if you place too many
restrictions, you run a great risk of not having a slate of candidates.  You
make the job of the nominating committee that much harder.

 

I know this from experience - we had to beat the bushes HARD to drum up
people each year I was involved with this user group's Board.

 

 

 

=======================

Amy Terlaga

Assistant Director, User Services

Bibliomation

32 Crest Road

Middlebury, CT  06762

(203)577-4070 x101

http://www.biblio.org

----

Bibliomation's Open Source blog:

http://biblio-os.blogspot.com/

 

Join us on Facebook:

http://www.facebook.com/group.php?gid=171935276419

  _____  

From: evergreen-governance-l-bounces at list.georgialibraries.org
[mailto:evergreen-governance-l-bounces at list.georgialibraries.org] On Behalf
Of Watson, Sylvia
Sent: Friday, August 27, 2010 5:14 PM
To: 'evergreen-governance-l'
Subject: [Evergreen-governance-l] ***SPAM*** RE: Be sure to do this

 

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/20100830/3e17a5c3/attachment-0001.htm 


More information about the Evergreen-governance-l mailing list