Summary
The proposal for a grant of 529693 ECO ($10525, rate $0.01987 12 March 2023) to fund the development of Eco Community Consensus bot. The production version of the bot (referred as V1+ in the roadmap) is available to use on Eco Discord by Layer 3 and Eco team.
Project URL: Eco Discord Lazy Consensus Bot on GitHub
Mission
Layer 3 is a decentralized group of trusted members within Eco Discord, which is currently aimed to support cultural development of the Eco community. The main challenge of the Layer 3 group is finding consensus in group decision making. 59 people have a lot of different opinions, how to find agreement and distribute funds from the pool?
The mission of the Consensus bot is to facilitate the proposal and approval process for grants and changes within Layer 3. The first version of the bot operates using a “lazy consensus” mechanism, where proposals are automatically approved after a set period of time unless enough members of the community vote to cancel them. This allows for efficient decentralized decision-making, and helps to cut down on the amount of unnecessary discussions and arguing.
Goals
The main goal of the Consensus bot is to bring a simpler and more transparent decision making, which means - to maximize the creative process within Layer 3, and to minimize the organizational efforts needed to make things happen (to get approval of the community and the required funding).
The bot seeks to optimize consensus by ensuring that all decisions are consistent with the community’s values and principles, as outlined in the ECOnstitution:
-
Evangelize: By streamlining the decision-making process within Layer 3 and making it more transparent, the Consensus Bot helps to attract new contributors to the Eco ecosystem by demonstrating the community’s commitment to efficiency and collaboration.
-
Create: The Consensus Bot supports the creation of new projects by simplifying the approval process and freeing up time and resources for members to focus on their creative endeavors.
-
Onboard: The Consensus Bot supports onboarding new Layer 3 members by providing a clear understanding of the proposal and approval process, making it easier for them to get started and participate in the decision making process.
-
Govern: By facilitating the proposal and voting process for improvements, the bot plays an important role in the community governance, and may also expand more to the protocol governance, depending on the future development of Layer 3 and the bot itself.
-
Monetize: By simplifying the process of $ECO distribution (as a direct consequence of points distribution), the Consensus Bot helps to increase the value and monetization of $ECO, supporting the growth and stability of the Ecosystem.
With two years of existence, the Eco Community has demonstrated its ability to support various types of activities and challenges in parallel, and the Consensus Bot is designed to foster this ability, enhancing independence of the creators and ensuring adherence to the community’s values.
Solution
The Consensus Bot leverages the concept of lazy consensus to streamline decision-making in a decentralized community. The lazy consensus approach operates on the principle that it’s easier for individuals to agree by default rather than actively objecting and proposing alternative solutions.
Lazy consensus integrates do-ocracy and a consensus process. Do-ocracy is a methodology by which those who take initiative to do work in a group are empowered to make decisions about what they do. It tends to appear most often in informal organizations characterized by high levels of mutual trust and a dependence on contributions by highly motivated volunteers, which is basically how Eco Community always used to operate.
Advantages of this approach include:
-
Faster Decision Making: With the default set to agreement, decisions can be made more swiftly, eliminating the need for extensive discussions.
-
Minimized Conflict: By reducing the possibility of objections and arguments, lazy consensus fosters a more collaborative and productive environment for community members.
-
Improved Efficiency: Streamlining the decision-making process through lazy consensus increases overall efficiency and reduces the time and energy spent on disagreements.
However, it’s essential to note that lazy consensus may not always be the best fit in every situation, particularly in cases of:
-
Complex Decisions: For decisions with significant impact, a more in-depth examination of all options may be necessary, and lazy consensus may not provide adequate information or clarity.
-
Diverse Opinions: In scenarios with a wide range of opinions and perspectives, lazy consensus may not fully consider all views and may not result in an inclusive solution for all members.
To address these limitations, additional features can be added in the future (as outlined in the “Further Development” section).
Roadmap
Below is the roadmap with the delivery timelines (subject to change based on the feature development of Layer 3):
| Package | Stage | Timeline |
|---|---|---|
| MVP | Beta | 30 Jan |
| V1 | Release | 20 Feb |
| V1+ | Release (current stage) | Feb-March |
| V2 | Beta | Approx. March/April |
| V2 | Release | Approx. April |
MVP features:
- Lazy consensus with voting.
- Automatic grants and basic validation.
- Zero-downtime runtime restarts.
V1 features included MVP plus:
- Lazy consensus with grantless proposals (to approve specific actions that don’t require a grant).
- Advanced validation (wider coverage of cases, NLP, bug fixes).
- Analytics (new “!export” command).
- Multiple tech improvements (e.g. automated DB backups, recovery and versioning).
V1+ features: hot fixes and improvements based on the feedback received in production. The improvements are being added continuously so there’s no fixed date on the timeline.
- !tips - automated accounting of “personal” points.
- Various usability and tech improvements.
V2 features: a version to be used in season 2, new mechanisms and/or improvements based on the ongoing Layer 3 development and the backlog.
Stages:
- Beta: available in Eco Community Tools Beta Test Server (ask for invite).
- Release: available in Eco Community Discord.
The roadmap will continue based on the development of Layer 3 (see “Further Development”). The project is open source under the MIT license.
Team & Contributors
Team
| Name | Discord | Role |
|---|---|---|
| Arseniy Nisnevich | yulston#0081 | Developer, PM |
Individual contributors
| Name | Discord | Contribution |
|---|---|---|
| Valeriy Shevchuk | facts parade#4191 | User Guide and User Flow Descriptions (Figma) |
| Francis James Tolentino | - | Pull request |
A round of applause is in order for everyone who took part in the beta testing on the Eco Community Tools Beta Test Server. As part of the “Funds Usage” section, a proposal is being made to offer a reward to all beta testers who have made significant contributions and had a positive impact on the project.
Seeking additional team members! If you possess expertise in Python and are passionate about the project, feel free to reach out. A huge plus would be:
-
Skills in DevOps and/or QA automation (automated pipelines with integration tests are needed).
-
Adaptability and autonomy; the capacity to make decisions that effectively reconcile the needs of the users with the objectives of the project.
-
Active engagement in the Eco Community governance.
If you have skills or knowledge that can contribute to the project but are not related to development, don’t hesitate to reach out and let’s discuss how you can be involved.
Funds Usage
Detailed breakdown of the project development up to the current stage of the project (V1+): Consensus Bot: Funds Usage Breakdown - Google Sheets
Development funding summary:
| Name | Worked days | Active hours | Hours rate, $ | Total, $ |
|---|---|---|---|---|
| Arseniy | 44 | 195.5 | 50 | 9775 |
A reward of 100$ is requested for open-source contributor Francis James Tolentino who has made a pull request. I contacted Francis and he agreed to receive a token of appreciation.
Additionally, a reward of 250$ to Valeriy (@facts parade#4191) is requested for building a User Guide and User Flow Description on Figma (see “Features Overview”).
Furthermore, an award is requested for 8 beta testers who provided valuable input during the beta testing phase, resulting in new features or bug fixes, with a grant of $50 each, totaling $400:
Docdim#1444
olgatelb#9342
ihar#7824
MikeWeb#6752
Irina2610#2451
Saulo#9999
Valirini#1374
Ranil#4566
The combined allocation amount is $10525:
| Contributor(s) | Amount, $ |
|---|---|
| Development (Arseniy) | 9775 |
| Open-source contributors (Francis) | 100 |
| Documentation (Valeriy) | 250 |
| Beta test contributors (8 members) | 400 |
| Total | 10525 |
Features Overview
To quickly learn about the bot, look through the User Guide by @facts parade#4191: User Guide on Figma
Additionally, a description of a User Flow in each usage scenario is available: User Flow Descriptions on Figma
The bot currently has four implemented commands, which are:
- !propose - the main command that can be used in two ways: with a grant, which will apply the grant automatically after two days if it wasn’t cancelled, or grantless, which only approves certain actions without applying a grant.
- !tips - automated accounting of “tips” (or “personal” points), limited by 3000 per season according to the latest Layer 3 agreement.
- !help-lazy - this command sends detailed usage instructions to the user via direct message.
- !export - this command returns a spreadsheet containing all accepted proposals, tips balances and the history of tips transactions. Additional analytical commands can be added upon request.
The bot is designed to streamline the onboarding process and offers clear and concise guidance for any user commands. It also includes automated responses to address potential user errors, such as voting on the wrong message, using incorrect command syntax, submitting proposals with non-english text etc.
The bot is designed as a critical infrastructure component, ensuring reliability through several measures, including:
- Utilizing two databases that are separated based on their usage, with one for active proposals and the other for the history of proposals used for analytics. This enables better optimization and user responsiveness, with ORM used to simplify development.
- Conducting automated DB backups to Google Cloud, with the active proposals DB backed up every hour and the history DB backed up every 12 hours. Backups are securely stored for 10 days.
- Providing automated recovery in case of a downtime, which synchronizes the DB with the current state of all active proposals in Discord, including adding and removing voters and applying decisions for which the timer has exceeded during downtime. Further information on recovery can be found in this comment.
- Ensuring runtime sustainability through proper error handling and the use of PM2, a zero-downtime process manager that automatically restarts the application if it crashes. The bot is always run as a PM2 daemon and will never go down as long as the server machine is up and running. Updates to the bot can be easily delivered, taking only a few seconds to apply any changes in code without downtime.
- Utilizing advanced concurrent logic to handle voting and recovery, which underwent proper testing and was proven to be reliable. Adding new proposals can be paused at any moment without shutting down the bot.
- Controlling the entire setup with a startup script, which installs all dependencies, enables backups, sets up the firewall, runs tests, and starts the bot. This allows for simple migrations to other host machines if it will be needed.
- Monitoring the runtime with Netdata and PM2. Additionally, the bot has a robust logging in place, which allows to troubleshoot any issues quickly.
- Ensuring data accuracy and security, the bot validates all user data input through a comprehensive 3-step checking process.
- Accessing the server with SSH using a 2048-bit RSA key owned only by @yulston. The server is secured with a firewall enabled in the startup script. Each stage (beta and prod) is run under a separate user with restricted read/write permissions only to the files under their home directory. The OS used is Ubuntu 20.04 LTS, with all stable security patches automatically installed by the “unattended-upgrades” tool.
- Hosting on AWS to ensure stability.
Availability
The Consensus bot is accessible for use by Layer 3 members and the Eco team on the primary Eco Discord server. Additionally, it is available for testing to everyone on the Eco Community Tools Beta Test Server. To request an invite, you can reach out to me or any other member. All the latest updates and features will be tested there before being introduced to the main production server.
Further Development
The direction of the bot’s future development will be shaped by the input from Layer 3. Depending on whether Layer 3 decides to replace the current system with the bot, integrate them, or request new features, the roadmap will be determined. Below are some of the ideas that are being considered, but none of them have been put on the roadmap yet.
A solution to the Warlock Dilemma (when it’s unclear why a post didn’t receive any reactions, whether it’s due to its quality or lack thereof) could be to include a few required “accepted” reactions (2-4) for a proposal to be considered successful. It was suggested by multiple people in Discord. This approach is exactly what is done in the Fedora Project (see “References” section below for more information).
One issue yet to be resolved in Layer 3 is the accounting of points that remain on the balance after they are distributed. The Consensus bot can implement a feature that addresses this problem, described here.
Another idea, integrating the bot with “Table B” into a single automated workflow could combine their strengths and reduce the potential for human error. More details can be found in the Discord discussion.
A survey can be conducted to gain insight into how justice is perceived in Layer 3. The survey would involve members voting on hypothetical grant request scenarios to determine the most appropriate voting methods. Additionally, the survey would collect data on how various factors, such as community experience, influence voting decisions. The results of this survey would help us better understand the Layer 3 community’s view of justice and aid in the selection of appropriate voting methods and parameters. For example, the threshold to cancel a proposal could be determined based on the requested point amount, or the proposal duration could be based on the number of disagreeing votes or previous proposer history.
Some more of the possible features that can be added:
- A mechanism for distributing and tracking “personal” points in L3 (1000/month or other limit). Details can be found here.
- Integration of “Table B” functionality into the bot, allowing for delegation of points directly within Discord and analytics requested by a command. More information on GitHub.
For situations that require a majority vote, some more mechanisms can be added (again, these are just ideas not included in the plan):
- Bucklin Method: A way to compare each option with every other option to find the preferred choice. If no option gets over 50% of the votes, the option with the least votes is eliminated and voting starts again. This can be used for complex decisions where there are multiple options and different levels of support for each.
- Approval Voting: A method where each person votes for as many options as they want and the option with the most votes wins. This can be used for situations with a large number of options or when a person supports multiple options.
- Range Voting: A method where each person assigns a score to each option and the option with the highest average score wins. This can be used for activities or challenges where participants need to rank their preferences.
Other directions may include:
- Adoption of the bot to make protocol-related changes.
- Adoption of the bot for other communities and platforms.
The development of the bot has many possibilities. The funding request in this proposal covers the V1+ version that is currently available in production. The bots development will continue. There are no plans yet for additional funding requests until a clearer understanding of the desired features and development plan is established.
References
Read more about lazy consensus and how successful companies, communities and technologies operate using it. In many of them you can find lazy consensus as a default mechanism for decision making, while a majority vote is used for critical decisions.
Usage in Web3
In short, contrary to the popular narrative about the importance of voting, Colony encourages DAO builders to avoid voting wherever possible.
Sometimes called ‘lazy’ consensus, Optimistic Governance assumes that all actions are legitimate unless proven otherwise.
Usage in various IT projects
- Apache Foundation (~1000 employees)
Lazy consensus lets us avoid having to wait for a community-based decision before proceeding. However, it does require everyone who cares about the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, while objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is watching and cares.
More significant decisions are made through a process of full consensus. In order to pass, these decisions need three positive votes (+3) and no negative votes (-1) within a specific period of time i.e. 14 days.
For example, proposing new event guidelines for events, changing the decision-making process, and voting on Outreachy budget allocation requires full consensus.
- Prometheus (765 GitHub contributors)
The default decision making mechanism for the Prometheus project is lazy consensus. This means that any decision on technical issues is considered supported by the team as long as nobody objects.
- Sanic (287 GitHub contributors)
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote. For any major decision (as defined below), there is a separate Request for Comment (RFC) process.
Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.
For efficient agreement two factors are important:
- do it asynchronously.
- be lazy.
Most decisions start by seeking Lazy Consensus. If an objection is raised through the Lazy Consensus process, Deciders work together to seek an agreeable solution.
Individuals sharings
Bethany Nowviskie (Chief Academic Technology Officer at James Madison University, US)
You can no more effectively deny the power of lazy consensus than you can deny gravity or thermodynamics. It will act on you whether you acknowledge it or not.
Daniela Mayrshofer (CEO at consulting agency "Consensa Projektberatung GmbH & Co. KG)
To work in the mode of lazy consensus, it`s mandatory to create a culture of trust, appreciation, mindfulness, listening to each other and openness.
The advantage of the concept of lazy consensus is that a group is always able to move forward: very quick, when there are no objections - and a little slower with a learning curve when there is a valid concern to be discussed. That usually saves a lot of time und prevents endless discussions - even if not everybody is able to express her specific opinion.
Isabel Drost-Fromm (Apache Foundation)
With that lazy consensus model it is possible to unblock situations where pull requests are fairly uncontroversial. It gives people a chance to read them and move on if there’s no significant objection. It also helps putting a deadline on issues to make transparent if they are time sensitive or not.
More about various methods of self-governance (not limited by lazy consensus): Democratic Mediums
