First of all, +1 on everything Chrys said.

Having been to probably too many conferences about the Future of Journalism, I agree there is a serious lack of meetings where people come away with new knowledge of how to actually DO STUFF. So this would be exciting. Some ideas for content:

a) "Crash courses" where one or two well-spoken experts teach people specific new skills. Potential topics abound on Hacks/Hackers: How to run apps in the cloud, process pdfs, manage mass email, do version control, create visualizations, HTML5, even playing with spreadsheets and how to get started programming. As Chrys mentioned, don't forget the newbies. We're all beginners at something. Give these courses enough time that they can dive into code and have people get their feet wet making something. Ie: a lot more than 50 minutes.

b) "Show and tell." Some of the best sessions are people who built cool apps showing them off, telling how they built them, sharing lessons learned. Lots of folks would to peek behind the scenes of Patchwork Nation, or this month's amazing NYT graphic, or the Times of London's crowdsourcing, or that epic WSJ video on the financial collapse. And we'd like to ask the creators questions.

c) Not all panels are bad. With the right people and the right topic, they can be enlightening. Sometimes panel discussions are the best medium. Some show and tells could be better as panels -- not just how one paper's team builds maps, how several do. Other ideas for panels: How hacks work on investigative teams, how to get a newsroom to buy in, designing for tablets & mobile, trends in UI, making the most of comments, maybe a long audience Q & A with smart people. As long as they keep to specific, practical ideas.

We don't need any more philosophical debates about narratives, niches, imaginary business models or -- God forbid -- social media. There's plenty of all that already. Basically if you ever think "Jeff Jarvis would be really good on this panel," kill the panel.

I'll probably update this post, but my initial reaction:

1) A clearly articulated vision for the conference's mission.

2) Fast, reliable wifi, plentiful power outlets.

3) Semi-formal structure: combination barcamp, pre-scheduled speakers, built-in side-conference/hall chat time.

4) Active recruitment of a wide variety of speakers and approaches. Not just rock stars, not just white guys.

5) Less debate, few panels (and effective moderators for the panels), more instruction/demonstration.

6) Offerings for curious but fearful newbies.

7) Somehow keep things small. (No Tufte roadshow-sized lecture halls)

At the Guardian, where I worked until the end of March (I took voluntary redundancy, a buyout), we had internal hackdays that brought together journalists, developers and even commercial staff. We had 24 hours to produce something. It was helpful from the journalists side because it helped them understand the development process more. Commercial staff brought knowledge of the market and also some knowledge of how to bring an idea from concept to market. Developers also got an insight into the editorial mindset. The Guardian Datastore and Datablog came out of the first hackday. It was a useful way to work.

I'm not a developer, and my skills in terms of development are pretty limited. I wish I knew more. However, I have been a digital journalist of some sort since 1996. Bringing together people with a range of roles and skills in journalism and development can bring about some great learning, not just in specific skills, but also in terms of helping projects get done in organisations.

One way, I think, might be to let topics bubble up from folks through a process something like this:

1. Person posts code on github/other "social" repo site to tackle some needed task or issue.
2. People try it out, write about it, fork it, ask questions, ask for features, etc.
3. Through step 2, a smaller community of ppl who can demo and answer questions about it forms.
4. Allow for some kind of voting mechanism to propose/choose what topics/issues to work on, with the requirement that there must be something (code, a demo, a document to discuss) behind it. Not simply an idea, but a work in progress.
5. Top picks become sessions at conference, with some "wildcard" or lightning sessions for newer ideas/topics/code.

For example, for NICAR this year, Ben Welsh didn't just prepare a handout on GeoDjango, he prepared an app. Imagine if people interested in that session got the opportunity to try it out beforehand, and came to the conference with that experience - it could advance the discussion at the conference beyond basic questions and contribute to further development and learning.

This would give something of an advantage to those who had existing code for projects, but we could balance that out with the "I have an idea" folks as long as they document it well and have some kind of roadmap.

In other words: projects with a purpose.

+1 to well defined intention, planning, strong facilitation, diverse presenters.

I'm a big fan of Speed Geeking -- harder on the speakers, but everyone gets to ask questions.

I think a clearly articulated vision means that you actually say, "when people leave I want {something}." Skills is still pretty vague. What skills? Who will get something out of this and who won't? (My hunch? As soon as you start saying "something for everyone" it is time to rethink.)

I'm picturing some foundation workshops (and some leadership development in the process: is there someone who should do a hands on version control workshop who doesn't usually lead sessions?), some hands on workshops, where small groups are tackling existing challenges or trying to build something new. Something like this?

And ... spend as little time as possible talking about not sucking. Or about how other conferences suck, or how original this conference is. Nothing makes me want to refine my spitwad skills faster than a welcome talk about how original and different this is all going to be. Just do it.

Chrys' points I'll second: clearly articulated mission/vision for the conference, reliable wifi and power, semi-formal structure, no esoteric debates, and keep things small.

One observation is that there now seems to be a cottage industry for putting on small-scale journalism/tech conferences (BCNI Philly last week, BCNI Boston in August, GonzoCamp, Digital Journalism Portland, the regular Hacks/Hackers meetups, etc). The explanation I would put to this is that they're filling an increasing need within the industry: regular education. If I were helping to put together one of these events, I would approach planning from the paradigm of "how can we facilitate the greatest amount of knowledge exchange?" I would also try to get each event planner to participate in a common conversation on the pros and cons of the format they chose.

All of the sessions I attended last weekend were interesting but the ones I was most engaged with were Drew Geraets' on the Public Insight Network and Howard Weaver's on Peer News. Both were quite knowledgeable on their subjects, covered topics that were either new or interesting to me, and created space for discussion around the topic.

