Call for an emergency vote to push back every stage of ANV4 by 1 week

ANV4 is the first time using the new AGP format of:

  • proposal => community review => AA review => final freeze => vote

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?

Overall, I’m extremely disappointed. I’ve spent months engaging with the Aragon community and learning about various pain points. In response, I spent days thinking about and drafting many AGPs that I thought could help. I invested my time and energy to contribute to Aragon’s governance process even though there was very little in it for me. Now, due to technical errors and miscommunication, all my AGPs are closed. I’m extremely disappointed in the thoughtfulness, community engagement, and execution of this ANV.

I’m happy to fight for freedom, but this was not that…

4 Likes

Further Analysis

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.


What is “finalization?”

The updated AGP-1 says:

  • “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.”

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.

Looking at the AGPs that were not closed, we see the following:

  • AGP PR 102: A comment says that the proposal was updated, but no mention of finalization.
  • AGP PR 65: A comment says that this AGP is is not finalized and should be left open as a draft.
  • AGP PR 60: No comments.

Looking at the AGPs that were closed and merged, we see the following:

  • AGP PR 113: No comments.
  • AGP PR 112: A comment states technical difficulties, but do not state anything about “finalization.”
  • AGP PR 106; A comment was made asking to move the AGP to stage v, but does not state anything about “finalization.”
  • AGP PR 103: A comment was made stating that the proposal is finalized, please move to stage v.
  • AGP PR 89: A comment was made stating the proposal is finalized and can be moved to stage v.

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.

Looking at the AGPs that were closed and not merged, we see the following:

  • AGP PR 111: No comments.
  • AGP PR 110: This PR was created 5 hours before the AGP “finalization” deadline. This PR was created by an AGP editor, but not by the original author. A comment states that this was an attempt to work around a bug in the GitHub PR system.
    • This process of re-submitting PRs for original AGP authors to comment on is not standard practice, nor is it documented.
    • This new PR was submitted 5 hours before the AGP “finalization” deadline.
    • AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 109: This PR was created 5 hours before the AGP “finalization” deadline. This PR was created by an AGP editor, but not by the original author. A comment states that this was an attempt to work around a bug in the GitHub PR system.
    • This process of re-submitting PRs for original AGP authors to comment on is not standard practice, nor is it documented.
    • This new PR was submitted 5 hours before the AGP “finalization” deadline.
    • AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 108: Comments were made by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 107: All comments and reviews were created less than 24 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 105: AGP editor reviews were created less than 5 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 104: Comments and reviews by the AA and AGP editors were made 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 101: Comments were made by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 100: Author stated 2 days before “finalization” deadline that the infrastructure to edit AGPs was not working correctly. No solution was provided. AGP was closed due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 99: Closed by AGP editor. No comment.
  • AGP PR 98: Closed by AGP editor. No comment.
  • AGP PR 97: Closed by AGP editor. No comment.
  • AGP PR 96: Closed by AGP editor. No comment.
  • AGP PR 95: Closed by AGP editor. No comment.
  • AGP PR 94: Closed by AGP editor due to lack of “finalization,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 93: 7 days before “finalization” deadline AGP editor asked author to split PR into 2 because it contained multiple AGPs in the same PR. Author replied and followed instructions accordingly.
  • AGP PR 92: The AA and AGP editors made comments 10 hours before the “finalization” deadline. Author has commented in this thread that, due to their time zone, they were literally asleep when AA and AGP editors commented and had no way to reply before the deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 91: Comments were made by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 90: Comments were made by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 88: Comments were made by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 85: Comments were made by an AA member 10 hours before the “finalization” deadline. The author did their best to respond to comments in the time provided, but then could not edit their AGP due to a technical bug in the infrastructure used in the ANV governance process.
  • AGP PR 84: No comments. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 83: Review was provided by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.
  • AGP PR 81: Review was provided by an AA member 10 hours before the “finalization” deadline. AGP editor closed the AGP due to not being “finalized,” even though there is no clear documented protocol to “finalize” an AGP.

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.


Governance Infrastructure

The infrastructure we are using for the Aragon governance process broke. Many people were not able to edit or update AGP PRs after submission.

  • For a more detailed explanation of the situation, take a look at this GitHub PR. GitHub shows a commit from 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.


3 Likes

Upon further reflection and analysis of AGP-1, this situation calls for an emergency vote to reschedule the finalization of AGPs for this ANV.

As evidenced, the process to “finalize” AGPs was not adequately defined and the governance infrastructure to submit AGPs was broken.

