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 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. Sincerely, Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133
