Hi all,

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:

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.

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.

Kathy Lussier

On 10/17/2016 09:57 AM, Galen Charlton wrote:

It is fast approaching time to elect the Release Manager for the next
Evergreen release.

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
open-ils-general@list.georgialibraries.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.



Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
Twitter: http://www.twitter.com/kmlussier

Reply via email to