AGP-1 specifies that the AA can hold emergency votes to delay or reschedule Aragon Network Votes. For these reasons outlined in this thread, 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 Network Vote #4

  • Draft proposals for this vote are due, mandatory community review period begins: 2019-10-10 at 16:00 UTC
  • Final draft proposals for this vote are due, Aragon Association review begins: 2019-10-17 at 16:00 UTC
  • Aragon Association review ends, final community review begins: 2019-10-24 at 16:00 UTC
  • Aragon Network Vote #4 begins: 2019-10-31 at 16:00 UTC
  • Aragon Network Vote #4 ends, final results announced: 2019-11-02 at 16:00 UTC
3 Likes

Aragon exists to fight for freedom, but this ANV did not support the freedoms of the Aragon community. This is because the AGP process was poorly defined and some people were not able to edit their AGPs as part of the AGP process. 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.

@luis @jorge @stefanobernardi

1 Like

I agree, I stayed up until 4am reviewing our proposal and making sure everything was right and “finalizing” it. Our PR still being open was our obvious request to continue moving to the next stage. It was never clear I had to state somewhere in literal words that we wanted to continue moving to the next stage. I was asleep when our proposal was then withdrawn without any warning.

4 Likes

Opened an Issue in the Aragon AGP GitHub repository to formulate the ideas in this thread into a cohesive call to action:

1 Like

Today is the last day of Devcon and we are throwing the Aragon party tonight. The timing has definitely been a bit unfortunate.

We will look at this tomorrow and share our thoughts.

1 Like

First I wanted to quickly clarify this:

PR-113, this is not an AGP but simply renaming a file in the repo because the file name wasn’t updated correctly in the PR that merged and assigned the AGP number for AGP-106.

PR-112, replicates the content of PR-85 because a technical issue prevented updating the PR to assign the AGP number. It references the original PR which does indicate that it is final.

These instances are not examples of an AGP being updated to stage V without an indication from the author that they are finalized and ready to move to stage V.

Every proposal that was merged and updated to Stage V has a comment by the author indicating that it was ready to be moved. Their is no “Key” word specified in AGP-1, and perhaps that is ambiguous, but I don’t really think the issue here is whether an author uses a specific term to indicate that the proposal is final or whether it is ready to be moved to stage V or some other wording that describes the same intent. It is however important that there is communication. As an AGP editor I want to be helpful and move things through the process, but have to balance being helpful with being consistent with AGP-1, which clearly indicates that proposals which do not have any indication that they are finalized and ready to be progressed are handled.

From 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.

It’s worth noting that I authored multiple AGPs this cycle and even as an AGP-editor I failed to finalize them before the deadline. This is entirely my fault, and while disappointing, It seems clear to me that the process was both reasonably clear, well documented, and communicated and I don’t think it makes sense to try and push fault onto the process for that failure.

That being said, the process could certainly be improved in the future, and while I believe that the process has been executed faithfully and consistently as described in AGP-1 as it exists today, I’m not opposed to an emergency vote being used to allow ANT holders to choose to delay the vote by a week.

It seems clear that for whatever reason many proposals and multiple authors all failed to finalize proposals despite the intent for them to progress. As an AGP-editor I don’t feel like I have the authority (or want the authority) to make discretionary decisions about rescheduling AGP deadlines, but an emergency vote does have that authority and it seems reasonable to consider using that to resolve this dilemma between maintaining consistent processes and being overly bureaucratic to the detriment of the community.

2 Likes

It seems clear to me, regardless of the reason, having so many AGPs closed and not merged means the process didn’t work well this time around. My biggest frustration was the fact it seems the AGPs were reviewed so late before the cut off time leaving not much room for editing them.

in any case, I support the reschedule

5 Likes

On the basis that the process of submitting GitHub PRs broke, a key part of the overall ANV voting process, I think this alone probably warrants an emergency vote to be triggered to push back ANV4.

1 Like

Noting that there’s also a GitHub issue for this discussion here. Let’s try to keep the conversation in one place (this forum thread) for clarity’s sake.

There’s a lot here, I’ll try and address each point, some from my own perspective as a participant in the process and some from my perspective as an AGP Editor.

We went from having around 20 APG PRs to 3.

(Actually, four AGPs made it through: mine, ChainSafe’s, and two of @anteater’s)

What is the process to “finalize” a proposal? This was never specified.

