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
signature.asc
Description: Message signed with OpenPGP using GPGMail
