How to Hack LDCX

LDCX is an annual unconference held at Stanford University every Spring. It brings together some of the world’s leading technologists from the libraries, archives and museums spaces. The three-day event is usually small (fewer than 100 people) and relatively informal. Each year there is a healthy crop of first-time attendees, but the majority of people are those who have attended an LDCX before.

The first-timers often don’t know what to expect, and given both the informal and adaptive nature of the event (not to mention that it’s an unconference), we don’t put a lot of energy into documenting its Ps and Qs. At LDCX 2015, though, the suggestion was made that a write-up similar to Declan Fleming’s “How to Hack Code4Lib” post could be a useful (and low-overhead) way to set expectations for new LDCXers, and maybe even share perspectives among veterans. These points were crowdsourced by the LDCX community in April of 2015. So here goes:

• LDCX is an unconference; while the organizers set certain themes (e.g., archives, discovery, linked data) and attendees tend to share certain assumptions & environments — they come from LAMs, have larger scale repositories, place an emphasis on open source software, may have Hydra/Fedora/Blacklight somewhere in their stacks — any topics pitched by the attendees are welcome. If you think it’s interesting and relevant to the space, chances are pretty good that someone else will too.

• You get out what you put in, and a big reason (the main reason, really) that people come is to learn from and work with each other. If you are coming to be an observer or want to be a fly on the wall through the whole event, this is probably not the right place, or perhaps year, for you. If you have something that you think might be of interest to others, then air it! Lightning talks, session pitches, demos, or breakout groups led by attendees are not just invited, they’re encouraged.  

• Expect a mix of talking, thinking and doing. We try to structure the schedule to promote quick demos and presentations (lightning talks, sessions led by experts on a particular field), analysis (hands-on sessions, more open-ended discussion & exploration especially over meals and evenings) and doing (slinging some code or applying new models to use cases from home). The best events have a mix of all three; if you’re getting more than enough talking but not enough thinking or doing, then it’s welcome and encouraged to excuse yourself (with or without co-conspirators) to break out on a specific topic or begin doing deep-dive work.

• Barring schedule conflicts, LDCX is held the Monday-Wednesday of Stanford’s spring break week. To plan ahead, Stanford’s academic calendar lists spring break dates well into the future: https://studentaffairs.stanford.edu/registrar/calendar-future

• On Thursday and Friday following LDCX, there are often Hydra-related events (such as Hydra Power Steering and/or a Hydra Developer Congress). The Hydra Developer Congress is open to any interested party, and involves two days of heads-down coding and in depth technical work for collaborators on the Hydra Project and related components, such as, but not limited to, Blacklight and Spotlight.

• We rough out a schedule of sessions the first morning; be prepared to suggest topics and “pitch” a session—give a few sentences on what it will cover and desired outcomes.  Once topics are pitched, we determine what should be plenary (of interest to nearly everyone) and what can be multi-tracked, and then the group does its best to come up with a schedule with the minimum number of conflicts for attendees.

• Recognize that some scheduling conflicts will happen—we all have varied interests and passions, and LDCX attendees seem to have more and broader interests than most. You can help the scheduling process by recognizing that 1.) conflicts are always going to happen, 2.) you can’t be everywhere at once, and 3.) a true conflict is between two sessions where you are a major protagonist (facilitator, informant, primary stakeholder) in both--not just a curious participant. Be prepared to compromise on what you want to attend, and count on great notes and report outs to help catch up on action happening in other tracks.

• Sessions tend to be swayed by who is at them, so if you are determined to get specific outcomes, make sure that is clear in your pitch.  Sometimes an intended working session becomes a tutorial; sometimes a discussion splits out to some folks discussing and some developers going heads-down to improve the code.  Sometimes the pitch clarifies that multiple sessions are desired, for different outcomes.

• It’s okay to suggest a session like “Is there someone here who can do an intro to xyz for n00bs?  I need to learn more about xyz.”  You may find other folks who want to learn about xyz, or maybe it will turn into a one-on-one during a break or lunch.

• Make use of the breaks, meals and social times to talk about topics that interest you, especially if you have a session conflict or want to discuss something not on the schedule.  Many an extra topic gets squeezed in this way.  And of course, simply enjoy yourself socializing, too!

• The schedule can be tweaked as we go, since new topics arise and existing topics sometimes have interest fade due to social time discussions or previous sessions.

• Generally, there will be designated places for “breakouts” where you can duck out to write some code, draft a spec, or have a discussion.  Attendees are encouraged to join each other for heads-down work, even when they are working separately.  You are also welcome to seek out a Stanford employee at their desk (e.g. if a developer has “opted out” for some sessions).  Take advantage of opportunities to network with folks in this community, even if you’re only working near each other in a room.

• This is a community built on mutual respect, which means that the code of conduct (http://library.stanford.edu/projects/ldcx/2015-conference/code-conduct) is central to our interactions. If you feel unsafe confronting a disrespectful or harassing situation, know that the hosts and self-identified helpers have your back. There is a procedure for working through problems, and we are committed to helping you.

• It’s about the people and the work.  LDCX builds our community, forging closer relationships among people sharing similar problems and solutions.  You have sucessfully hacked LDCX if:

• you discovered some work being done that is relevant to your work
• you met some colleagues doing relevant work
• ...and you want to keep working with them
• you deepened relationships with colleagues you already know
• you got some help with a problem your institution faces
• a new solution surfaced for addressing your work
• you shared your solution to a problem