[Eg-oversight-board] Thinking strategically: EOB involvement in "future of EG XUL client"?

Tue Sep 3 10:09:08 EDT 2013

Fair warning, this will be long and blunt,

I think we have to carefully think about what we mean by providing
leadership here.  We don't (and absolutely should not) have directorial
authority over the code.  A lot of paths could lead in that direction so I
think we need to abjure that possibility.  At the same time the staff
client itself is a problem.  We can have long arguments about what those
problems are but I don't think anyone disagrees that moving forward we need
some sort of plan.  Unfortunately this is a big problem.  As Jason
Stephenson pointed out his bosses aren't going to put his time onto it.
 And I think it is so big a problem and abstract in the minds of so many of
those resource allocators that it's essentially someone else's problem to
them.

So, it falls to those who are more forward thinkers who want to take care
of themselves to tackle this problem.  So, where are we going and what can
we do?

Well, I'm grateful for the work Kathy has done in getting some consultants
to look at issues and I will be interested in seeing what their report
looks like.  Frankly, I think if we want to do something productive our
best course of action is to look at how we can grease the wheels in
building the road map out.  This I think could be a good project for the
board and the developers to collaborate on but will require someone from
the development community to step up as a leader for and it be someone that
can work with the oversight board if we are going to be relevant in it.  I
say that because while I think the oversight board could be useful I don't
think right now we really are necessary to that process.  Long term one
thing we could do is build mechanisms for gathering input from the larger
Evergreen community and giving that to developers.  I'm currently hoping to
accomplish that with our South East conference to gather input from a large
regional group of Evergreen libraries and be able to report on that. I hope
at the Hack-A-Way that we can have some frank conversations about the pros
and cons of different directions.  That is a way bigger discussion than is
appropriate for this email and also gets into server side considerations.
 Right now this is in the developer's hands and it's up to us to prove
ourselves.  Frankly, the Oversight Board has been a symbolic entity with a
few critical but narrow in scope functions.  This year I've seen us try to
expand that and I think that's great but as a meritocracy we have to prove
ourselves.  So, one possible goal, work at finding ways to gather community
input in meaningful ways for working with developers.  This same mechanism
would provide us with the ability to impress upon people the importance of
work and perhaps lay the ground work for goals I will list below.

So, back to the MASSLNC work: I do worry about developer response.  Because
while MASSLNC is starting to look at analyzing the big picture the issue of
resources is still completely unaddressed.

Frankly, the way things work right now is that a lot of development gets
done because developers either sneak it into their schedule (or do it on
their own time) or they advocate the work to their bosses.  As things stand
right now we need buy in from developers to get any kind of momentum going
and we need to remind ourselves of that.  And ... and I can not over state
this ... on huge projects like replacing the staff client there will have
to be leadership within the existing development community to spearhead it.
 This isn't a quick quid pro quo from someone you did a favor for.  That
works for small patches but not this kind of project.  In fact because of
the scale and complexity of this we're talking about the only way
developers would accomplish this without buy in from their organizations is
to motivate them on a pretty deep level.  Short of one path being mind
blowingly obvious and sexy to every developer and they become obsessed with
it - this isn't going to happen.  Frankly, any path will have detractors.
 In fact this is a problem that causes paralysis.  So, possible goal #2
would be to work with developers to help them find mechanisms to get past
this paralysis, not just on this issue but others.  Frankly, on big issues
I worry that perhaps the release manager or some kind of core committer
team might need greater powers to get past the paralysis that often
happens.  Note, I don't think the oversight board should have this power
but perhaps we can help the developers or at least champion the
conversation in the community.

So, back to resources,

(And I apologize, but I'll pick on Jason S. here since he brought himself
up as an example in email on another list.)

The Oversight Board can stand here and say "I think we need to do X" but
... does that carry weight?  Will Jason Stephenson's bosses say "Oh, well,
the Oversight Board said it so now Jason can work on this eight hours a
week."  In fact, those resource allocators generally pay no attention to
what we say.  If we want them too we have to build the board's brand and
awareness of us a lot more aggressively.  Accomplishing other goals will
help us build that authority but I think we should consider how we present
ourselves.  Would some of it be pomp and circumstance?  Sure, but sometimes
that matters.

Now, what if we want to be able to add resources ourselves whether that is
hiring consultants to look at code bases or having work done directly?  We
need that community feedback mechanisms and we need the resources.
 Resources could either come donated via our authority or by having the
coffers to pay for them / do matching grants.  Those are obviously goals
I've been working forward on.

