Tag: keynote

Code4lib Day 3: Keynote #2 Lazy Consensus

by Bethany Nowviskie, University of Virginia

She began by expressing that it is great to have a speaker from the inside the community and lots of thanks to the invitation to talk. Then continued to talk a bit about her background and where she is coming from, including Blacklight and Hydra. She is now in the library world, where she was introduced to many issues such as open access, class issues.

Lazy Consensus

Frequently, lazy consensus gets formalized, such as in committees. When a decision needs to be made, a proposal is put forward. Some might agree, but the default answer is yes. If there are objections, then you go back, but usually just some adjustments. In order to object, people need to take the time to think and take the effort.

Some might think that there are fortunes for the bold. However, with this social contract where  we already agree that if you don’t say yes or no, “we’re not waiting on you,” inertia can work with you or against you.

Chaotic Good

Your team should work in lazy consensus. Use it to do what you know is right. How do you know what’s right? Make sure you’re one of the good guys. Act and speak up when you need to.

Ideal Conditions

  • skunkworks / R&D operations – trust them to have a plan
  • developer-driven 20% time
  • rabble-rouse… in disguise – organize smartly to fit in
  • knowing your enemies (trends, not people) – extract personalities, because usually fighting bad trends, not people
  • finding your friends (people, not just trends) – check data preservation, open access, digital humanities people

Your (Ethical) Obligations

  • always share information freely – it will fail otherwise
  • never shut out the public services and user experience
  • practice what you’d teach – think mentoring a promising novice
  • if you screw up, confess
  • try not to screw up in the first place

In Applying

If you have a bad technical plan, the library administration might not notice whether you implement it to the letter. They probably care more about the spirit than the letter of it. However, do genuinely try to explain to all levels of the organization.

Never do it alone. The word consensus is in there for a reason. You need enough people who agree on the direction to take that can be implemented reasonably and sustainably.

Keep talking to people.

Produce

If you produce, administration will have your back, but then you need to deliver a product that will make everyone look good, even the dead weights.

Involvement

The library is not involved enough in larger issues at the university, national, or government level. One common example is the research that is produced, peer-reviewed, and then sold back to the university at exorbitant prices.

It’s up to you to make contact with the leadership level of the organization. If you have a problem, put it on the agenda. Make the first move.

Shift Needed

There should a bias toward action. Stagnation is a far, far greater danger than taking measured risks.

Drive it like you stole it.

Q & A Comments

Does this reflect reality? Sometimes it is the person. – Act like it is the trend, even if it is the person. This will work better in some areas than others, but it is flexible.

Some believe that they are righteous and do not care about consensus. – Power to the people. Get enough of the staff to implement a directive.

How to deal with it going wrong? – Hard to do sometimes in formalized way, and need to do collectively.

EDIT: Bethany has now posted her version of the keynote talk on her blog.

Code4lib Day 1: Keynote on Code4libcon

Daniel Chudnov from George Washington University was the first Keynote of the conference.

Dan began with a bit of an introduction and then went into a very touching overview of the story of his family and his life. His life lesson was that

things fall apart.

We Blew It

We have turned away too many people: way more than 100 people. That was a terrible mistake. If we don’t address this mistake, this [conference] is not going to last.

Code4lib was inspired by Access, with some key aspects:

  • single track
  • participatory
  • social
  • beer
  • fun

The difference the organizers wanted was a (possibly) geekier version in the USA in Spring (so as not to compete with Access). What might have really pushed this discussion is that

we turned away more people in 2012 than attended in 2007.

Why? The most common answers revolved around the capacity of venue. There were of course, some other concerns about keeping it a small, informal, participatory conference that were expressed, especially in the backchannels (IRC and Twitter).

Nevertheless, Dan asked the key question “Why do you come?” He expressed how he comes to connect with people, and hang out with the attendees, and there are many others that wanted to join, but were turned away.

He went on to talk about how while there is a chasm of techies vs. non-techies, there shouldn’t be. Plenty of people want to learn what coders do, and as a group, we should want to help respond to change constructively. They want to code, and we should connect and work more closely with them. We have one choice to make:

HACK OR DIE

We Must Expand

Dan used PyCon as a possible a good mode to follow. They have:

  • 2 days of pre-conference tutorial days
  • up front training for all levels
  • 4 days post-conference sprint days
  • back-end collaboration for all levels
  • plenary talks, plenary lightning
  • multiple tracks

Dan was against multiple tracks for many years, but not anymore, because

we need to connect or this thing we have will fall out from under us.

His point is that next year people won’t even bother if there is no clear statement to make things work.

Challenges

  • break complacency
  • lack of proposals to host
  • too heavy a burden on local organizers

Possible Solutions

Committees need to be formalized, especially an advisory committee of former hosts to help future hosts. The work needs to be done through the year, and more open like it used to be. Dan also suggested a formal program committee to replace the “diebold-o-tron”, but there was some disagreement because it’s less participatory.

Some other ideas included a multi-core code4lib where each regional group would be 1 hour live streaming on the same day, and the BarCamp approach where there are no pre-planned presentations, which might work for regional code4lib conferences. However, concern was expressed with having too many small conferences organized, burning out possible hosts for the annual code4lib.

The next code4lib conference should aim for 500 people.

Chicago is ready. Are you?