github-for-policy

How to use GitHub for collaborating on public policy (especially for open data).

Initial material copied from here: http://government.github.io/best-practices/collaborative-policymaking/

See also:

• GitHub — Government best practices
• GitHub Showcase — Policies
• The GitHub Difference: Overcoming Barriers to Collaboration in Government
• Using GitHub in Government: A Look at a New Collaboration Platform

Collaborative Policymaking

Examples

• Project Open Data (White House Open Data Policy)
• New York State Open Data Handbook
• Australian Capital Territory Open Data Policy
• NYC OpenData Technical Standards Manual (TSM)
• Chattanooga Open Data Executive Order
• San Francisco Open Data Legislation
• San Diego Open Data Policy

Logistics

• Content stored as Markdown, a near-plain text markup language for non-developers
• Document(s) can be published using a custom HTML/CSS/JavaScript template using GitHub Pages, or displayed simply as rendered (unstyled) HTML
• Encourage editing via the web interface or via prose.io

Encouraging Contributions

• Expose process: publish pre-release revision history, have discussions in public, memorialize in-person discussions, leverage GitHub's Issues feature, and strive to maintain one class of contributors
• Explicitly encourage contribution — both in your project documentation and along side the published content
• License the content as appropriate, usually either Public Domain (CC0) or CC-BY
• Communicate the big picture: roadmap, timelines, goals, vision, and current status
• Whenever possible, open source the problem, not the solution
• Provide encouragement, feedback, and gratitude with each contribution
• Minimize friction through tooling
• Describe requirements and how to preview changes locally
• Use automated testing via Travis CI
• Decentralize decision-making authority to technical and subject-matter experts as appropriate
• See also: community-building best practices

Releases

• Whenever possible, the agency should regularly accept/reject proposed changes and cultivate community feedback
• If necessary, if a document cannot be changed, community feedback can be curated on a seperate branch from master
• The community branch can be “released” (merged) on a regular release cycle in line with agency goals