[Eg-oversight-board] EOB meeting, Thursday, 18 July 2013, 2-3 p.m. EDT

Fri Jul 19 12:06:10 EDT 2013

Hi Stephen,

I've given some thought to points 2 and 3 in your e-mail and would like 
to offer some of my feedback to help kick off this discussion. On 
7/18/2013 1:47 PM, Elfstrand, Stephen F wrote:
>
> 2) I move that the EOB appoint release managers after receiving a 
> recommendation from the developer community
>
> a.This will allow the oversight board some input into the 
> prioritization of activities surrounding a release
>
> i.eg is the documentation for both and installers / upgraders and end 
> users acceptable, Do the upgrade scripts work correctly?
>
> ii.Are the priorities set by the EOB being implemented in the release 
> (ie. are quality & performance issues being addressed)
>

I'm not in favor of an EOB appointment for the release manager for the 
following reasons.

* During the most recent RM-selection process, only one person submitted 
his name as a candidate for the position. I don't see how changing the 
appointing authority would make any perceived improvements to the 
release process when there isn't a large contingent of developers 
chomping at the bit to take on the job.

* The most recent selection process was wide open, allowing input from 
anyone who was willing to post to the Evergreen developer's list or to 
attend the May 1 IRC meeting. My hope is that Oversight Board members 
who feel strongly about release priorities would participate in those 
meetings. Those meetings are open to the entire community. In looking at 
the log from that meeting 
(http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-05-01-13.00.log.html), 
although most of the people who voted for the RM were the core 
committers, I see that others in the community also voted, including me. 
As far as I know, there is nothing that would stop an Oversight Board 
member from also voting or providing input if the same process is 
followed for the next release.

* Galen has started inviting the Release Manager to EOB meetings, and I 
think it would be a good idea for future EOB chairs to continue this 
practice. If an EOB member has a concern about the release process, I 
think this is an excellent opportunity to raise those concerns.

* I'm not sure the RM sure be responsible for making sure that end-user 
documentation is complete in time for the release. Perhaps that should 
fall into my realm as the DIG release coordinator.

However, I would like to point out that, although the documentation is 
still catching up with the features, I think there has been a lot of 
improvement in release-time documentation, especially since Equinox 
started requiring customers to include documentation in their 
development contracts. We have a list of 2.4 features needing 
documentation at 
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.4_needs 
that I just updated by adding a "Complete" label for everything that has 
been contributed to the official doc repository. Sure, we don't have 
everything documented yet, but it's come a long way from the days of 2.0 
where there was little documentation for new features. We could probably 
finish it off in a few weeks with the support of a couple of additional 
contributors who are willing to take on some of the unassigned items. 
Or, we could make a lot of progress in clearing out the backlog if more 
institutions did what Berklee College of Music did by asking college 
interns to upgrade older docs to the new Asciidoc format.

Moving on to your second priority, I think you can get more information 
about quality & performance issues by reading the two most recent blog 
posts at http://blog.esilibrary.com/ or my recent e-mail to the general 
list about the MassLNC-sponsored performance evaluation 
http://markmail.org/message/6yzorevfs6xtnn2u. In other words, many of 
these concerns are already being addressed, not because the RM made it a 
priority, but because the community made it a priority by contributing 
staff time, money, and other resources to make it happen. I'm not saying 
that the EOB shouldn't be involved in pushing these very important 
priorities, but I don't think appointing the release manager is the way 
to make it happen.

* I don't necessarily feel qualified to decide who the best release 
manager is. I have a lot of thoughts on the communication I would like 
to see from a release manager, but there are many things a release 
manager does that I just don't understand. Even with the recommendation 
from the developers, I would be concerned that this change could 
potentially lead to a situation where the EOB appoints somebody who does 
not work well with the developer community, which would lead to a 
dysfunctional release cycle.

In short, I would say there are plenty of opportunities for EOB members 
and other community members to communicate their concerns to the Release 
Manager without taking a step that will probably cause discord in the 
community while yielding very little benefit.

