[Evergreen-governance-l] Rules of Governance

[Steve Wills]

________________________________________

On Behalf Of Corridan, Jim (ICPR) [jcorridan at icpr.IN.gov]

Governance Committee -

Thank you Sylvia for the tremendous time and effort you and the committee (Dan and Galen) have put in to preparing the draft governing rules.

I am not quite clear what role Dan and Galen see for the Foundation.  I have thought one of the roles of the Foundation was to be the code committing entity.  If there is no Technology Committee, will the Board make those decisions?  Will that necessitate the Board being composed mostly of developers?  Should the foundation be more than a code committing entity? (and I hope it will be much more).  Will it coordinate communications, conference, fundraising. and notify all of us of development efforts?

--------
I add to the thanks for Sylvia, Dan and Galen.

Dan points out that:

1. Technology Committee "responsible for reviewing and recommending
updates, changes, and patches to the Evergreen code" would in one stroke
alienate the existing developer base.

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

Stev3 suggests: 

Perhaps the above definition of a Tech-Comm charter is hobbling to the existing milieu, 
but is there anything that an organized technology committee could do in a support role to assist 
the individual developers on the ground that is not currently being done?

For instance, is there anyway a new developer knows to go into IRC and shout 
"hey guys, anyone mind if I take issue #1135?  no? cool! On it."  unless they lurk in IRC for a while?   

If they happen to be brave enough to grab issue #1135 and solve it, how do they get it back to core 
without being told by the long tooth's that they will have to look at it to see if it's worthy and get back 
to the programmer, who is under pressure by his managers to move on to other projects?

Along the way, how do they know who is the best "go to" person for a particular branch of the system? 
i.e. XUL v. OpenSRF v. PostgreSQL etc.

And speaking of PostgreSQL, during this past year, I have been told in IRC that a PostgreSQL tuning 
problem was not an Evergreen problem and I should go to the PostgreSQL community in order to solve 
that problem.  Having no where to turn, I forced my way through the problem as if it was the first time 
anyone had ever seen it.

These are the kinds of things a "Developers & Contributors Support Committee" could help solve.  
Perhaps it is a sub-committee of communications and without the power to lock-up the repository.  

Perhaps one of it's functions is to act as an administrative assisting body to developers and contributors 
so that the programmers on the ground have a place to shunt the n00bs without losing their development stride?
It should be important to us not to "shut down" the potential new contributor.

Another function might be to help non-hacker managers understand why they should support the efforts of 
their hard core programmers in contributing to the community even if the institution's revenue model isn't clear.

Another function might be to help individuals and institutions assess their talent against community needs and "hook-up" 
technicians with projects at appropriate skill levels.  Now if you are a C++, PERL, Python or Java strong programmer, you have to 
blunder your way around until you find the section of Evergreen that you can understand without learning a new language
and begin to poke.  Again this is unless you are actively involved in a deployment, you have a very understanding boss, or no life.

 Contributors sometimes dabble and then give up in any community but without organized support we'll shed 
talent we can't afford to lose.  There is a need for this kind of support to be organized in the community in the 
interests of fostering a stronger contributor base that doesn't die out when their grants do.