So, that's a substantial brain dump I suppose but the summary is : we're
toothless in this right now.  If we want to be productive we should work
forward on building our authority, building mechanisms for community
feedback and educating community members, building our coffers and
considering grants.  Directly on this I look forward to seeing the results
of MASSLNC's work but there is a lot more to be done and since no answer
will make everyone happy we need to find a way to get past that logjam in
the development process (not take it over when we're unqualified to do so
as an organizational entity).  If we do build those others things perhaps
we will be in a better place to help the developers when they get to where
they need to be to progress further.

On Thu, Aug 29, 2013 at 1:56 PM, McKinney, Elizabeth <
emckinney at georgialibraries.org> wrote:

> I have not followed the conversation that Yamil referenced.  Is this a
> time-critical issue for the development community?  If not, I would propose
> waiting for the study to conclude and begin discussions. I agree with Kathy
> that proceeding with discussions based on evaluation evidence would be the
> best approach. I also agree with Yamil that the EOB could be instrumental
> in long term strategic decisions.
>
>
> Elizabeth
>
> Elizabeth McKinney
> PINES Program Director
> Georgia Public Library Service
> A Unit of the University System of Georgia
> 1800 Century Place, Suite 150
> Atlanta GA 30345
> 404.235.7141
> emckinney at georgialibraries.org
> http://www.georgialibraries.org/
>
>
>
>
>
> ------------------------------
> *From: *"Kathy Lussier" <klussier at masslnc.org>
> *To: *eg-oversight-board at list.evergreen-ils.org
> *Sent: *Thursday, August 29, 2013 1:07:08 PM
> *Subject: *Re: [Eg-oversight-board] Thinking strategically: EOB
> involvement in "future of EG XUL client"?
>
>
> Hi all,
>
> I do think the Board can provide some leadership on this issue.
>
> One of the reasons MassLNC worked to hire a consultant to do a
> performance evaluation for Evergreen was to help guide the community in
> this decision. During the future of the staff client meeting and a
> previous developers meeting, there were a lot of conflicting opinions on
> the best path forward, and those of us at MassLNC thought an unbiased,
> outside analysis would be helpful in making this decision.
>
> Unfortunately, we have had some delays in the project, not by any
> negligence from the consultant, but due to problems we've encountered
> setting up the test environment. We're seeing the light at the end of
> the tunnel and expect the evaluation to begin shortly, but that still
> leaves another 2 1/2 months before the evaluation is done.
>
> That may be too long for the community to wait before making the
> decision of what the next staff client might be, but I personally would
> feel more comfortable if the decision were based on some kind of
> thorough evaluation that explores the source of the problems that we
> have and what would be the best approach moving forward.
>
> Kathy
>
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative
> (508) 343-0128
> klussier at masslnc.org
> Twitter: http://www.twitter.com/kmlussier
>
> On 8/29/2013 12:36 PM, Yamil Suarez wrote:
> > Hello,
> >
> > Right now someone brought up the topic of the future of the EG XUL
> client on the DEV list[1]. This topic has come up in the past, and I
> thought we could discuss it a bit at the next EOB meeting or just by email.
> I think it could be a situation were the board can try to provide some
> support and/or leadership for this type of long term strategic decision
> that will probably  have to be made. I am not suggesting that the board
> will be the one making the decision, but that we can try to help the
> process along.
> >
> > For the record, my simple understanding of the issue is that the XUL
> client from Mozilla, which serves as the basis of the EG client, will very
> likely stop meeting EG's key needs in the long term. Again, my
> understanding is that the Mozilla XUL client development community's long
> term design decisions will conflict with what the EG software needs to work
> properly. This leaves the EG community with choices like continuing to use
> the versions of XUL client that still work for EG, though at some point we
> will not be able to use a ny new verions of the XL client. The EG community
> might also consider using an alternative design that replaces XUL client
> with something else.
> >
> > Somebody else in the EOB can explain this much better than me, but I
> just wanted to start a conversation within the EOB, because this seems to
> be a situation were someone has to help keep a long term strategic mindset
> in mind.
> >
> > Thanks,
> > Yamil
> >
> >
> > [1] http://georgialibraries.markmail.org/thread/6ltqtlzbk2iq27hj
> > _______________________________________________
> > eg-oversight-board mailing list
> > eg-oversight-board at list.evergreen-ils.org
> >
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board
>
> _______________________________________________
> eg-oversight-board mailing list
> eg-oversight-board at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board
>
>
> _______________________________________________
> eg-oversight-board mailing list
> eg-oversight-board at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/eg-oversight-board/attachments/20130903/b65d6600/attachment.html>