����������ý�Ļ���Ʒ

is a Web app we've been building at MEDLab to help communities design, edit, and share their own governance systems. You can think about it as an effort to re-think the idea of bylaws in an Internet-native way. It's something that could be useful for all kinds of virtual communities, and we have developed it in partnership with open-source developers and mutual-aid groups. Currently, it is just a visual interface, but ultimately we hope it can export code for governance software tools.

As an experiment, we are currently attempting to re-implement CommunityRule in , an open-source library for block-based visual code editing. This gets us one step closer to converting the governance structures described by someone’s community into code that can be implemented—for example, by the smart contracts of a DAO, or by software like . Blockly has a built-in functionality for converting blocks into code. You have to define what the code is, but doing an initial implementation in Blockly gives us a skeleton that we can fill in with code later. Blockly also has a built-in notion of type, which makes it easier to define what blocks can go together, further providing structure for converting the blocks to code. Blockly also has built-in definitions for various common programming structures like loops, conditional statements, and arithmetic operations. Conceivably, these could allow users to define their own governance modules with considerable precision and modify already existing ones easily. Overall, a CommunityRule blockly implementation is intended to begin bridging between the purely visual representation that we have now and a programmatic representation.

The first experiment was making a modifiable block for a majority vote or a straw-poll. The block has several options. It allows users to set the winning threshold, which by default is 51 percent. It also has a quorum option, allowing users to specify a minimum number of voters required for a valid election. It takes as an input a candidate list and has a section to add more blocks that describe what to do if there is a tie. Theoretically, in a fuller implementation of CommunityRule, users could drop blocks into the tie section to describe what procedure to run if there is a tie, using other blocks.

This block raises a few questions about the implementation in terms of how much detail is required. One of CommunityRule’s goals is readability, but as you get deeper into the weeds of formality and require blocks to become programs, you need more and more details specified. For example, this block takes as an input the list of candidates which would be required for an actual program to run a majority vote, in addition to a list of votes, but it’s unclear how much of that detail should be available to the users and how much could remain on the back-end.

Here, for example, is the code behind the above module:

And the underlying JSON code:

While it may be possible to have the candidate list be present in the block but not shown to users, this is part of the difficulty with making the Blockly implementation. If something is necessary for the code but can reduce readability, we have to decide what will take priority.

Another question raised by this block is how the blocks fit together. CommunityRule, as it stands, mixes procedure and structure with no clear distinction. It’s equally easy to drag and drop blocks that define structural elements such as circles or boards with procedural elements such as majority voting consensus, without clearly defining how the structure interacts with the procedure.

This is acceptable in a purely visual implementation, because it relies on human intuition to determine how these things fit together, and there is no requirement of having a machine understand it. But with the Blockly implementation comes the question of how do we make structures and procedures talk to each other, and what connective tissue we have to create to do that.

For example, the majority-voting block currently has a “left output” configuration meaning that it “plugs in” to another block as an input instead of following after another block in a stack of instructions. What exactly it can plug into is still undefined, however. A solution for this might be to create a type system with clearly defined input and output types for each block, so the users can tell how blocks fit together, but this could lead to confusion along with the possibility of reducing the possible governance structures that are definable using CommunityRule.

One thing to try next is the implementation of the structural templates on CommunityRule, such as . So far, a little experimentation has been done to try and create a generalized structure block called a group, which should act as a sort of class initializer that would combine structure with procedure, along with some of the other CommunityRule blocks like values into an encompassing group structure.

We could also simply add more Blockly versions of CommunityRule blocks with additional configuration options. This would help us explore how they might fit together and what kinds of patterns they have in common.

Another next step is pursuing a more formal type system as discussed above, though the specifics of the type are still unclear. It appears that at minimum a distinction between blocks that dictate structure and blocks that dictate procedure must be established.

One other need, which has come up several times during the development of CommunityRule, is having some sort of questionnaire that guides the user through creating a governance structure. This could go a long way in improving usability by narrowing the options and creating a template that users can modify instead of expecting them to start from scratch.