CommunityRule refactor now online


With the support of SCRF, a refactor of the CommunityRule codebase is now online, poised for much more ambitious future projects.


Last year, Smart Contract Research Forum provided a grant to CommunityRule, an open-source Web app led by MEDLab at CU Boulder meant to serve as an interface for community governance design. The project was led by Deacon Rodda at SQGLZ, and I have already shared Deacon’s brilliant reflections on the project. Drew Hornbein took on the development work to implement Deacon’s recommendations. As I reported earlier, Asher Farr did some experiments with reimagining CommunityRule in Blockly.

CommunityRule was initially developed as a demonstration project by me. While it achieved some exploratory adoption, the (badly designed!) technical underpinnings limited its ability to be modular and adaptable to new challenges.


The SCRF-funded project enabled some important advances:

  • Refactoring the application code from vanilla JavaScript to the much more advanced Vue.js
  • Moving the database from raw HTML to JSON/YAML, enabling vastly improved data portability
  • Redesigning the authoring interface to be more self-explanatory, responsive, and flexible
  • Encouraging custom module design as the default, rather than relying on pre-written modules
  • Small adjustments in nomenclature and usability

Discussion and Key Takeaways

These changes bring us closer to the goal of connecting a) a visual design interface with b) programmable governance software. For example, we hope that CommunityRule can be used in the future for designing and implementing governance processes using DAO technologies and Web2 services like PolicyKit and Modpol. Moving to a JSON-based data model enables us to much more easily do things like:

  • Add arbitrary data fields on governance modules
  • Deploy custom instances of CommunityRule with custom module sets
  • Translate modules into working governance code

One important insight during this process, aided by the Blockly experiment, was recognizing the need for governance modules to be much more precisely specifiable, rather than simply being described in natural language text. As we move closer to enabling computable rules on CommunityRule, we need to gradually lessen our dependence on natural language and support appropriate machine-readable data models.

Implications and Follow-ups

We will continue to develop the basic software for usability and new features. This process will be spurred by much larger pending grant projects, in partnership with the Metagovernance Project, which we hope will fund CommunityRule development for use by open-source communities and integration with PolicyKit, respectively. Thanks to the groundwork provided by this phase of development, we can hit the ground running on those efforts.

Thank you, SCRF, for your support! And we invite anyone interested to give the new CommunityRule a try and let us know what you think.


Thank you for the update, @ntnsndr. This is exciting progress!

I am particularly interested in the observation that natural language text ended up being a barrier of sorts. It certainly makes sense that as CommunityRule is implemented across platforms that machine-readability would be important, but I am hoping that you would be willing to explain a little more about this insight.

1 Like

Thanks for this. Perhaps I overstated the case, as natural language explanations are really important. It’s just that they are inadequate for precisely defining how a module should function. I think the long term goal for CommunityRule should be to include space for both precise specification and NL description—like well-commented code. So a module might look like:

majority_binary_vote = {
  description = "Positive result if over 50% of members vote yes"
  threshold = > members*.5
  time_limit = nil

In a case like that, having to specify both in natural language and code is revealing. In NL we might say “it’s a majority vote.” But explaining it to a computer requires answering some other questions.

  • Is it a majority of all members, or just of voters?
  • Is there a time limit on voting?
  • What happens if the threshold is reached?

So in addition to greater machine readability for going beyond NL, there is the likelihood of greater clarity and specification.

1 Like

Congratulations on finishing the refractor @ntnsndr and thank you for updating us on everything! I’m excited to see everything come together. Just using your template was really helpful to me in designing governance for a project I’m working on. Actually, that makes me wonder, @Sunnypizza213 whether you might find CommunityRule useful for designing your agriculture DAO

(if anyone is curious about Sunny’s project check out - Project Agriculture DAO)

1 Like

Thanks James! I am happy to do CommunityRule sessions with any communities interested.

1 Like

Thank you.

We will check it out for sure.

1 Like

Are there any projects that are experimenting with new types of organizations within companies and organizations? I’ve been very surprised at how rigid and dogmatic the culture of agile sprints, proposals and project management in tech is compared to other industries. I understand it comes from running decentralized teams against hard deadlines, but whenever read about exciting new governance structures, I have to wonder about life for the contributors and specialists working for the decision makers.

1 Like

Murmur is an interesting example of a platform for building governance structures for teams in existing organizations that are meant to be forkable and copyable.

Great question about quality of life. I’ll have to think about how that might become incorporated in interfaces.


Maybe someone could write “Microserfs 3.0” (a la Douglas Copeland’s 1995 novella/Wired piece)

I too am fascinated by the tension between natural language and machine-readable text. One possibly illustrative example is a non-profit I’ve mentioned in this forum before, Project Haystack, which has created standardized semantic models for describing physical locations, machinery, and the data streaming off IoT sensors—all for the purpose of achieving interoperability.

To give the simplest taste, here’s a familiar location described in Project Haystack terms:

id: @whitehouse
dis: "White House"
area: 55000ft²
tz: "New_York"
weatherStationRef: @weather.washington
geoAddr: "1600 Pennsylvania Avenue NW, Washington, DC"
geoStreet: "1600 Pennsylvania Ave NW"
geoCity: "Washington D.C."
geoCountry: "US"
geoPostalCode: "20500"
geoCoord: C(38.898, -77.037)
yearBuilt: 1792

It gets more complicated from there, of course, but the point is that if all our wildly diverse manufacturers adopted the semantic standards advocated in the Haystack model, we’d be a huge step closer to implementing, say, a smart city.

The rub is that most manufacturers refuse to use these standards—I think mostly because “Not Invented Here”—and of the companies that do use them (in whole or in part), most refuse to publicize the fact that they do.

Thus, after a decade-plus of meticulous development, Project Haystack’s dream of interoperability goes unfulfilled for human political reasons. So much for coding utopia!

1 Like

Exciting project! Thank you @ntnsndr ! I checked out the website and the product, it seems that we’re able to create our own CommunityRule with predefined modules. 3 things here

  1. I wonder how did you decide to set these modules, is there any academic work or references on these definition and categories?
  2. I see some overlap and connection between the four categories: culture, decision, process, and structure; and the modules in each category. Like would Do-ocracy decision making process would somehow conflicts with the Board structure? It would be interesting to think about what would be the whole picture of the organization with each of these combinations; and could we have the CommunityRule structures in a more scalable way, like part of the org is under certain CommunityRule while these small parts come together following a different CommunityRule?
  3. some module documentations are not finished yet, I would be very interested in helping out with those, lmk!
1 Like

Thanks so much for this! Especially your interest in helping with documentation:) I’m actually unsure about whether to maintain those large text-based descriptions of modules. As I’ve reported to SCRF earlier, I’m interested in moving CommunityRule toward less of a text-heavy design and more toward configuration options that help explain to users how a module might work. Still, if you find those docs useful and would like to contribute, I would love that, and would be happy to make sure they’re readily available on the platform. Here they are in the repo.

In terms of the module set, I am actually planning to simplify the set of default available modules and encourage more module customization. One piece of feedback I’ve gotten a lot is that a lot of the names of the modules are opaque and unfamiliar, and this makes the platform harder to use. For instance, I think it might be better, rather than having 5 different voting modules, to just have one voting module that can be configured in many different ways.

I’m also not sure, if we have a shorter module list, if we need to maintain the categories of modules. There is certainly overlap, and it is hard to draw clean lines. But if anything, I think of the categories in terms of prompting users to make sure they have all those things—e.g., don’t forget about culture!

I’d love to hear any further thoughts you have! If you’re interested in discussing your participation in the project, I’d be happy to set up a call.