You notice a bug (problem or opportunity for improvement) and then you put a bug (metaphorical insect) into someone's ear. Most people don't like bugs (actual insects) so have you successfully bugged (bothered) them or have you done A Good Thing? When you find yourself with access to someone who could make things better for people who don't feel comfortable speaking up, how do you use this power in a way that contributes to real improvement without eclipsing other people's input? You also want to make sure that you aren't betraying confidences or triggering backlash to yourself or others. It seems like a tricky line to walk, but with a little diplomacy and lot of benefit of the doubt you can make tangible improvements to your corner of the free software community.

This talk will cover specific trouble-spots like unwelcoming behavior, the "we always done it this way" disease and how to coax your esteemed project lead (read: occasional control freak) into loosening their grip -- at least a little. It's also helpful to implement some solid "nothing's on fire today" systems for maintaining low temperature group dynamics, a culture of openness and transparency around shared goals. For anyone who cares about the success of free and open source software, this work is critical in both the wider community and inside our individual projects.

So, what things could we stand to fix around here and what are the best strategies for fixing them? The best way to start a bug report is with a description of the expected or desired behavior. Filing great bug reports on the people side that leave you, your project and the wider community in a better place requires just a little additional finesse. Maybe you'll let me put a bug in your ear about it?