“Finalize” means to make any remaining changes that you want to get your proposal into a final state (exactly what will be voted on the ballot) and as AGP-1 says, “request to move the proposal to Stage V before Stage V is scheduled to begin”. This request has historically been done as a comment on the PR that says something like “this proposal is final, please move it to Stage V”.

There were not even attempts to make such a request for the proposals whose PRs were closed, via any channel or in any way, nor any requests for clarification about this by authors prior to the PRs being closed, and so it can be unambiguously said that they either did not follow the process or expected their proposal to be withdrawn. Either way, closing the PRs was a legitimate move.

Note that this is not new: finalization has been required in every past vote, and has not been an issue until now. I would be interested to hear reasons why it has suddenly become an issue, but am reluctant to accept that it’s because the process is not clear or “specified” because 1) it is definitely specified in the part of AGP-1 quoted in the closed PRs, and 2) if it weren’t clear, I would think this would have come up as an issue before.

I therefore don’t see this as a good reason for pushing back every stage of ANV-4.

In addition to confusion surrounding the process itself, AA put in the bulk of their comments/feedback less than 24 hours before the vote!

Their reviews were as much a surprise to me as everyone else. Given the timing of the provisional review, it’s hard to say whether they were more helpful (because those who were paying attention had time to adjust their proposals), harmful (because those who weren’t paying attention were left wondering what to do with the comments on short notice), or neutral (authors could have simply ignored the comments).

In any case, the AA was not required to issue a provisional review and in my opinion it was better to have it than not at all. I therefore don’t see this as a good reason for pushing back every stage of ANV-4.

In addition to all that, the process of submitting GitHub PRs broke.

This was a weird issue, one I had never seen before in all my years of using GitHub. It’s still unclear if something “broke” on GitHub or if this was a user error. I did not experience the issue myself. I created a support ticket with GitHub earlier this week to get more information about what happened, and have not heard back about this yet.

I think the GitHub issue is unfortunate, but unless the proposal was submitted last minute, it was a solvable issue (as evidenced by the action I took to correct the issue for several proposals). With that said, assuming this was indeed a GitHub bug and not user error, this is the issue most outside of any of our control, and I think it did affect the productivity of several AGP authors, and so this issue may be a good reason to push back every stage of ANV-4.

(Aside: this is possibly also another data point in favor of moving the Aragon community off of GitHub..)


I have my own issues with this ANV that I will air here: I was actually planning on voting “no” on every proposal except my AGP-89 proposal to change the Fiscal Year schedule, as a protest vote, because I am not happy that AGP-61 was not accepted onto the ballot in ANV-3. This rejection by the AA resulted in ANV-4 happening during what I know to be a very busy month in the lives of many active community members (Devcon, Asia tour, extensive personal travel plans, etc). I don’t know if all of this busy-ness played a role in the mistakes made in this ANV but I’m sure for some it did not help. I can speak for myself and say I certainly would have preferred more bandwidth to give the AGP process more attention.

All that said I have not yet made up my mind about whether or not I would support a proposal in an emergency vote to push back every stage of ANV-4. In part because if AGP-89 is approved then the next vote will only be two months from now and (with all due respect to the AGP authors whose PRs were closed) I don’t think any of the closed proposals are urgent enough to disrupt the current schedule. However an argument could be made that the benefit of pushing back every stage is worth the cost of executing an emergency vote and possibly disrupting the vote schedule; I just haven’t seen that argument or good reasons to support it. As I said, I am undecided on this.

1 Like

The “request” step is very bad UX if we’re going to use Github for this process. GitHub already has an existing workflow that carries very valid intent. When opening a pull request, you’re clearly stating the intent that you “request” for your updates to be pulled. If you decide you no longer want your updates to be pulled you close your pull request. If your updates are a work in progress you submit your pull request as a draft.

When the time comes for AGPs to be merged into the AA review process any open pull request that isn’t marked as a draft should carry the intent that it “requests” to be merged. It is backwards to the existing workflow to require leaving a comment on an open pull request that you are requesting for it to be pulled, “request” is included in the term “pull request” for a reason and makes this extra request step unclear.

I’m not saying closing the PRs was an illegitimate move but I do think this process should be changed and I strongly support an emergency vote to push back ANV-4.

4 Likes

I’d also like to add that the “busy-ness” @light outlined is likely related. In the only other AGP I’ve submitted I was asked directly within the PR if my proposal was final to which I responded that is was. I suppose this response was counted as my formal request? I did not realize I was making this formal request with my response but perhaps if members had the time to do that this round more authors would have written qualifying messages.

