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 "" (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 

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


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College

Reply via email to