[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