Great post today from OCWC board member Phillip Schmidt on the iSummit event he attended — what went well, what might have gone better. As a communications guy getting ready for our own conference in September, this graf, on how best to share the conference with the larger community, was particularly thought-provoking to me:
The natural response to this would be: “place more emphasis on documentation and share audio/video/text online”. However, having facilitated the documentation efforts at the iSummit 2007 I know how hard it is to collect all the images and notes from participants, and how much (tedious) editing is required to bring it together into a useful resource. Yet, I am not sure how many people actually go back to the notes beyond trying to find email addresses of people they met, or links to projects that were mentioned. In 2007, Mark and I knew we were going to write an article about the event, so having very detailed notes was more important than this year.
So I would suggest, that rather than trying to document everything that is going on during the event, we create a rich list of contact details, URLs, and links to everything that comes up during the discussions. Every time someone mentions a project, it needs to be added to a list of resources on the wiki. That’s relatively easy to do, even if we ad short annotations which makes the list so much more useful, and this could easily live on after the event.
Like most people reading this, I’ve seen sharing efforts at these sorts of things done well and done poorly — and found that there’s not necessarily one right way. It depends on who your conference audience is. I’ve been to academic conferences where almost everything put online was done centrally (and what was put online was not much). On the other hand, I’ve presented at a digital democracy events where people liveblogged your presentation as you spoke.
My sense is our community falls between those two extremes, and in the next couple of weeks we’ll be figuring out how best to assist in documenting the event in a way appropriate to our resources and audience. But we’d love your help. What sort of things have you seen that have really worked — and have not added that much overhead? What have you seen that has failed?
And the big question: what sort of approach to documentation would you like to see us employ in Logan?
[and remember this question is as much directed to those who will not be in Logan as those who will, Consortium members and non-members alike — share your thoughts!]