Working open
questions we want answered
explaining value of open dichotomy of open - vulnerable vs visible how to cocreate more effectively with networks scaling beyond informal sharing to something bigger moving past using the internet primarily to publish - moving to using it to cocreate
teamwork
growing recognizing within organizational cultures that good teamwork practices are central to success Google Docs as a tool of real-world activism; e.g., Collaborative spreadsheets of sexual harassers
going to an org that has a defined model. resistance to getting them to rethink the tools they use already
- example: volunteer recruitment pipeline takes too long. person tried to create a system for interacting with volunteers earlier in the process, but it didn't fit into existing organizational structure
issues that no one organization can solve - requires collaboration. thinking of organization as one node within a network that no one can run
rigidity in existing technological structures. there's less of that now. more open source tools that you can use
benefit of constant communication - team members
Austin Kleon, /Show Your Work/ Using open source principles in the context of creative communities
The places that are the most open are places where there's a clear delineation of who is and isn't in the community.
showing your work
clarity of purpose - why are you sharing this spreadsheet?
experience working in an open source community that defines itself as being for "everyone". It made vague statements about what its purpose was. Arguing with people about what the mission is. Rules were loose enough that everyone could bring their interpretation.
Need to publicly state what the mission is. Who it's for, what it's for.
Clarifying why you're working open. e.g.: to get feedback? what happens if you don't get any useful feedback?
keeping asynchronous collaboration going
big international conference calls aren't useful, but they are useful because they serve as de facto deadlines. how to create that ongoing engagement that's not driven by arbitraty deadlines.
bias, recognizing differences
Different ways that you invite participation allow different levels of difference within community.
freeform end of the spectrum -- distributed day of action, do whatever you want!
restrictive end of the spectrum -- sign this petition
practice - basketball players practice all the time, but community organizers don't practice. we're in the game all the time.
write about your work.
big aha moments
don't squash the enthusiasm! dealing with problems in a way that keeps people. steer them without slowing them down.
this conversation doesn't happen enough!
reputation - if your org uses open practices well, you'll get a reputation for doing that and more people will want to collaborate with you. if your organization has a bad history with collaboration, your reputation will preceed you.
language isn't code! trying to get people to use coding practices (version control, etc.) with non-code material has diminishing returns.
using this format: what went well, what went poorly, what did you learn. good way to keep teams connected. (tool: retriun)
Notes
- Going well
- build better teamwork
- recognition that success requires collaboration
- community
- we did something intentionally with open-source branding
- fast feedback
- positive feedback from peers encourages me to keep going
- github
- release schedule
- training
- sharing
- product
- "community" work built into "client" work
- Could be better
- it's mostly unknown
- spurts
- keeping asynchronous collaboration going
- inconsistency
- marketing
- documentation
- never enough time
- github issue queue
- working open in a dysfunctional org feels like bullshit
- bias in which communities use open practices
- recognizing differences within a movement while still working toward shared goals
- desire for feedback not matched by skill in receiving and using it
- Lessons learned
- the wider world - why/how monopolies suck
- don't squash the enthusiasm
- sell the value (not the cost)
- "better" is the enemy of "done"
- there's a huge hunger for smarter teamwork and collaboration in orgs
- we win when open is one part of a larger toolkit
- language isn't code
- team retrospectives as a practical way to share and improve
- trusted group you can pre-stage stuff with
- "working open" most produce early wins if the organization is going to commit to maintaining it
- your reputation for working open, or not, preceeds you