<div dir="ltr"><div>Fair warning, this will be long and blunt,</div><div><br></div>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.<div>
<br></div><div>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?</div><div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>So, back to resources,</div><div><br></div><div>(And I apologize, but I'll pick on Jason S. here since he brought himself up as an example in email on another list.)</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 29, 2013 at 1:56 PM, McKinney, Elizabeth <span dir="ltr"><<a href="mailto:emckinney@georgialibraries.org" target="_blank">emckinney@georgialibraries.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif">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. <br>
<br><br>Elizabeth<br><br><div><span name="x"></span>Elizabeth McKinney <br>PINES Program Director <br>Georgia Public Library Service <br>A Unit of the University System of Georgia<br>1800 Century Place, Suite 150<br>Atlanta GA 30345<br>
<a href="tel:404.235.7141" value="+14042357141" target="_blank">404.235.7141</a><br><a href="mailto:emckinney@georgialibraries.org" target="_blank">emckinney@georgialibraries.org</a><br><a href="http://www.georgialibraries.org/" target="_blank">http://www.georgialibraries.org/</a><br>
<br><br><br><span name="x"></span><br></div><br><hr><div style="font-size:12pt;font-style:normal;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal"><b>From: </b>"Kathy Lussier" <<a href="mailto:klussier@masslnc.org" target="_blank">klussier@masslnc.org</a>><br>
<b>To: </b><a href="mailto:eg-oversight-board@list.evergreen-ils.org" target="_blank">eg-oversight-board@list.evergreen-ils.org</a><br><b>Sent: </b>Thursday, August 29, 2013 1:07:08 PM<br><b>Subject: </b>Re: [Eg-oversight-board] Thinking strategically: EOB involvement in "future of EG XUL client"?<div>
<div class="h5"><br><br>Hi all,<br><br>I do think the Board can provide some leadership on this issue.<br><br>One of the reasons MassLNC worked to hire a consultant to do a <br>performance evaluation for Evergreen was to help guide the community in <br>
this decision. During the future of the staff client meeting and a <br>previous developers meeting, there were a lot of conflicting opinions on <br>the best path forward, and those of us at MassLNC thought an unbiased, <br>
outside analysis would be helpful in making this decision.<br><br>Unfortunately, we have had some delays in the project, not by any <br>negligence from the consultant, but due to problems we've encountered <br>setting up the test environment. We're seeing the light at the end of <br>
the tunnel and expect the evaluation to begin shortly, but that still <br>leaves another 2 1/2 months before the evaluation is done.<br><br>That may be too long for the community to wait before making the <br>decision of what the next staff client might be, but I personally would <br>
feel more comfortable if the decision were based on some kind of <br>thorough evaluation that explores the source of the problems that we <br>have and what would be the best approach moving forward.<br><br>Kathy<br><br>Kathy Lussier<br>
Project Coordinator<br>Massachusetts Library Network Cooperative<br><a href="tel:%28508%29%20343-0128" value="+15083430128" target="_blank">(508) 343-0128</a><br><a href="mailto:klussier@masslnc.org" target="_blank">klussier@masslnc.org</a><br>
Twitter: <a href="http://www.twitter.com/kmlussier" target="_blank">http://www.twitter.com/kmlussier</a><br><br>On 8/29/2013 12:36 PM, Yamil Suarez wrote:<br>> Hello,<br>><br>> 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.<br>
><br>> 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.<br>
><br>> 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.<br>
><br>> Thanks,<br>> Yamil<br>><br>><br>> [1] <a href="http://georgialibraries.markmail.org/thread/6ltqtlzbk2iq27hj" target="_blank">http://georgialibraries.markmail.org/thread/6ltqtlzbk2iq27hj</a><br>> _______________________________________________<br>
> eg-oversight-board mailing list<br>> <a href="mailto:eg-oversight-board@list.evergreen-ils.org" target="_blank">eg-oversight-board@list.evergreen-ils.org</a><br>> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board</a><br>
<br>_______________________________________________<br>eg-oversight-board mailing list<br><a href="mailto:eg-oversight-board@list.evergreen-ils.org" target="_blank">eg-oversight-board@list.evergreen-ils.org</a><br><a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board</a><br>
</div></div></div><br></div></div><br>_______________________________________________<br>
eg-oversight-board mailing list<br>
<a href="mailto:eg-oversight-board@list.evergreen-ils.org">eg-oversight-board@list.evergreen-ils.org</a><br>
<a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-oversight-board</a><br>
<br></blockquote></div><br></div>