This is an artifact of thinking of GitHub as a software platform and not as a platform for participating in Aragon governance, for which the workflow is documented in AGP-1.

AGP-1 was written before the drafts feature was added to GitHub. Hence the stated requirement to “verbally” confirm finalization. This step was added so AGP Editors could avoid merging incomplete AGPs.

I do think that if we continue using GitHub for the AGP process we could amend the workflow outlined in AGP-1 to say that rather than verbally requesting to move a proposal to Stage V, drafts could be submitted as “draft PRs” and then changing from “Draft” to “Ready to review”. A proposal in a “Ready to review” state would then be considered finalized.

That’s why I defined it as bad UX, the process is implemented on a platform where an understanding of the workflow already exists and because it goes against that understanding, it’s confusing to users. Prior to drafts, the convention of prefixing your pull request with “WIP” achieved the same functionality. I think any proposal not clearly label as a draft or work in progress should carry the intent that it is requesting to be pulled. It would be better to see incomplete AGPs pulled and filtered by the AA review process than to see complete AGPs (that people have spent a lot of time and effort crafting) withdrawn due to bureaucracy.

2 Likes

AGP-1 does not state anything about “verbally” confirming finalization. A search of AGP-1 (via ctrl f) will confirm that the words “verbal” and “verbally” are not contained anywhere in the document. AGP-1 states:

  • “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.”

AGP-1 states that after community review (which seem to be forum discussions) then the AGP author needs to request that an AGP is moved from stage iv to stage v. A pull request literally has the word “request” in the name! This is also the standard commonly accepted usage of GitHub. Without any further specification in AGP-1, it can only be assumed that the standard workflow for GitHub applies.

If a non-standard workflow that is not native to the platform being used was expected, that non-standard workflow needed to be clearly specified. The terms “finalize” and “request” were not specified outside of the workflow of GitHub. As such, AGPs cannot fail to meet criteria that are not specified in the first place. There simply is not a logical connection between what is written in AGP-1 and what was expected by the AGP editor.

1 Like

Not entirely sure I buy in to this, even though I agree it is a shame that a lot of AGPs were rejected due to misunderstandings/poor timing. What do you interpret “request” and “finalize” as? I interpret it as explicitly stating that you want to move the AGP to stage V by any means.

Right! Exactly! That’s your interpretation. AGP-1 does not provide concrete details on the finalization process, but leaves it up to the reader to interpret what is meant.

  • “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.”

** personal opinion **

I will agree with @jordan and @burrrata on this specific last point, where the AGP-1 document doesn’t have a particularly clear definition of what finalization step is asked of the submitter.

In terms of UX, it seems exceedingly clear what the default expectation and behavior should be: submitting a request does indeed mean the submitter intends it to be final unless there are some comments to it, especially given the fact that the discussions and community feedback are often previously requested on the forum.

It seems to me quite weird that we would want to design a process which is clearly contrary to most people’s both intuitive and reasoned expectations - therefore I would “vote” that all open APG requests that have been opened prior to the commencement of the community review period (aka: submitted on time), shall be deemed finalized by the end of the community review period, and that the AA board review all of them.

I think an emergency vote, with its disruption to the whole process, could be an overkill for such a simple situation derived on a small (ambiguous) technicality, and with no drawbacks, as ANT holders would vote on the issues.

We need to balance usability with process, as I really wouldn’t like to see this governance process become an over-bureaucratized system, which would risk drastically reducing the already low participation - especially as we already have the AA Board review stopgap.

2 Likes

Agreed! :slight_smile:

In the past an AGP has been re-scheduled and pushed back by a week due to expected technical difficulties using the Ethereum network. In this case, there were technical difficulties using GitHub and “legal” difficulties surrounding the language and intent of APG-1 (if Aragon is interpreted as a digital jurisdiction). As in the past, it seems like re-scheduling and pushing things back a week would be helpful to address this. Since we now have a multi-step AGP process, my suggestion is to move every stage back by a week.

The “Emergency Vote” section of AGP-1 states:


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.


If I understand correctly, a vote re-schedule only requires a action by the AA, but not ANT holders. If that is the case, disruption to ANT holders would be minimal. The community would then have time to incorporate last minute feedback by AA members and AGP editors. This would result in higher quality AGPs for the Aragon community. Then, as @stefanobernardi mentioned, there is still the stopgap of the AA to filter proposals before adding them to the official ANV4 ballot. This seems like a win/win for all parties involved.

2 Likes