CommunityRule

Making the CommunityRule Library Searchable

Anonymous — Tue, 07 May 2024 16:08:54 +0000

Making the CommunityRule Library Searchable Anonymous (not verified) Tue, 05/07/2024 - 10:08

Rohit Taware

Creating an effective way for users to navigate and utilize an online platform with extensive content can be a challenge, particularly for new users unfamiliar with the site’s structure. This was the case with CommunityRule, our online tool that hosts a growing library of user-created governance designs and existing templates. Newcomers often find it daunting to search for and locate specific rules or communities relevant to their interests. To address this, we embarked on a journey to enhance user experience through the implementation of a chatbot aimed at simplifying the search process.

Initially, we explored options based on the new crop of AI systems, particularly large-language model chatbots. But the complexity of that approach quickly got out of hand for a platform meant to be simple, open-source, and inexpensive to host. The solution we devised involves the use of a basic search tool powered by cosine similarity, an algorithm that measures the cosine of the angle between two vectors. This method is particularly suited for text comparison, making it an ideal choice for matching user queries with relevant content in our database. By analyzing the text input by users and comparing it to existing descriptions of rules and communities, the chatbot can suggest the most relevant matches, thereby streamlining the search process. Although we departed from the idea of having a conversational chatbot, we retained the chat interface for this search tool.

How to search CommunityRule

You will find the search icon at the bottom-right of the website, which will open a chat prompt as follows:

After searching with keywords, the tool returns the top five best matches as responses. The user can click a link and see that rule.

With the search-enabled chatbot in place, navigating CommunityRule has become significantly more accessible to new users. They can more easily find communities and rules that match their needs, enhancing their engagement and participation on the platform.

Off

Traditional

White

New in CommunityRule: User Login, Rule Editing, and More

Anonymous — Wed, 03 Apr 2024 22:43:02 +0000

New in CommunityRule: User Login, Rule Editing, and More Anonymous (not verified) Wed, 04/03/2024 - 16:43

Rohit Taware

CommunityRule is a tool that helps make communities better by providing a central place where people can create and share governance designs for their communities. It offers nine simple templates for setting up community structures. Communities can follow, modify, or even decide not to use these templates. They are meant to start discussions, inspire new ideas, and encourage feedback.

Since CommunityRule was first developed as a prototype by MEDLab, it has lacked certain important features. For example:

User logins: There was no option for users to create personal accounts or log in.
Robust database: The site lacked a robust database. It relied on a simple Google Sheet to manage the library of user-generated rules. This presented limitations on data storage, as well as yoking the project to an external platform.
History of rule versions: The website didn’t keep a record of old versions of rules, making it difficult to see how rules evolved over time.
Editing rules: The website did not allow users to edit the rules they had created. This could affect their ability to make changes or updates to the guidelines as a community evolves.
Permissions: There was a lack of proper structure of permissions on who can delete or edit rules.

To address these missing features, and to establish a firmer foundation for CommunityRule development, we introduced a few new features to our existing platform.

Database: Database and editing tool enhancements will make it easier for users to find relevant information and customize it to their specific community needs, thus improving the overall usability of the platform. Users will find it more convenient to access relevant information, and the customization options will empower them to adapt the platform to their community's unique needs. MySQL is the chosen database management system for the backend. MySQL is a widely used relational database that provides a robust and scalable solution for storing and retrieving data.

REST API: We developed various Representational State Transfer (REST) APIs. REST is an architectural style for designing networked applications, and in this context, it's used to create a set of standardized endpoints for communication between the frontend and backend. The REST APIs are exposed from the backend, meaning they are made available for external applications (such as the front end of the website) to interact with. Node.js is employed as the backend technology. Node.js is a JavaScript runtime that allows developers to use JavaScript for server-side scripting. It is known for its efficiency and asynchronous, event-driven architecture.

Login functionality: We introduced a new login functionality where users can manage their own rules. Upon clicking the Login button, users will see the following prompt to enter an email address:

Once the user clicks on the Send Code button, the provided email address will receive a unique 4-digit code. An email will be from hello@communityrule.info; the subject of the email will be the “Logging code for community rule,” and the content will be of the following format “Code for logging into community rule is XXXX.” The user will be prompted with the following new prompt to enter the code:

Now the user needs to enter the correct code to log in. If the code is correct, the user is logged in. If the code is incorrect, the user will see an error message. The user can also ask to send the code again. Once successfully logged in, the user will see a user icon, as shown in the following screenshot. The user can then click on that icon to see the logged-in email address.

If you click on the logout button, you will be logged out of the website and you will see the login button again.

You need not be logged in to see the rules in the library, or even to create a new rule. Logging in is necessary only for publishing rules and for editing or deleting rules you have previously published. When you publish your rule using your email address you will be considered as the owner of the rule

Library options: The library will list all the rules that have been published till now from the new database we created. Now when the user clicks on any rule it will be loaded into the window as follows which will have the Edit and Delete buttons as shown below.

Edit: If you are the owner, you will now be able to edit your rule. We introduced a new button, Edit, which will be visible only to the owner of the rule—the rule’s original creator, i.e. you created the rule. If you are editing the rule, however, you won’t be able to change the name of the rule; the rule name will be read-only.

Delete: You will be able to delete the rule if you are the owner of the rule or an admin. If any rule is deleted, it will no longer appear in the Library.

If you are not logged in, or you are not the owner of the rule, you will not see those buttons. As before, all users (whether logged in or not, whether owner or not) have the ability to use the Fork & Edit button to copy the rule and edit it. Rule owners who want to change the rule’s name will need to use this functionality.

Fork history: In the Library of user-generated rules, the fork history of any rule is now recorded at the bottom. If the rule was not forked from another, no fork history will be visible. Deleted rules will still be visible in the fork history but they will not be publicly visible.

These changes are important steps toward making CommunityRule a more sophisticated, user-focused, and versatile tool. By addressing current limitations and expanding its functionalities, we aim to solidify its role as an essential resource for communities seeking effective organizational structures and governance models.

Off

Traditional

White

CommunityRule Refactor Now Online

Anonymous — Fri, 20 May 2022 16:31:28 +0000

CommunityRule Refactor Now Online Anonymous (not verified) Fri, 05/20/2022 - 10:31

Nathan Schneider

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.

Also published at the Smart Contract Research Forum.

Off

Traditional

White

Designing Community Governance with Blockly

Anonymous — Tue, 15 Feb 2022 04:36:14 +0000

Designing Community Governance with Blockly Anonymous (not verified) Mon, 02/14/2022 - 21:36

Asher Farr , Nathan Schneider

CommunityRule 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 Blockly, 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 PolicyKit. 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 circles. 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.

Off

Traditional

White