Because we've got, through ticket trackers and that kind of thing, some semblance of records of how we produce code - but precious few records of how we produce things like talks on open source, or how various people go through the process of thinking about them. Note that I am still new enough to speaking so as to have to pull my process together more or less from scratch (and fight a rather healthy dose of "but... how do I do this? I don't know!" fear), so... y'know, if I eventually figure out how to do this, anybody can. That is my thesis, anyway.
Here's what was rolling around in my head on the bike ride home, awkwardly phrased: "The point of a talk is sparking insight, not conveying information." I'm thinking about the talk I'm going to be giving at OnLinux, and how I'm going to do it; what is the speaking style that is a natural extension of the way I teach? I think it has something to do with the way I run meetings.
The motivation is to have as many simultaneous actively participating people in the meeting as possible - ideally, at all times in the meeting, everyone in the meeting should be doing something really cool (and hopefully Marketing-related) - not just waiting for their turn to speak. Think of it as a virtual version of the law of two feet. (From https://fedoraproject.org/wiki/Marketing_meetings)
In other words, I don't care if you're learning what I'm teaching; I care that you're learning, and I care that you care about what you're learning. Or at least that's how I ran my tutorials back when I was a TA. Similarly, I don't care if people listening to my talk actually listen to my talk; I care that they think about something that they think is really cool as a result of the time we spend together. I want them to have their ideas, not my ideas.
This is the way I listen to talks myself - unless I'm right in the front row, I'm usually unable to actually catch all the things the speaker says (hearing loss + echo-riffic rooms + too far away to lipread = ehhh) so I clutch at what I do hear and run forward with it in my mind; this is great, because it means I'm both engaged and intellectually excited during the entire duration of the talk. It's a way of customizing the talk for yourself as a listener. And I would like my audience to do that. Everyone.
Hm. Okay, I have a piece of the target, and the other piece is "what area do I want people to be thinking about?" and that is in the abstract (though maybe I ought to come up with a more deliverable/action-oriented one, or something. Ehh. I'll worry about that if I think I need it later. But anyway, I can figure out how to use my session time so that this is the effect it has. I wonder if I can find a way to convey this thought at the beginning of the talk. Hm.
Anyway, here's the presentation abstract that I wrote at... something like 5am on Friday morning. I'll try to work the presentation out here as it evolves; it'll be interesting to be able to look back and watch how my thinking on giving talks (or this particular one, anyhow) takes shape. As usual, comments welcome. The presentation was sparked by this list and a conversation at POSSE.
The Invisible Traceback: blockers that make potential contributors drop out (and how to fix them)
Unix Philosophy #12, Rule of Repair: "When you must fail, fail noisily and as soon as possible." This applies to both code and culture; when someone gets stuck and hollers for help, they are helping their community find and fix a participation process bug. However, the new contributor on-ramp pipeline is particularly tricky to debug; potential participants often struggle in silence, giving you no indication of their presence, let alone why they were unable to begin working with your project community. We'll go over some common blockers that quietly prevent students (and other new contributors) from beginning to participate in open source, and how to fix them no matter who you are.
Beginners enthusiastically welcomed - this talk is for everyone who's ever wanted to contribute to open source as well as everyone who's ever wanted to help someone else get started with contributing. It took me over 6 years of banging my head against a solitary wall to figure out how to contribute back to open source (and it's been worth it) - here's how to figure out (or help someone figure out) the same thing in 99.999% less time.