Quellcode durchsuchen

Amended guides to recommend separating a Rule from its data

Nathan Schneider vor 4 Jahren
Ursprung
Commit
d2748f2101
2 geänderte Dateien mit 6 neuen und 0 gelöschten Zeilen
  1. 2 0
      _guides/first_rule.md
  2. 4 0
      _guides/git_repo.md

+ 2 - 0
_guides/first_rule.md

@@ -18,6 +18,8 @@ Whether your community is already up and running or still just an ambition, choo
 
 **Use the Modules for inspiration.** Access them via <span class="pushButton"><img src="{% link assets/tabler_icons/tool.svg %}" title="Modules" /></span> alongside a given question. These suggestions are drawn from [Democratic Mediums](https://democraticmediums.info), a sister project that aims to collect governance patterns from diverse contexts.
 
+**Separate the Rule from its data**. Think of your Rule like a constitution as opposed to a code of laws, like a building as opposed to the people who put it to use. Don't try to include all your community's policies in your Rule; explain there how you make and change policies. Don't list out who holds what roles; just define the roles. In your Rule, make clear where people can find that data---the policies, the role-holders, and so forth.
+
 **Read and re-read.** Be sure that all the terminology and processes are consistent. Inevitably there will be loopholes and bugs, but try to resolve as many of them as you can. The <span class="pushButton">Preview</span> button provides a clean display for easy reading. Just press <span class="pushButton">Customize</span> when you're ready to edit again.
 
 **When you've finished a draft, show it to your community for feedback.** Others will probably think of things that didn't occur to you. This may even raise some important issues about how different members were perceiving the community differently. Aim to reach unanimity---or something close to it---about your first Rule.

+ 4 - 0
_guides/git_repo.md

@@ -33,3 +33,7 @@ git commit -am "Added GOVERNANCE.md, derived from CommunityRule"
 </pre>
 
 Whichever approach you take, **make sure that your Rule is accessible to any participant in your project.**
+
+Finally, **make a place for any other governance documentation you'll need**. We recommend having a Rule that is distinct from the details of its current implementation---separating the code from the data, in software-speak. For instance, you might make space at the bottom of your GOVERNANCE.md file for listing which community members hold which roles, or which policies your group has agreed on through processes defined in the Rule.
+
+Congratulations on making your project's governance practices clear and transparent!