spike out external best practices notes

_posts/2015-03-09-open-source-best-practices-external-engagement.md

@@ -0,0 +1,74 @@
+---
+title: "Five best practices in open source: external engagement"
+Excerpt: ""
+---
+
+
+### 1. Expand your definition of stakeholders
+
+Going in to your first open source project, you'll likely have a narrow definition of stakeholders. You've probably accounted for open source developers, internal business owners or subject matter experts, and possibly the press. Open source communities are made out of more stakeholders, both inside and outside your firewall. Put a different way, [everyone contributes](http://ben.balter.com/2013/08/11/everyone-contributes/).
+
+Here's a short list of personas that likely already exist inside your organization:
+
+* Non-technical, non-user stakeholders (management, legal, security, privacy, ethics)
+* Potential users
+* Veteran (or curious) users
+* Subject matter experts (accessibility, content, i18n)
+* Technical users
+* Active developers
+* Potential developers
+
+Even before you hit publish, there's lots of ways to seed your project's ecosystem with different types of contributors, technical and otherwise. Here's a few ways they might contribute:
+
+* Kick the tires, does it work?
+* Answer the question: “what features would you love to see?”
+* Flesh out documentation, note where documentation is lacking
+* Community evangelism, speak, teach, and spread your love for the project
+* Submit new questions to the project’s Q&A forums, or take a stab at an answer
+* Host a genius bar at the next local meetup
+* Translate the project into a different language
+* Give feedback on proposed bug fixes and features, propose new ones
+* Recruit new developers
+
+In traditional government workflows, many of these functions happen by necessity, but artifacts, if they exist, are invisible to the open source community. Before you seek to engage external stakeholders, shift internal stakeholders off traditional workflows, and have them begin using the same tools you'd use to engage external stakeholders. Have a feature request? Open an issue. Want to review the docuemntation? Here's a link to the readme.
+
+If you do it right, by the time you're ready to engage the external community, you'll be a pro, having already used the same tools to engage your internal community, which can now be placed on equal footing at external stakeholders.
+
+### 2. Be the hub, encourage spokes
+
+As an
+
+* You are the host of the internet’s most boring cocktail party
+* Non-blocking is
 better than blocking
+* Be a matchmaker (connect subject matter experts and technical experts in the open)
+* Minimize one-to-one interactions
 (emailing anonymous-inbox@agency.gov)
+* Every answer to every question should have a URL
 (and a human name and face)
+* Answer questions once
(or never if the community can)
+
+### 3. Minimize Friction
+
+* Friction (n) The time it takes to go from
“I want to contribute” to “I have contributed”
+* What does this thing do?
+* What language is this thing written in?
+* Do I need a lawyer to know if I can use it?
+* How do I bootstrap my local development environment
+* How do I submit an improvement? How long will it take to merge?
+
+### 4. Decentralize governance
+
+* You don’t need a meeting
 to merge a pull request
+* You don’t need a suit
 to merge a pull request
+* You need to be a member of the community to participate in it
+* Responding to issues and providing support
+* Code review and enforcing project style
+* Accepting or rejecting pull request on behalf of the project Long-term planning, roadmaps, releases
+
+### 5. Encourage contributors
+
+* The right to contribute is assumed
 in the open source world
+* It’s not in government
+* Let developers know
 you want contributions
+* Go out of your way to encourage them
+* In advance
 (Document how to contribute, technical requirements, how to run the project locally in the README)
+* Daily
 (Provide constructive and supportive feedback, express gratitude when merging or commenting)
+* Going Forward
 (Automate testing with continuous integration, minimize friction through shared tooling)