From Wikipedia
Jeff asked this in the comments:
Do you have experiences moving an organization to a culture of “it’ll probably work/we’ll deal with problems as they happen” from “you haven’t convinced me yet/what if it doesn’t work”?
What if you’re trying to effect change in your organization? Where do you start?
Continue reading
How to handle WTF conference presentation moments.
On a couple mailing lists I participate in, people have raised the question: “When something offensive occurs during a conference presentation, what’s the right response from the audience and/or conference organizers?”
Unfortunately, at least one of these discussion lists is private, so I can’t directly quote the individuals who posted. But the content was worth sharing, so I’m summarizing the group’s thoughts in my own words below.
Here are some of the suggestions for handling offensive, unprofessional or inappropriate presentation content:
One theme that emerged was the need for some kind of immediate response that communicated both to the audience and the speaker that something was wrong. However, many situations require individuals to use their best judgment in responding, and stopping a talk should likely be left to the discretion of a conference chair.
Also, treating the speaker as though they have made an honest mistake and did not intend to offend anyone (I have yet to experience a situation where this was not the case, personally) is always the right way to start a conversation about it.
Photo courtesy of SanFranAnnie, under a Creative Commons License
I want to talk about a couple things today during my unfortunately named “architecting participation” session at BarCampPortland. My goals for participation are to get people to an event or be part of an open source group and then to get them to keep coming back.
The three things I’m going to touch on are: inviting in and making people feel welcome, making people feel useful, and making things fun.
With the ultimate goal being world domination of free and open source software.
We’ll see how it goes 🙂
At Code-n-Splode last night, we first heard Christie Koehler give a great talk on CodeIgniter, the one PHP web framework endorsed by Rasmus Lerdorf, original author of PHP. She went over the pros/cons, details of how you go about installing and then using CodeIgniter, and then showed a very detailed example from her recent work. I hope she posts the slides soon – they were great. (If you want to see our tweets – per Gabrielle’s suggestion, we’re tagging with #cns now.)
After the talk (nearly 9pm!) we all went over to the Green Dragon for our #afterhours chat. Audrey led off by explaining the recent controversy she’d written about, and the Ruby/Rails community response to her posts.
Some of the things she shared I was shocked by – specifically some very personal attacks in comments that she’d decided to save (in Skitch), but remove from her posts. Her standard was: “is this something that would cause my mom to stop reading.” And, if the comment met that standard, she archived and removed it.
I learned about threads in the local ruby community about the topic of women’s participation, and some very positive comments on Hacker News and Digg, and _why’s posts that seem to be expanding perceptions and opening people’s minds to ways that may ultimately be more inclusive of women and minorities.
All told, we had 15 people at the meeting, 13 of which were women. Our first Code-n-Splode meetings started with about five people. Our largest meeting (thanks to the clever, rocket-building Sarah Sharp) had somewhere around 30 people.
Among the many things that the Code-n-Splode crew discussed last night was “what made portland different”. And I thought I’d let you in on our secret.
We ask women to participate.
When we have code sprints for Calagator, Open Source Bridge or we have the Agile development meetups dedicated to coding – there are always women there. From what I understand, having women show up regularly to code sprints is unusual in other cities.
When I am responsible for these meetups, I contact the people that I want to attend directly – and I ask them to come. This is a mix of women and men (I no longer have to explicitly think about inviting women, because so many are already in the community). But when I was first asking people, I *did* have to contact women who were just dipping a toe into the community — to convince them that yes, joining us would be fun, educational and sometimes good for their careers.
When I first started attending user groups regularly about nine years ago, I often was the only woman. Now, it is extremely rare for me to be the only one. Particularly in groups that span multiple technologies (Web Innovators, Open Source Bridge, Extreme/Agile developers, Functional programming, and BarCampPortland come to mind) or are largely social opportunities for geeks to mix (Lunch 2.0, Beer and Blog). More geeky women (and women that I don’t already know) seem to attend these types of events.
I don’t think there is a single magic formula for transforming your city’s geek scene. But I think it is worth asking questions of the Portland tech community leaders, finding out how our groups work and trying out our techniques in your home town.
One OSCON session that made me think was “Does Open Source need to be organic?” The panel contained Brian Aker (MySQL), Rob Lanphier (Linden Lab), Stephen O’Grady (Redmonk), Theodore Ts’o (Linux Foundation). The session was less about business vs. community, and more about how to increase community involvement in your projects.
Brian Aker mentioned Launchpad, and the way that it handles code forks. Forks are integrated into the system using a new revision control system – Bazaar. The forks are front and center – allowing all developers on the project to add forks and update them, incorporating them in with the primary code distribution point. This model reinforces the idea that forks are natural and can be positive evolutions in open source projects.
My big take-away: If you want to increase community contribution to open source projects, provide public and easy-to use interfaces. Publish your API early and create pluggable interfaces! Let developers add functionality and publish their add-ons easily, both in your project’s development space and on their own.
The same principal can be applied to the people side of open source projects. In your organization, make roles, tasks and responsibilities transparent. Let everyone – inside AND outside the project – know what they could be doing to get things done. The mistake that many projects make is assuming that people know what they could be doing.
Think of the people-side of projects the same way as you think about the code. Documented APIs are the same as public mailing lists, blog entries and wikis that reveal what your organization is actually doing, and how new people can get involved. Roles and titles that are meaningful let people know who they should bring their ideas to. And that lowers barriers to participation.
Leadership is not just telling people what to do – it’s inspiring, facilitating and then getting out of the way of people who are willing and capable of doing things on their own. Community grown from inspiration, and then fed by encouragement, fun and recognition of accomplishment, are the ones that last. And these communities are the ones that I want to be part of.