benbalter / feedback

Ask @benbalter anything!
6 stars 3 forks source link

NGO + Government + Open Source communication #8

Closed a-laughlin closed 7 years ago

a-laughlin commented 10 years ago

Howdy Ben. I appreciate your open source for government writeup. I'm currently cofounding a NGO startup where we're working with cities and volunteers to develop sensor-based tools that help cities and citizens measure and visualize subjective well-being.

We're having some communication challenges similar to those in your post, and some that differ. For example, we have some people who are familiar with Github such as developers, then those who aren't, such as designers and psychologists. My cofounder is a PR guy who is all about polishing things before presenting them to the cities we're working with, thus likes to use private emails. Government staff, in this case, are both a client (for free as in beer), and a limited collaborator in beta-testing + marketing prior to citizen roll-out.

I'm all about transparency and inclusion, though that's a culture shift for non-developers. For example, would we iterate a presentation deck for a mayor in Github before giving the presentation? What about a marketing campaign generated together with the city's PR department? What aspects of sensitive biometric data should be treated as open to protect people while encouraging trust between citizens and city government?

Would you be up for thinking through some communication guidelines with us as we iterate? I started outlining some initial stakeholders, channels, etc. in our repo.

benbalter commented 7 years ago

@a-laughlin Wow. Sorry to say I missed your issue when you originally opened it. Hope I can still be helpful, but did want to respond to your question.

I'm all about transparency and inclusion, though that's a culture shift for non-developers. For example, would we iterate a presentation deck for a mayor in Github before giving the presentation? What about a marketing campaign generated together with the city's PR department?

I'd making the distinction between working in the open and showing your work. People rarely forgive mistakes because the author merely showed their work. Understanding why a mistake was made, after it's been made, is very different than participating in the process that created it (which is more likely to make readers more understanding). Regardless of if you're working in code, policy, or prose, open sourcing problems, not solutions, is more likely to be perceived as insight into and the opportunity to improve a work in progress (early access, or beta).

Opportunity to meaningfully participate is different than transparency in that it breaks down the us/them distinction. "Here's our work, please check it" creates a very different conversation than "we're starting towards this goal, will you help?"

Last, there are varying degrees of openness. It's not all or nothing. You can have a private repo with community members that have proved themselves thoughtful in public contexts, or a semi-private chatroom that only retains messages for 30 days. By playing with scope, you can maximize the likelihood of meaningful feedback, while minimizing the risk of backlash from those not part of the culture.