background in negotiation theory, worked for authors of “Getting to Yes”
not the first experience you want people to have: “Bet you its a duplicate” (bug submission)
value of project is social capital: number of people contributing – harkens back to yesterday’s keynote, and that organizations evaluate OS projects based on number of developers.
community management = negotiation!
everybody’s pointing at webchick & jhodgson
hiring on technical skills, promoting on soft skills. and nobody says that. the big lie around the meritocracy.
the tools for treating this as a science already exist
lower transaction costs for engaging in the community: skills, design, data
a tweet: “the part of open source I dislike the most is [dammit, didn't get to translate, but amounts to I hate it when everyone is wrong and just doesn't use my idea]
from a negotiation perspective this is the worst option
at the core of every conversation: interests (as separate from positions) – why do you want this? underlying motivations. (it’s like doing usability testing!)
the smart-alec comment: I just want you to tell me that I’m smart.
use them to generate options, then what external standards can you use to make decisions. (legitimacy)
often breaks down because relationship and/or community are lacking
in open source communities, relationships are often MUCH weaker. communication also often weak, missing 70% because of lack of visual/audio cues.
“crazy distorted version of this framework”
build this stuff into the tools we use – nudge people to better communication
Inquire – Paraphrase – Acknowledge – Advocate
example of bug report (?) that is ALL advocating
modeling behavior and setting norms
“what should the software have done?” vs “What were you trying to do?/Why did you want to do that?”
and yet there’s all these tools out there
fork as a big threat – but github as a structure allows people to run off and innovate, at an infinite scale
attracting/empowering the lone individual
cooperation vs collaboration challenge
collaboration is very high-touch; open source restrctured process to enable cooperation, going off on your own and then bringing it back into the whole.
example of Firefox add-ons – which sounds a LOT like Drupal module situation
mapping consumption of memory by add-ons: a real issue of cooperation – then providing more data can empower the user to make better choices, which provides useful feedback to addon developers.
discussion of bug vs support
developers are incented to be mean, because they don’t want to waste their time. so talking about changing the culture maybe not the best place to start. look at the incentive structure: what’s driving the behavior?
open source projects don’t have open data portals.
if you want to advocate for drupal, you have to recognize that there are things that drupal is not good at. (in context of bug/issue tracking)
how do we create dashboard systems? shows example of seeclickfix
the hardest people to get data about are the people who leave and never come back.
need to bring real accountability to project/module owners – track wait times, checkins, etc. setting expectations. (would be interesting to combine that with time-limiting responsibilities)
open data city hackathon – look up more.
fascinating stuff. “getting health inspector data before you go into the restaurant”
