CommunityRule refactor now online

TLDR:

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

Background

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.

Results

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.

4 Likes

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.

2 Likes

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"
site
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