Aragon Goverance Proposals repository
License: Other
Hi Aragon!
Our team over at Commonwealth Labs has drafted a proposal that would allow Aragon to participate in the launch of our new WASM-runtime, on-chain governed network Edgeware. Besides strong value and mission alignment, we’d love to share more about why this makes sense for Aragon to consider - if you’re interested, check our draft -we’ll get the AMA scheduled soon too!
This will help reduce or eliminate ambiguity about what is a hard requirement and what is optional in AGPs.
Reference: https://tools.ietf.org/html/rfc2119
ANV4 is the first time using the new AGP format of:
This new process is significantly more complex than before. Considering that the majority of AGPs this round were closed, that should give us pause. We went from having around 20 APG PRs to 3. Obviously this process was not very well understood. The reason for most of these cancellations is that people did not mark their AGPs as "finalized." It would seem reasonable that the AGP editors might see this and realize there was a problem. Perhaps an announcement saying: "Hey! less than 72 hours before you need to finalize AGPs." would help. Maybe commenting on PRs reminding authors that they need to "finalize" their proposals to pass to the next stage. Lots of things could have made this process a success, but it was not.
In addition to confusion surrounding the process itself, AA put in the bulk of their comments/feedback less than 24 hours before the vote! This does not give AGP authors a lot of time to take feedback into consideration, respond, and make changes. Considering that the Aragon community is global and has to deal with multiple time zones, this is simply not considerate. The Aragon Governance Process is the foundation of Aragon, but my impression is that this ANV was not a priority for the AA.
In addition to all that, the process of submitting GitHub PRs broke. Many people, myself included, were not able to edit their proposals after submitting a PR. This is likely due to a bug in the GitHub PR system. If the process we use for governance is broken, how are we supposed to function as a community?
If you have a governance process that is not clearly specified, how is the community supposed to participate?
If you have a governance process that relies on infrastructure that is not reliable, how is the community supposed to participate?
We cannot have clear and fair governance if the governance process is not clear and fair.
The updated AGP-1 says:
This is terribly ambiguous. What is the process to "finalize" a proposal? This was never specified. As a result, if we look at the open and merged AGPs we see that there was no consensus or consistency in the way AGPs were approved.
The infrastructure we are using for the Aragon governance process broke. Many people were not able to edit or update AGP PRs after submission.
unknown repository and does not allow for changes to that commit.This affected multiple AGPs, not just the example above. As a result not all AGP authors were able to participate in ANV4 with equal opportunity. This is not ok.
We can clearly see that there is no consensus as to how an AGP is supposed to be marked as finalized. Various methods were used, none of which were clearly documented or followed by the majority of AGP authors. This is simply not acceptable for a governance process.
In all of these cases the AA provided feedback less than 24 hours before the AGP "finalization" deadline. There was a week for community review when such comments could have been made. Making comments less than 24 hours before a deadline is simply not enough time for AGP authors to reflect, respond, and make changes - esp in a global community that with differing time zones. This is inconsiderate and irresponsible at best, and downright mischievous as worst. How can we fight for freedom if the very process we use to engage in Aragon community governance is so deeply biased and inefficient?
In all of these cases the process to "finalize" an AGP was not specified. No warnings or guidance was provided. AGPs were simply closed due to not complying with rules that were not specified in the first place.
In many of these cased the PR mechanism for GitHub was broken and did not allow AGP authors to edit their AGPs. This prevented all governance participants from having fair and equal opportunity. This is not in line with AGP-0.
AGP-1 specifies that the AA can hold emergency votes to delay or reschedule Aragon Network Votes. For these reasons outlined in this Issue, I am calling for the AA to create an emergency vote push every stage of ANV4 back by 1 week. This will give everyone time to update their AGPs so that we can all get on the same page. This will update the ANV4 schedule to the following dates:
Aragon exists to fight for freedom, but this ANV did not support the freedoms of the Aragon community. This is because of a lack of specificity in AGP-1 around the AGP "finalization" process, GitHub technical difficulties that broke the infrastructure that facilitates the AGP process, and last min comments/review by AA that did not leave room for AGP authors to reflect, incorporate feedback, and update proposals before the AGP finalization deadline. As a result, all parties involved were not fairly represented and did not have an equal opportunity to participate in Aragon network governance. It is the responsibility of the AA to take action when things do not go according to plan. This is one of those times.
Having the titles as actual headings in the document, rather than only in the metadata, could help to identify what AGP is being seen.
Before:
After:
We could also have the identifier in the title:
The AGP Authorship Standards PR was pulled from ANV4 by the Aragon Association due to the high volume of AGPs in ANV4. This Issue is a placeholder for that AGP that shows the proposed updates to AGP-1.
I (@burrrata) will submit these changes (or a modified version of) as an AGP for ANV5.
Version 1.2
AGP stands for Aragon Governance Proposal. An AGP is a document that details a change to the management, allocation, or use of shared resources owned or directly influenced by the Aragon Network. All AGPs must be consistent with the goals and values put forth in AGP-0 (the Aragon Manifesto) and compliant with the requirements outlined in this document, AGP-1. The AGP author is responsible for building consensus within the community for their AGP and documenting dissenting opinions.
The purpose of the Aragon Governance Proposal Process ("the AGP process") is to provide a structured process for making changes to the shared resources of the Aragon Network. For these shared resources, governance processes are needed to grant or deny access and approve or reject proposed changes. By creating a fair, lightweight, and transparent AGP process, the AGP-1 authors hope to give ANT holders a meaningful say in the governance of the Aragon Association and the Aragon Network and increase the chances of success for both.
Parties directly involved in the process are the AGP author (you), the AGP Editors, the Aragon Association (“the Association”), and Aragon Network voters.
Proposals follow this workflow:
During Stage III AGP Editors will review proposals for formatting, legibility, and compliance with AGP-1, referring to AGP-1 as the basis for accepting, denying, or requesting modifications to a proposal. The role of AGP Editors is further described in the AGP Editors section.
At a high level, the AGP-1 workflow looks like this:
Before you spend time working on a proposal, make sure the proposal complies with AGP-1 and has a chance of passing review by the AGP Editors and your peers. Review the AGP tracks and their requirements then select the track that you think is best for your proposal. If your proposal meets the requirements, it has a much greater chance of being accepted by AGP Editors and approved by Aragon Network voters.
There are four tracks that an AGP can be categorized into. Select the one you think is best for your AGP:
Proposals that cannot be categorized into one of these tracks will likely be denied by AGP Editors. At the discretion of AGP Editors, a proposal may be categorized as “Other” until a new track is approved as part of a Meta AGP.
In addition to the requirement that all AGPs must be consistent with AGP-0, each track has its own requirements for AGPs as follows:
Association
Proposals made to the Association track must affect one or more of the following:
Finance
Proposals made to the Finance track must affect the movement of assets held by the Association multisig. The Association will have discretion over which multisig transfers must go through the AGP process.
Meta
Proposals made to the Meta track must affect changes to AGP-0 or AGP-1. The Association has the power to add and remove AGP Editors and fix errata in AGP-0 or AGP-1 on an as-needed basis without going through the AGP process. All other proposals to modify AGP-0 or AGP-1 should be made to the Meta track.
Proclamations
Proposals made to the Proclamations track must be consistent with the Aragon Manifesto.
During Stage II you should seek feedback on your AGP idea by sharing it with your peers in the Aragon community and soliciting their feedback. Examples of appropriate venues to share your AGP idea include:
Be open-minded and respectful of all feedback you receive. Adjust your proposal to address serious concerns as they come up to increase the odds of your proposal passing review in later stages.
If an AGP discussion is open on the Aragon Forum or the Aragon AGP GitHub repo, the person who started that discussion has the first claim on submission of a formal AGP around that idea. This claim on the AGP is only valid from the time the issue/thread is opened until the next ANV.
If it seems like discussions around an open thread/issue have been abandoned, and the author still has a claim on AGP submission, you need to get permission from that author before submitting an AGP yourself for the idea.
After you have asked the Aragon community whether an idea is available for you to create an AGP, has any chance of support, and you have received sufficient feedback to feel confident going forward, you can create a draft AGP as a pull request to the AGP repo. Use a template from the Templates section below to ensure you are including all the necessary information. The draft AGP file should be given a temporary name, which the AGP Editor will rename when the AGP is assigned a number.
Collaboration is not a zero-sum game. This is what makes being a member of the Aragon community so attractive, rewarding, and enriching. To ensure that we cultivate a healthy and collaborative environment all AGP authors are required to fill out a “Contributions and Prior Work” section. This allows authors to add attribution info to AGPs in a clear and unambiguous manner. If you are the sole originator of an idea and it immaculately came into your mind without any input or feedback from the broader Aragon community, then you can say so in the "Contributions and Prior Work" section.
Templates
Below is a list of AGP templates for each track. Copy the template for the track your AGP is in, fill it out, and submit the pull request with your AGP for review. Sections marked as “required” in the template must be completed. Note that all proposals must be licensed CC-0.
To make a Meta track change, you must:
After an AGP has been submitted as a draft to the AGPs repo, it must undergo a Community Review period that starts three weeks before the next Aragon Network vote begins and lasts for one week. Draft AGPs must be submitted as a pull request to the AGPs repo before the Community Review period begins to be considered for the next Aragon Network vote. All draft AGPs that have an open pull request at the time the Community Review begins will automatically be moved to Stage IV for consideration.
During the Community Review period, the draft AGP author will have a chance to respond to feedback and make changes to their proposal based on the feedback they have received to increase the likelihood of the proposal passing.
If anyone feels that they are not given due credit where credit is due they can request this change in the AGP review period. This request must be accompanied by proof of contribution. It is up to the AGP reviewers to determine if this claim is valid, and if so, add the contributor to the "Contributions and Prior Work" section of the AGP.
At the end of the Community Review period, AGP Editors will perform a final review of the proposal.
If agreeable, an AGP Editor will assign the AGP a number (generally the PR number related to the AGP). The AGP Editors will not unreasonably deny assigning a number to the AGP.
Reasons for denying an AGP number and closing the pull request include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing concerns by reviewers, or not in compliance with AGP-1.
After a proposal in Stage IV has been thoroughly reviewed, you may finalize your proposal and request that an AGP Editor moves the proposal from Stage IV to Stage V. If you do not finalize the proposal and request to move the proposal to Stage V before Stage V is scheduled to begin, AGP Editors will consider the proposal withdrawn and close the pull request when Stage V begins.
An AGP in Stage V is the final version that will appear on the ballot during the next Aragon Network vote. AGPs that move from Stage IV to Stage V are reviewed by the Aragon Association Board of Directors and, if approved during the pre-vote review session, are merged into the AGPs repo and added to the list of AGPs that will be submitted to the Aragon Network for a vote in Stage VI. Approval or rejection of an AGP during Stage V is made at the discretion of the Association board.
The Stage V Association board review session begins two weeks before the next Aragon Network vote is scheduled to begin and lasts for one week.
All AGPs that have moved to Stage VI since the last Aragon Network vote and have been approved by the Association board are included on the ballot in the current vote. During the vote, Aragon Network voters will review proposals on the ballot and cast their votes.
If a vote on an AGP produces a Rejected result, then the status of the AGP will be updated to "Rejected" and no further action is necessary. If a vote on an AGP produces an Approved result, then the AGP will either be executed automatically by the Aragon Network or else dutifully executed by a manager designated in the AGP (or designated by the Association board if no manager is designated in the AGP). Any pull requests referenced in a Meta track proposal approved in Stage VI will be merged by an AGP Editor, and the result of the Aragon Network vote will be recorded in the corresponding AGP file by an AGP Editor.
Aragon Network votes take place quarterly on the following days, starting at 16:00 UTC time and lasting for 48 hours:
Support required
With the exception of Meta track proposals, the minimum support required for approval is >50% of all votes cast, an “absolute majority”. The minimum acceptance quorum required for approval is >0% (at least one positive vote needs to be cast). Votes are token-weighted, so 10^-18 ANT (the smallest possible fraction of one ANT) equals one vote, and at least 10^-18 ANT is required to vote.
For Meta track proposals, the minimum support required for approval is >66.6666666666666666% of all votes cast, a “supermajority”. The minimum acceptance quorum required for approval is >0% (at least one positive vote needs to be cast). Votes are token-weighted, so 10^-18 ANT (the smallest possible fraction of one ANT) equals one vote, and at least 10^-18 ANT is required to vote.
Emergency Vote
The Association can call an emergency Aragon Network vote or re-schedule a vote at any time with minimum 48 hours notice by a unanimous approval vote of the Association board. In case of emergency, immediately following approval by the board, the Association will make a best effort to notify ANT holders of the start date and time of the vote using these communication channels:
If the Aragon Association approves re-scheduling a vote, the new start date of the vote must be no more than 14 days later than the previous start date of the vote. The Aragon Association cannot approve re-scheduling the same vote more than twice.
AGP Editors are experienced and active members of the Aragon community selected by the Association to manage the AGP workflow. AGP Editors are not gatekeepers to the proposal system. AGP Editors exist to make proposals submitted to the AGP repo easier to review.
AGP Editors have two responsibilities:
Review proposals
AGP Editors review proposals and accept, deny, or request modifications to them based on formatting, legibility, and compliance with AGP-1.
Move proposals from Stage IV through to Stage V
After a proposal author submits a pull request with their proposal in Stage III and has it reviewed by the community in Stage IV, an AGP Editor will review the proposal to make sure it is compliant with AGP-1. If so, the AGP Editor will assign an AGP number to the proposal. After a proposal in Stage IV has been thoroughly reviewed, the author can request that an AGP Editor moves the proposal from Stage IV to Stage V.
The current AGP Editors are:
This document borrows from Ethereum’s EIP-1 written by Martin Becze and Hudson Jameson, which itself was derived from Bitcoin's BIP-0001 written by Amir Taaki, which in turn was derived from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Aragon Governance Process, and should not be bothered with governance questions specific to Aragon or the AGP process. Please direct all comments and questions to the AGP Editors.
Copyright and related rights waived via CC0.
At the moment, it is very hard to find the right AGP unless you know all the numbers by heart.
Currently PRs have labels for different stages of going through the process.
As there will be past proposals and upcoming that want to get included in a specific round, I think it would be useful to have Round/Vote labels added as well.
So that for example, AGP-5 would have a label for Aragon Network Vote #1 where as AGP-42 would have a Aragon Network Vote #2 label attached.
Instead of the usual "Should AGP-X be approved?", maybe we could add a short title before that question, like "Aragon Black: Should AGP-X be approved?" or "Separation of State and Church: ..."
AGPs are a wonderful tool to give the community a voice and guide Aragon's decision making. Before submitting proposals for concrete decision making, there is often a need to gather signals from the community. This can happen in the forum, but in a heated and long term debates it's often impractical to measure sentiment without getting overwhelmed. The Aragon community realizes this and has created an awesome signalling app.
I propose that the signalling app be updated so that it is fully functional and can included in the AGP-1 doc as part of Stage 2: preproposal. This would require all AGPs to use the signalling app to gather sentiment from the community along with current methods of forum posts and AMAs before drafting a proposal. This metric can then be taken into consideration by the AGP Editors during Stage 3: Draft.
Please share thoughts on this and/or what needs to happen from a technical perspective to make it possible. Once a more concrete plan is in place, a submission as a Meta AGP seems appropriate. Thanks :)
Following on from this thread and this thread I propose we create a Community Rewards DAO (CRDAO). Its goal is to acknowledge and reward informal contributions and encourage community members to take initiative and create value in a permissionless fashion
TBD, but will be the Vault of the CRDAO
12,000 ANT
1
The CRDAO will reward contributions to the Aragon ecosystem with small amounts of ANT. Its purpose is to reward people for contributions they do and encourage them to do more voluntarily without necessarily an expectation of specific remuneration. it differs from CFDAO in that recipients do not apply for funds, CRDAO rewards are recognition for service to the Aragon Community.
CRDAO will have a fixed weekly budget. This will provide a runway from this AGP to the next. The budget will be divided amongst nominated Aragon community members using Autarks Dot Voting app. The reward policy will be based on the 1Hive model, however a key difference being that any member of the Aragon forum can nominate anyone else, but it is up to the DAO members to actually vote on those nominations. Details on the proposed structure and settings of the CRDAO can be found here
Organization (if any)
Name: Community Rewards DAO
Website: N/A
Funds will go directly to the DAO's vault. Burrrata and Aaron will be responsible for creating the DAO. Community members will be asked to inspect and audit the DAO before funds are transferred to ensure permissions are set correctly according to the CRDAO-Outline..
Name: aaronfosterreal
PGP key fingerprint: 66AF0356A1D09F61
Website: Aaronfoster.eth
Other URL: https://keybase.io/aaronfosterreal
Name: burrrata
PGP key fingerprint: FFB0474A8164B4B7
Website: burrrata.ch/website
Other URL: https://keybase.io/burrrata/
Copyright and related rights waived via CC0.
Currently the Flock repo states that:
The Aragon Association and representatives of the current Aragon teams will review and approve the relevant applications but the community is invited to participate in the public discussion that will take place in the comments of the relevant pull request. After approval by the Aragon Association, teams must submit a Finance track proposal requesting funding via AGP-1 and ANT holders will approve or reject such proposals.
However AGP-1 does not itself say anything about the Flock process. We should amend AGP-1 to integrate more tightly with Flock, either by incorporating it into the Finance track or creating a separate Flock track.
Decisions are everything. Our lives are determined not by how many steps we stake, or how diligently we take them, but by the direction we choose to walk. Aragon makes choices via AGPs. As such, AGPs guide Aragon's future. It's important that we have all the data we need to make the best choices we can for AGP votes.
This is difficult because while we want to be as educated as possible, we all have busy lives. We can only represent the interests of the community by making it as easy as possible for as many people as possible to engage in governance decisions and vote. How do we find the balance between research and ux? We don't. We make the data available and let people make their own decisions.
With that in mind, I propose the Aragon Voting Gauntlet: a series of trials and tribulations designed to squeeze the data out of every proposal. This will hopefully lead to more thorough AGP proposals, more community feedback in the draft/review process, and better outcomes for the Aragon community. These suggestions are meant to augment the current AGP-1 process, not replace it. The main idea is to give people more time to do research and ask questions, and to create more events that prompt them to do so.
Voting Prep Countdown
> 1month: Anyone can create proposals. It's encouraged, but not required, to get feedback from the community before doing so, as AGP-1 Step 2 suggests.
1 month: A month before the upcoming vote, submissions are closed. The AGP editors curate the proposals (removing those that don’t meet the submission guidelines) and present the best ones to the community for review.
3 weeks: Every proposal has an AMA where the community can ask questions, critique proposals, and have open conversations. This allows for flaws to be discovered and/or proposals to brought into line with reality. Think of it as a time to review the rough drafts before final edits.
2 weeks: After the AMA, there’s a week where proposals can be modified based on community feedback (final draft).
1 week: Proposals are locked and the community has one more week to review and debate them before voting.
Voting: It happens.
2 week review period: Tokens are locked and the vote is analyzed to ensure no capture or manipulation (dark DAO, etc...). I think there’s already provisions in place for this, but it’s worth mentioning again as part of the overall process.
New cycle where anyone can submit proposals.
Looking for feedback before creating a Meta AGP. Thanks! :)
Version: 0.01
Delegate voting as a primitive has clear benefits, potentially compounded with staking, bonding curves, futarchy, as well as the others, being developed.
Furthermore, it increases the influence of community members aligned with the Aragon vision and manifesto but have little plutocratic Power.
voter turnout at the first round of voting was extremely low, while the turnout has increased in the most recent round of voting 4.8% is still incredibly low leaves us open to attack.
then there is the uncomfortable truth that one whale did control the outcome of several proposals. if the turnout remains roughly the same next time around, A few $100k's can buy a controversial AGP. Personally, I was for #41 but if it got flipped last minute by a whale, that would have been a PR disaster.
One of the biggest factors behind this simply that voting sucks, It costs money and its bandwidth intensive. Furthermore, it doesn't scale well (in attention terms). Of course, waiting 30min for the app to load isn't exactly great UX, however, these are technical issues which I'm confident will be resolved.
I'm super excited about the Level K Futarchy app, governing the AGP process with futarchy 😍🤓🚀🦅. But there are questions of liquidity that I'm not sure have been solved. Personally, I'd prefer the AGP process to run this way but I'm not sure how long it would take to do it safely? In the meantime, we need to explore other options. We should not have all our eggs in one basket (pun intended!)
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.