<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>I thought it might be useful to provide my suggestions for the Evergreen conference and changes we may want to consider for the future.  Apologies in advance if this is either rambling or redundant, or both.<br><br></div>The conference operates on thin margins.<br></div>Every year the conference committee is confident (perhaps overly confident) that this year they will increase attendance numbers and increase sponsorships.  The problem is that we can't increase our sponsorships without increasing our attendance.  And our attendees who increase our numbers are generally just employees of a library in an existing consortia.  This exact complaint was brought up by multiple vendors - essentially, the Evergreen conference is really only between 8 and 10 "clients" and having more circ or cataloging staff attendees at the conference doesn't increase their ROI.  And that's fair. <br></div><br></div>And the attendees who can increase our numbers (local staff) seem to want very specifically targeted information related to them at the conference.  The conference surveys have been pretty clear that end-user staff want and expect *training* from the conference.  But that hasn't traditionally been the aim of the conference, nor can we reliably provide that since the programs are solicited from volunteers in the community. Also complicating things for "training" on Evergreen features is that Evergreen is so customizable that "training" or explanations of how to use certain features may not jive with local policy for their consortia or library system. Regardless, I believe we can, to some extent, provide that kind of training in the pre-conference sessions.  However, we will need to be very selective in the process of recruiting the pre-conference presenters (trainers) if we're going to try to actively meet that need.<br><br></div>Also, I firmly believe that the conference should make money for the project.  With that money, the project can provide outreach, build infrastructure, and promote the community.  We want to provide a good conference with stellar programs and a welcoming environment.  But the conference is also for building relationships, allowing developers and community leaders to conduct business and brainstorm, as well as providing space for the EOB, committees, and interest groups to meet.  IOW, we're trying to meet a lot of needs and there needs to be balance - we can't make everyone happy all the time.  If you look at the breakdown of attendees, systems administrators and developers are roughly 1/3, end-users are roughly 1/3, and admin/consortia leaders are roughly 1/3.  Those are all stakeholders that are important but their needs are very different.<br></div><br></div>To reduce overhead for the conference and to try to give <u>everyone</u> the best experience we should at least look at making some changes. Based off of my experience and the results of conference surveys, I have some suggestions for changes to the structure and the sponsorships.  <br>Note that the proposed reduction of the conference to two tracks had wide support in the survey and the track reduction and changes to pre-conferences and when/where IGs, etc. meet, should reduce the overhead for costs associated with meeting rooms, A/V, signage, labor, etc.<br>See attached doc for details.<br></div></div></div><div><div><div><div><div><div><div><div><div><div><div><div><br></div><div>Thanks for sticking with the rambling...<br></div><div>And as always, this is just a suggestion based on my experience - I leave it to y'all to decide what to take away from the information and what direction to go.<br><br></div><div>Cheers!<br></div><div>Grace<br></div><div>p.s. Exhibitor and attendee surveys also attached.  For anyone who prefers visual representations, just let me know and I can share the Google form with you.<br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div>