I would like to submit my name for consideration to be Release Manager
for Evergreen 2.next. I have worked in the Evergreen community for more
than six years, contributing both code and documentation to the project
and reviewing contributions made by others. I have also been active in
developer meetings and helped organize Bug Squashing Days. Through my
involvement, I have a good handle on the planning, communication and
organization required for a smooth release process.
I have one primary goal for the next release: getting the browser-based
client closer to a finished state so that more libraries are able to run
it in a production environment. During next week's hack-a-way, we have
an agenda item to discuss a path to completion and a release of 3.0 in
2017. Regardless of whether this discussion leads to a 3.0 release in
March or not, I think focusing on a few key areas can put us in a
position where more libraries will be able to start using the web
client with the next release.
Reaching this goal will require the help and participation of all
contributors to the project, not just developers, but also DIG members,
testers and those who are experts in the Evergreen application. Here are
some of the areas I would like to focus on over the next few months:
ADDRESSING KNOWN BUGS
Despite the extensive amount of testing and bug fixing that has occurred
as each sprint has been completed, continued testing has turned up more
bugs in the web client, something that is to be expected with a project
this large. Although some of these bugs are small, others may be
blockers for libraries to start using the new client. Over the past few
weeks, there has been a lot of activity in fixing the bugs, but it would
be great if we could get more involvement from the developer community
to work on them. We are likely to learn of more bugs once libraries use
the web client in production, and clearing out the known ones now will
help the process go a little more smoothly.
To help us focus on these bugs, I would like to follow up on a
suggestion I think first came from Galen and Mike to schedule web client
hacking days in the community. Ideally, some of the developers who have
worked extensively on the web client would be available to answer
questions on those days, but I think the real benefit lies in setting
aside the time where code contributors can focus on working on those bugs.
ADDRESSING LOW-HANGING UI AND CONSISTENCY ISSUES
Another area I would like to focus on is addressing UI and consistency
issues in web client. This work could include:
- identifying inconsistent language in the new client and then providing
more consistency in these areas.
- in web client grids, ensuring that default column picker options
reflect the data staff most often need to see.
- identifying and improving other low-hanging usability issues
Web client hacking days don't just need to be for code contributors. As
we get closer to a full web client release, fully documenting the new
interfaces is becoming more critical.
I welcome any other ideas you all may have for getting the web client
ready for our Evergreen libraries!
Thank you for your consideration.
On 10/17/2016 09:57 AM, Galen Charlton wrote:
It is fast approaching time to elect the Release Manager for the next
The Release Manager does not have to be a core committer, but does
need to be familiar with Git and have already contributed
substantially to the Evergreen project whether it be code or
Nominations (including self-nominations) are due by 11:59 PM EDT on
Friday, 28 October. Nominations should be made by email to
open-ils-...@list.georgialibraries.org with a Cc: to
firstname.lastname@example.org. Replying to all on this
email will also work.
Nominees should send an email to both of the above mailing lists a
statement about their relationship to the Evergreen community and
their goals for the next release. The elected release manager will be
expected to adhere to the established schedule for the release
The election will be held in the Evergreen IRC channel on freenode.net
during the week of October 31st (i.e., the week of the Evergreen
Hack-a-way). Later this week, I will circulate a poll for setting the
specific date and time.
Everyone is invited to participate in the voting. Evergreen core
committers who cannot make the meeting may submit their vote via email
to the open-ils-dev mailing list.
As a side note, during the Hack-a-way we will discuss the results of
the experiment with the buildmaster position during the 2.11 cycle; if
we decide to continue with it, we'll likely select buildmasters for
the next release during the Hack-a-way or shortly thereafter.
Massachusetts Library Network Cooperative