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

[Watson, Sylvia]

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.]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/mailman/private/evergreen-governance-l/attachments/20100827/41068a2c/attachment-0001.htm