 |
 |
On Jun 8, 2016, at 1:55 AM, Kyle Banerjee <[log in to unmask]> 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