91��Ƭ��

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.