> 3)I move that a membership fee structure be introduced proceed of 
> which would be under the control of the EOB
>
> a.This will allow the EOB to sponsor strategic development even if it 
> doesn't meet immediate needs of current users to meet the challenge 
> posed by "Next Gen" Library systems
>
> b.Better, faster, mobile-friendly OPAC
>
> c.Resouce sharing and NCIP development
>
> d.Improvements to Administration like allowing the customization of 
> facets from the staff client
>
> e.A better reports interface
>
> f.Improvements to the Evergreen web site (what ever happened to the 
> Drupal-based prototype?
>

I agree that the EOB should try to identify and support strategic 
development (not sure I agree that all of the listed projects fall into 
that category), and we need a good way to identify which projects should 
be our focus. I agree that development sponsors by local groups can 
often overlook long-term, strategic goals for the system (I know MassLNC 
can partially fall into the blame camp for that), but I think it's 
incorrect to assume that we never meet strategic goals with some of 
these projects. The recent acquisitions work funded by SC LENDs, SITKA, 
Bibliomation and MassLNC is an example of Evergreen sites coming 
together to work in an area that was a high priority for the community. 
My hope was that we could have gone further with that project to make 
the necessary speed improvements for screen loading time, but, 
unfortunately, we weren't able to get additional partners for that work 
when we sent out plea for help in January. However, acquisitions is 
certainly in a better state than where it was during the 2012 Evergreen 
conference. MVLC is working on NCIP development, so I do see that people 
are making strategic development happen without waiting for a membership 
fee to be assessed.

I have to admit that, at first glance, I don't like the idea of a 
membership fee structure. However, since we are already having 
conversations about fundraising and grant writing, I think it's 
appropriate to have this discussion in the larger community channels. If 
such a discussion were to happen, I hope the following questions are 
addressed:

1. Who is assessed with a membership fee? Is it assessed for every site 
that runs Evergreen or is it a fee that must be paid to be a voting 
member of the community? MassLNC does not run Evergreen, but works with 
three consortia that do run Evergreen, and I would want to make sure 
that those three consortia are not "double charged" by paying their own 
membership fees along with a fee for MassLNC.

2. Is there any kind of credit given to organizations that are already 
contributing heavily to the future of Evergreen? For example, 
organizations that have already allocated thousands of dollars per year 
to develop Evergreen. What about those organizations, like MVLC, that 
have donated hours of staff time to contributing code to the software, 
including that NCIP code that was cited as a strategic development need? 
Do they get credit for all of their code contributions or just the ones 
that meet the definition of strategic? If this membership fee helps to 
support documentation, can we receive credit for the hours we put into 
creating docs?

I don't really want to speak on behalf on my consortia because I haven't 
discussed this issue with them yet. However, if there is a membership 
fee established, I can imagine some of their board members balking at 
the idea of paying an additional fee when they feel like they already 
have made substantial contributions to the project.

3. The above were more practical questions, but here's a philosophical 
question. If we are assessing this membership fee on all sites running 
Evergreen or for those that are voting members of the community, what 
does open source mean in the Evergreen context? Yes, I know the code is 
still open, but I would be concerned about setting a precedent that you 
have to pay to run Evergreen or to be a voting community member. How 
does the membership fee differ from the proprietary licensing fees that 
were theoretically used for improvements decided by the majority will of 
a user group? This model was one that the MassLNC consortia wanted to 
move away from, and I would want to make sure we aren't recreating a 
similar structure in the Evergreen community.

Just my two cents. I would be interested to hear what others think.

Kathy

> Stephen Elfstrand
>
> *From:*eg-oversight-board-bounces at list.evergreen-ils.org 
> [mailto:eg-oversight-board-bounces at list.evergreen-ils.org] *On Behalf 
> Of *Galen Charlton
> *Sent:* Wednesday, July 17, 2013 5:31 PM
> *To:* eg-oversight-board at list.evergreen-ils.org
> *Subject:* [Eg-oversight-board] EOB meeting, Thursday, 18 July 2013, 
> 2-3 p.m. EDT
>
> Hi,
>
> The next Evergreen Oversight Board meeting is scheduled for tomorrow
> from 2 to 3 p.m. EDT and will take place on the #evergreen IRC channel.
>
> The agenda is:
>
> 1. Financial Report (Galen)
> 2. Evergreen 2014 Conference Committee Report (Kathy)
> 3. Follow-up on support company listing
> 4. Grants and fundraising (Rogan)
>
> If there are any other items you wish to add to the agenda, please let 
> me know.
>
>
> Regards,
>
> Galen
> -- 
>
> Galen Charlton
>
> Manager of Implementation
>
> Equinox Software, Inc. / The Open Source Experts
>
> email: gmc at esilibrary.com <mailto:gmc at esilibrary.com>
>
> direct: +1 770-709-5581
>
> cell:   +1 404-984-4366
>
> skype:  gmcharlt
>
> web: http://www.esilibrary.com/
>
> Supporting Koha and Evergreen: http://koha-community.org 
> <http://koha-community.org> & http://evergreen-ils.org 
> <http://evergreen-ils.org>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/eg-oversight-board/attachments/20130719/f262c738/attachment-0001.html>