[Evergreen-governance-l] Rules of Governance

[Dan Scott]

Hi Steve:

On Sun, 2010-08-29 at 12:49 -0400, Steve Wills wrote:
> ________________________________________
> 
> 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 sure, but let's not try and write such a committee into the by-laws.
If there's a problem with assisting developers on the ground, let's
tackle it outside of the governance model.

> 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?   
> 


I think so:

http://evergreen-ils.org

Click "Documentation"
Click "How to participate in development"

This is a living document, and probably needs to be updated in places.
But it's not a particularly new document; an older version lived
directly on the Web site, and was converted to a wiki document to help
keep it up to date. (For example, referencing the IRC channel from here
would be a good idea; perhaps assuming that the "Chat" link from the top
of the Web site would guide would-be developers to the Evergreen IRC
channel is too much).

> 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?

It is actually a huge problem if a new developer can get code into core
_without_ "the long tooth's" looking at it. That developer should be
able to set up an ILS-Contrib subdirectory or create a bzr or hg or git
branch of core and keep their changes in sync until the change has been
reviewed and committed to core, if time is a major concern.

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

Hopefully they don't go to a particular person, because then you have a
great bottleneck effect. Give the community a chance to respond to
questions, rather than relying on an individual; that's one way to grow
a community.

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

I don't recall the context, but it was probably me that told you to go
to the PostgreSQL community. There are actually many places to turn in
that case: the #postgresql IRC channel on Freenode (just a /join away
from #evergreen); the PostgreSQL documentation; the PostgreSQL mailing
lists.