With this in mind, preparation should focus on identifying teachers for the topics people are interested in and figuring out how to make the learning process as effective as possible.

Also, I like the hackathon concept as a way of creating space for tangible outcomes from the event. This too could benefit from smart planning, even something as basic as limiting participation and ensuring that there's the correct ratio of developers to designers to everyone else.

The last thing I'd like to mention is that there's got to be a more productive approach to attendance. Sean reported that, of 200 people who RSVPed as coming, only 118 showed up. I don't know whether that's a higher than average ratio or lower than average ratio, but it might be worthwhile to artificially limit the number of people who can attend in order to create a sense competition for participation. Or have a mechanism for publicly shaming the people who say they're going to come but don't show up.

As someone who has organized a journo conference (BCNI Philly), I strongly considered incorporating some sort of hackday element.

The problem is that a hackday for journalism needs to be pretty specific and have a stated goal, and that degree of specificity would be tough to draw over 15 people as the journo/hacker word is still in its infancy. The varying skill ranges can be tough to overcome as well.

For BCNI's case, I thought that if a hackday were to happen it would have to be a dedicated event, not an "add-on."

Call it a combination boot camp/code sprint/demo-a-thon.

For people just getting started (which, as Kevin says, is all of us in some area), very hands-on, ground-up training. Coming in knowing a little, leave knowing a little more. Go back to your newsroom with a few ideas you can implement. Do code, video, FOIA, whatever.

For people who want to work, plan a project or three ahead of time. Set the expectation that those who want to can show up, code for a few hours on pizza, beer and Diet Coke and leave with something built (or close to it). CrisisCamp and Sunlight's hackathon are good examples.

Figure out a way to demo cool projects without panels. I've got stuff I can show off, but I'd rather just set up a monitor somewhere with a fact sheet, then leave it all day while I go code or learn Flash or something.

I like what Derek said. Every speaker should be required to provide a copy of some finished product that they will walk you through.

The only problem I see with a pre-conference voting system for all the talks is that people might miss out on some good foundation stuff. Does the GIS and Shapefiles session sound interesting at first blush? Maybe, depends on who you are. But goddamn will you be happy you went to that session when you try hacking your first geospatial app.

Of course, maybe a conference shouldn't worry about teaching people the foundational stuff -- leave that to tutorials and classes. Perhaps it's better to show off some cool stuff, show people it's within reach (and hey, you even have the code to prove it!), explain a bit about it, and let them dissect the pieces themselves.

I do like the idea that anyone with the desire to can write up some code and a set of instructions can be a speaker at such a conference though. It would be a triumph of the system to sit down at a talk by someone I didn't talk to on Twitter all day (though I love you guys).

[Apologies for cross-posting on the scoop…]

I know you guys have the hacks/hacker event coming up (which I wish I could attend), but I did want to let you know about a program we have coming up as well that I would love to have your input on.

We're developing a programming for journalists/journalism for programmers seminar at Poynter in August, so I'm very interested in everyone's comments. The idea of it as it stands now is that it would have two tracks: Journalists who want to know more about programming and working with programmers, and programmers who want to know more about journalism and working inside a journalism organization. Some sessions would be with both groups together, some separate. We're throwing a lot of ideas around, including a "make something together" day.

The very basic info is here: http://www.poynter.org/seminar/seminar.asp?id=5242&catid=149

We don't want to try to imitate IRE -- they're already good at what they do. And we want to help the community in general however we can. We'd like to expose more people in journalism to programming concepts, help spread good process, and help those farther along figure out how to get even better. And have a little fun doing it…

It's still very much in the planning stages, so I'd love to hear your thoughts. If you'd rather email, I'm regina at poynter.org.

I don't have a ton of new to add to these great insights - but I think if people can walk away really confident that they know something new that's key.

I went to the ONADC/Hacks & Hackers last night and that was a great presentation. If it were paired with a hands on demo with skill level tracks, I think you'd have a winning combination for all. Get people learning individually, then working in teams to produce something. Walk out with a clip in your hand.

Adding: I loved the format that the Knight Digital Media Center does for its news entrepreneur bootcamps. Just got back.

But they're a week long.

Format: Lecture, panel discussion, day's assignment delivered. Lunch (and since you have your assignment, you can choose whether to be social or whether to do work over the lunch break.)

Then: Afternoon of work, with scheduled one on one sessions with heroes, mentors, advisers. You can grab as many of the one on ones as you can squeeze in while still doing your assignment. Assignments are due the next day, usually, so again, you decide whether to be social or geeky (or both) during evening hours.

Same format might work for a startup weekend. Unsure how to squeeze it into one day, unless it was reversed, with "assignments" before day of event, or first thing in the morning, and then lecture/presentations/pitches/solutions in the afternoon and evening. Push the presentations late enough into the day, and they could be done with beverages.

Personal thought: Physical space matters, lots, in this format. For introverts and borderline introverts (raises hand), quiet space to work is a must to avoid exhaustion and attrition late in the day.

More of a workshop (or as they call it, a "camp") -- just an FYI

http://itp.nyu.edu/camp/

We're trying an experiment with this here in the Bay Area -- a storytelling/hack day for iPad media applications in cooperation with KQED. You can see more info at http://unite.hackshackers.com

If anyone wants to come out, please consider yourselves more than welcome! We're trying to combine the typical J-school exercise of going out and finding a story on the spur of the moment with a conventional hackathon. The idea is to get journalists and developers collaborating more directly from the inception of a story. And that way, the journalists also hopefully won't be left standing around while coders code, but going out to gather content for their news applications.

undoubtedly an unconconference model.. en.wikipedia.org/wiki/Unconference

Too often the real knowledge is in the audience itself and a well moderated unconference is perfect for this

AHN would participate and sponsor.