[OPEN-ILS-DEV] Call for nominations for release manager — Evergreen 3.0

[Daniel Wells]

[I apologize for possible duplication; my calvin.edu email is getting
"greylisted" by the mailing list, so I am sending this a second time from
Gmail.]

Dear Evergreen Community,

I am writing to offer myself as release manager for the upcoming 3.0
release.

Our library is an independent academic installation, and having recently
celebrated 7 years on Evergreen, a fairly early adopter.  I served as
release manager for 2.5 and 2.6, release cycles distinguished by virtual
"medals" (which, if I am elected, will certainly be making a comeback), and
stirring lyrical ballads about "2.next" (which certainly will not be).  I
was also the buildmaster and am current release maintainer for 2.11.

If elected, my primary focus will be full support for our express goal of a
fully-featured web client for 3.0.  A particular emphasis will be a
continuation of Kathy's efforts to push for greater consistency of the user
experience while still being ever mindful of the particularities of any
given feature.

My secondary point of emphasis will be on non-functional yet valuable
changes to the codebase, and this falls into two main areas.  First, I
would like to spearhead an effort to trim away dead (or dying) and
deprecated code.  I greatly appreciate recent efforts in this area, but
there is more to be done, and not just the XUL client.  While some things
can be removed outright, another useful strategy will be simply increasing
log messages (e.g. "XYZ is deprecated, consider using ABC instead."), or
even more simple than that, at least adding code comments when a method (or
entire file) has been superseded.  This last idea leads directly to the
second piece of this emphasis, and that is a general increase in code
comments.  In particular, I will seek volunteers to work through the
service code in particular and add, at a minimum, a header explaining
broadly what the contained code is for.

These goals are being informed and inspired by ongoing work here at Calvin
to document and holistically understand Evergreen in preparation for our
conference presentation and beyond.  External and internal documentation
are two separate goals which ultimately will work better when working
together.

I know from experience that an RM has limited ability to spur actual new
developments.  We each must work to scratch our own itches and those of our
institutions, so I will briefly mention here a few areas where I intend to
focus my own development efforts in the next cycle.  First, for too long
I've let a few of our local billing improvements languish, so I will double
my efforts to produce branches for community review.  Second, as one of the
original contributors to the serials module, I intend to offer whatever
help I can in smoothing the transition of those interfaces into the web
staff client.

Thank you for your consideration.

Sincerely,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20170321/f48e45c7/attachment.html>