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

[Lori Bowen Ayre]

I agree with Dan and Galen particularly concerning:

1) eliminating limits on how long someone can serve on the Board
2) expanding the concept of "contribution" such that it isn't limited to
writing code
3) eliminating the Technology Committee (but what about the committees we
have now like DIG and Reports?)
4) agree members should approve members (but perhaps the Oversight Committee
could have a role in the case of an appeal of the membership decision???)
5) agree that membership has to be for individuals because otherwise what
happens when those individuals change affiliations?  Seems like we need
individual members plus institutional members but somehow ensure that an
institution can't pay for a bunch of memberships in order to take over a
vote.

New Questions
1) does it make sense in this day and age that you have to be present to
vote?  seems like it could be  hardship for an international organization.
 Couldn't there be accommodations for absentee ballots?
2) 10% of members have to vote in a "Member requested referenced."   Does
this mean 10% of the people present at any given membership meeting?  or 10%
of all registered members?  Seems potentially low or too high depending how
you interpret it.

Lori Ayre

On Fri, Aug 27, 2010 at 2:17 PM, Watson, Sylvia <sywatson at library.in.gov>wrote:

>  *More from Dan that I forgot to include the first time:*
>
>
>
> Also, on the subject of community members, perhaps we could pursue a
>
> path that offers three kinds of membership. I was thinking that
>
> community membership could be structured something like the following,
>
> with the principle being that our primary goal is to encourage
>
> contributions to the project, while also recognizing the importance of
>
> the organizations that employ the contributors, and offering an
>
> opportunity to have recognized $pon$or$ship of the Foundation (usually
>
> the latter results in organizational logo + link being place in a
>
> "Sponsors" column on the project home page):
>
>
>
> 1) Recognized contributors (committers, significant patch providers like
>
> Dan Wells or perhaps Thomas Berezanksy, documentation writers, bug
>
> wranglers / mailing list supporters like James Fournie, translators)
>
>
>
> 2) Employers of recognized contributors who pay for core contributions
>
> or provide work time for those contributors get one member as a
>
> "contributing organization"
>
>
>
> 3) Sponsors (subject to approval by the membership and/or board similar
>
> to the rules of the Python Software Foundation)
>
>
>
> Members would approve new members on an annual basis; basically, I like
>
> the Sugar Labs model at
>
> http://wiki.sugarlabs.org/go/Sugar_Labs/Members :
>
>
>
> """Any "significant and sustained" contributor to Sugar Labs is eligible
>
> for membership. Although it is difficult to specify a precise
>
> definition, a contributor  generally must have contributed to a
>
> non-trivial improvement of the Sugar project or Sugar Labs activity.
>
> Contributions may be code, documentation, translations, maintenance of
>
> project-wide resources, running a Sugar deployment, or other non-trivial
>
> activities which benefit Sugar Labs. Membership eligibility is an
>
> individual determination: while contributions made in the course of
>
> employment will be considered, they will generally be ascribed to the
>
> individuals involved, rather than accruing to all employees of a
>
> "contributing" corporation."""
>
>
>
>
>
>
>
> *From:* Watson, Sylvia
> *Sent:* Friday, August 27, 2010 5:14 PM
> *To:* 'evergreen-governance-l'
> *Cc:* Dan Scott; 'Galen Charlton'
> *Subject:* RE: [Evergreen-governance-l] 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.]*
>
> * *
>
> _______________________________________________
> Evergreen-governance-l mailing list
> Evergreen-governance-l at list.georgialibraries.org
> http://list.georgialibraries.org/mailman/listinfo/evergreen-governance-l
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/mailman/private/evergreen-governance-l/attachments/20100827/151b6d33/attachment.htm