Since we're brainstorming...

In addition to regional meetings, how about having some smaller, national or 
even international thematic Code4Lib meetings. For example, I see an aching 
need for a "Code4Lib:Privacy".


Eric Hellman
President, Free Ebook Foundation
Founder, Unglue.it https://unglue.it/
https://go-to-hellman.blogspot.com/
twitter: @gluejar

> On Jun 8, 2016, at 6:40 AM, Eric Lease Morgan <emor...@nd.edu> wrote:
> 
> On Jun 8, 2016, at 1:55 AM, Kyle Banerjee <kyle.baner...@gmail.com> wrote:
> 
>> My recollection is that in the bad 'ol days, c4l was much more about sharing 
>> ideas to solve practical problems… Nowadays, the conference (which has 
>> become like other library conferences) has become an end in itself…
> 
> 
> In the spirit of open source software and open access publishing, I suggest 
> we earnestly try to practice DIY — do it yourself -- before other types of 
> formalization be put into place.
> 
> I was struck by Kyle’s statement, “the conference has become an end in 
> itself”, and the more I think about it, the more I think this has become 
> true. The problem to solve is not identifying a fiduciary for the annual 
> conference. The problems to solve surround communication and sharing. A 
> (large) annual conference is not the answer to these problems, but rather it 
> is one possible answer.
> 
> Unless somebody steps up to the plate, then I suggest we forego the annual 
> meeting and try a more DIY approach for a limited period of time, say two or 
> three years. More specifically, I suggest more time & earnest effort be spent 
> on local or regional meetings. Hosting a local/regional meeting is not 
> difficult and relatively inexpensive. Here’s how:
> 
>  1) Identify one or two regional leaders - These are people who will 
> initialize and coordinate events. They find & recruit other people to 
> participate. Sure, they require “spare cycles", but they do not have to keep 
> this responsibility past a single event.
> 
>  2) Create/maintain a Web presence - This is a Web page and/or a mailing 
> list. These tools will be communication conduits. Keep the Web page 
> up-to-date on the status of the event. Refer to it in almost every email 
> message. Use it to record what will happen as well as what did happen. The 
> mailing list can start out as someone’s address book, but it can grow to an 
> mail alias on a Linux machine or even a Google Group. The Web page can live 
> in the Code4Lib wiki.
> 
>  3) Communicate - Kind of like voting in Chicago, “Talk early. Talk often.” 
> This is essential, and can hardly be done too much. People delete email. 
> People don’t plan ahead. People think they are not available, then at the 
> last minute they are. The reverse happens too. Send communications about your 
> event often, very often. Use email to build a local/regional community. Share 
> with them your intention as early as Step #1. Keep people informed.
> 
>  4) Identify a venue — Find a place to have the event. Colleges, 
> universities, and municipal libraries are good choices. Ideally they should 
> be associated with the output of Step #1. The meeting space has to 
> accommodate fifty people (more or less), but bigger is not necessarily 
> better. The space can be an auditorium, a meeting room, many meeting rooms, 
> or any combination. The space requires excellent network connectivity. A 
> meeting space sans strong wi-fi is detrimental.
> 
>  5) Identify a time - The meeting itself needs to be at least one afternoon 
> long. A day is good. More than two full days becomes a bit difficult. 
> Starting at times like noon allows people to have traveling time, or for 
> folks who arrived the night before time to get oriented. Starting at nine and 
> ending at 5 makes for a nice full day. Ending the meeting around noon makes 
> it easy for people to travel back home. Host the event on a weekday and maybe 
> ending on a Saturday. This is professional work, and it may be fun & 
> interesting, but it should not require vacation leave.†
> 
>  6) Outline an agenda - The agenda embodies "la raison d’être”. The agenda is 
> a tool for facilitating the communication and sharing. Put it on the Web 
> page. Allow others to fill it in. Outline show & tell sessions of various 
> lengths. Recruit people who you know are doing interesting things. Be 
> prepared to show one or two things from the local institution. Do show & tell 
> on things other than computers in libraries. Give tours of local cool stuff, 
> like an archive, special collection, museum, maker space, or even churches. 
> These tours are less about the showing of the stuff as they are about 
> enabling communication of the attendees. Do you really think people are not 
> going to talk work while gazing at a painting? Identify concrete (library) 
> problems to solve, and these form the basis of hack sessions. Do the 
> “unconference” thing. Take hints from THATCamps. Do roundtable discussions 
> and have reporting back sessions. Bring in people outside computing but 
> inside the hosting community, and learning by everybody will take place.
> 
>  7) Identify how to eat - Going to one more more restaurants/bars for lunch 
> or in the evening is a very good thing. When it comes to lunch, people can go 
> out on their own, or the hosting institution may want to sponsor. Cookies and 
> snacks during the day are good things, but not necessary. Shy away from 
> caterers. They are expensive. Take the same money, go to the grocery store, 
> and buy things to eat. Make reservations in restaurants for larger groups.
> 
>  8) Do the event - On the day of the event, make sure you have name tags, 
> lists of attendees, and logistical instructions such as connecting to the 
> wi-fi. Have volunteers who want to help greet attendees, organize eating 
> events, or lead tours. That is easy. Libraries are full of “service-oriented 
> people”. Use the agenda as an outline, not a rule book. Smile. Breath. Have 
> fun. Play host to a party. Understand the problem you are trying to solve — 
> communication & sharing. Let it flow. Don’t constantly ask yourself, “What 
> if…” because if you do, then I’m going to ask you, “What are you going to do 
> if a cow comes into the library?” and I’m going to expect an answer.
> 
>  9) Record the event - Have people take notes on the sessions, and then hope 
> they write up their notes for later publishing. Video streaming is expensive 
> and over the top. Gather up people’s presentation materials and republish 
> them.
> 
> 10) End the event - Graciously say good-bye, clean up, and rest. Put the 
> coordination on your vita and as a part of your annual review.
> 
> 11) Evaluate - Follow-up with the people who attended. Ask them what they 
> thought worked well and didn’t work well. Record this feedback on the Web 
> page. This is all a part of the communication process.
> 
> 12) Repeat - Go to Step #1 because this is a never-ending process.
> 
> Now let’s talk about attendee costs. A national meeting almost always 
> requires airfare, so we are talking at least a couple hundred dollars. Then 
> there is the stay in the “cool” hotel which is at least another hundred 
> dollars per night. Taxi fare. Meals. Registration. Etc. Seriously, how much 
> are you going to spend? Think about spending that same amount of money more 
> directly for the local/regional meeting. If you really wanted to, coordinate 
> with your colleagues and sponsor a caterer. Carpool with your colleagues to 
> the event. Coordinate with your colleagues and sponsor a tour. Coordinate 
> with your colleagues and sponsor video streaming. In the end, I’m positive 
> everybody will spend less money.
> 
> What do you get? In the end you get a whole lot of professional networking 
> with a relatively small group of people. And since they are regional, you 
> will continue relationships with them. Want to network with people outside 
> your region? No problem. Look on the Code4Lib wiki, see what's playing next, 
> and attend the meeting.
> 
> Instead of centralization — like older mainframe types of computing — I 
> suggest we embrace the ideas of de-centralization a la the Internet and 
> TCP/IP. This way, there is no central thing to break, and everything will 
> just find another path to get to where it is going. Instead of one large 
> system — let’s call it the integrated library system — let’s employ the Unix 
> Way and have lots of tools that do one thing and one thing well. When 
> smaller, lesser expensive scholarly journal publishers get tired and find the 
> burden to cumbersome, what do they do? They associate themselves with a sort 
> of fiduciary who takes on financial responsibilities as well as provides a 
> bit of safety. And then what happens to those publications? Hmmm… Can anybody 
> say, “Serials pricing crisis?”
> 
> Let’s forgo identifying a fiduciary for a while. What will they facilitate? 
> The funding of a large meeting space in a “fancy” hotel? Is that really 
> necessary when the same communication & sharing can be done on a smaller, 
> lesser expensive, and more intimate scale? DIY.
> 
> † Here’s a really tricky idea. Do what the TEI people do. Identify a time and 
> place where many similar people are having a meeting, and then sponsor a 
> Code4Lib-specific event on either end of the first meeting. NASIG? DLF? ACRL? 
> Call it a symbiotic relationship.
> 
> —
> Eric Lease Morgan

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to