[OPEN-ILS-DEV] Clarification, and hopefully, a way forward

[Mike Rylander]

On 12/18/06, Nathan Eady <eady at galion.lib.oh.us> wrote:
[snip]
>
> So it would probably be beneficial to have a clear statement in
> a visible location about how the process works, so that people
> know where things stand.
>

Nathan, you've read the mind collective mind of the PINES team (and, I
suspect, the majority of the rest of the members of this mailing
list).  Jonathan also made some very salient points, and we are
working hard here to address them.  While I can't say I agree entirely
with Jonathan's assessment, I can certainly see, looking over the
entire thread, that his conclusions are logical, and may very well be
shared by many others on the list.

Over the last three days I've been drafting, with the expert
assistance of Bill, Jason and Brad, what we think is a process by
which we can begin expanding the scope of this fledgling community,
and being integrating more contributions, major and minor.

We are firm believers in the open source process, and we think we have
found a way to balance the interests of potential contributors and the
need to keep a stable and sustainable long term community with the
needs of PINES, who are still the only major funding source of work on
Evergreen (though even that is starting to change, with the Windsor
announcement -- YAY! -- and LibLime's commitment to the success of
Evergreen).  We want this to be as orderly a progression as possible,
and we want to give everyone the opportunity to in any way they feel
they can.

It is now obvious to us that we haven't clearly explained how things
work today internally, at least not publicly.  Those of you that have
spoken to us directly may (or may not...) understand it a bit better,
but we must be more direct, I think.

>From the beginning, the development team has worked as a whole.  Our
goal is always consensus, and we work together to make sure that we
all understand the implications of any changes or additions.  We find
that we do less rewriting this way, and there is far less duplication
of code when we all have input on big pieces.  Not only that, but we
generally come out of our design discussions with a far better plan
than the original proposal.  Some points that we always make a point
to consider during these discussions:

  * roadmap relative importance of the feature ("can we leverage other
planned development, or is this not as important as other planned
features?")

 * qualitative and quantitative match with the existing code and
feature set ("is it already there in some way?")

 * a clear, generalized implementation plan ("here's a way we can do X
_and_ leverage the work to implement Y in the future")

 * analysis of the overall effect (positive and negative) of other
functional areas that the implementation could potentially cause
("this will make A and B faster, but C will be slower")

We believe we have found, based on empirical evidence (Evergreen is
live at GPLS, and got to that point on schedule with a reduced
development staff), a very good process for steady, stable and
relatively rapid development.  We also believe that this process can
be extended, through minor formalization, directly to the wider
community.  The key to this is simple:  Technical communication and
discussion, and tons of it.  Quality progress is much more important
to the success of Evergreen that is quantity, however, we believe that
quantity can follow with quality.  With a solid, generalized,
adaptable infrastructure you have the opportunity for a large quantity
of services to be developed.

And so, in an effort to bring our working process to the community and
a hope that it is acceptable to all, we have drafted a set of
procedures and conventions for use by non-core contributors based on a
formalization of how we work.  Because of the size, breadth and
complexity of the existing code base, we do feel there is a
distinction between new, non-core developers and the more senior core
development team members, though we hope that this gap closes over
time for those who want to dive in.  The amount of time, in my
opinion, is entirely up to the new community member -- they will show
the rest of the community, by their contributions, that they are a
leader in the Evergreen world -- and I hope many reading this will do
just that and dive in!

Let me say also that it's very exciting to us to have such sudden and
impassioned interest.  We weren't expecting such a quick uptake to be
honest.  It is a little jarring, but also very heartening, to see such
investment in the project, as surely many on this list are ...
otherwise you all would have left long ago.  ;)

Thank you all for your attention so far.  Below you will find linked
the draft of which I spoke.  Here's fair warning:  it is very explicit
about the procedures we would like to implement, as well as giving
explanations for each point.  This is not meant to insult any one's
intelligence, or to sound condescending in the least.  We just don't
want to leave anything up in the air -- I want to be very clear about
everything so that there are no misunderstandings.

This document is based directly on my experience in the Postgres
development community, and while they are currently larger than us
(but not by much), we are shaped basically the same as them.  There
are seven core developers who have commit privileges, all of which
work full time on Postgres proper, and about 50 active participants at
many levels and in many areas who submit patches and documentation.
Evergreen has (currently, and what we hope to expand from) three full
time developers and nearly a dozen contributors over the last year or
so.

But more than our similarly shaped communities, both projects have at
their heart a common goal:  to create the highest quality, most
robust, most featureful enterprise grade product possible through
community design and development.  It is that which we want to emulate
more than anything, and the key to the success of Postgres has always
been, in my experience, their unwavering demand for thorough technical
discussion before implementation, their ever-present long term vision,
and their requirement of front-line code quality assurance through
peer review.  I think we can make those qualities, all positive in my
humble opinion, work for us as well.

I invite everyone to read, digest and comment on this document, and
all suggestions are welcome and encouraged.  Thanks again, and please
stick with us as we all figure this stuff out!

  http://open-ils.org/documentation/contributing.html

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org