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

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

I’ll provide my position shortly after checking with @light, but I will say that I would like processes that work for the community and not the community working for the processes.

At the same time, we should always strive to not create negative precedents that break the rule, and so this is a hard balance. Will circle back shortly.

2 Likes

Agreed! The only way this can happen is if the community engages in the process. Considering that the process did not work for the majority of community members who engaged, it would make sense to adjust accordingly.

Agreed! In this case, however, there are no rules being broken. The AGP process is not being modified in any way. Rescheduling an AGP is within the framework of AGP-1, and that framework exists to serve the Aragon community. The AA has the ability to re-schedule a vote, and has done so in the past due to technical difficulties. ANV4 has also experienced technical difficulties. Rescheduling ANV4 (by 1 week) would allow all parties involved to participate equally, resulting in better AGPs for ANT voters.

Thinking this through and it doesn’t quite make sense. @light alright provided an opinion on this topic in this thread. What more is there to check?

I hear and understand the feedback from AGP Process participants on this thread that the workflow around Stage IV finalization is counter-intuitive to those used to the established workflow of the platform used for Aragon Network governance (GitHub). I have proposed an errata fix (not requiring a vote to implement) with the goal of bringing the workflow more in line with how people are used to using GitHub. I welcome your feedback on this proposed change:

@burrrata @jordan @lkngtn @stefanobernardi


In terms of how to proceed, irregardless of the outcome with the above PR, after thinking about this some more I agree with other comments in this thread that the fact PRs were “broken” for some people and unable to be fixed before Stage V was scheduled to begin is reason enough to justify rescheduling the vote (which would automatically push back the other stages of the vote cycle) so that authors can properly prepare their AGPs for finalization. As has been pointed out, this can be authorized by the AA without any further action by ANT holders necessary.

@luis @jorge


I still have not heard back from GitHub about the cause of the “unknown repository” issue. A quick search of the internet suggests this happens when the “fork” repo that the PR is being merged from gets deleted. I’m not sure if this is what happened with the PRs in question. Could the affected authors confirm if they remember deleting the source repo that their AGP PRs were being merged from while the PRs were still open? @burrrata @anteater

4 Likes

The AA has voted to approve a delay. Announcement here:

2 Likes

Since every stage of ANV-4 has been pushed back by one week, I have re-opened the PRs that were closed last week, with the exception of the PRs that were affected by the “unknown repository” issue. @burrrata some of yours are the only PRs that remain closed. Please try to create these AGPs as new PRs and if they are affected by the unknown repositories issue again then we’ll try and figure out how best to proceed from here.

1 Like

I did not delete the source repo that AGPs were merged from while the PRs were still open. I also followed the same process for all PRs besides the 1Hive sponsorship proposal, so it’s unclear why some worked as expected and some did not.

Will do. Thank you for the update.

Thinking it through and this is still not intuitive… A pull request is a request to merge something into the repo. An Issue is where discussion around ideas happens. Why not just make Issues in the AGPs repo where proposals in stage III and IV go, and then have PRs be where people submit finalized proposals ready to be reviewed by AA and merged into the AGP repo if approved by ANT holders? That would make way more sense.

I second this.

I think a PR is by its definition a finalized state.

I’m not sure I’d want GH issues clouding the process even more as we have the forum for those phases, but that could work too.

1 Like

A pull request is a nice place to collaborate because people can make suggestions directly into the content itself, and these suggestions can be discussed and either be merged or rejected by the author directly in the pull request.

I think having the workflow I am proposing where PRs are either submitted as drafts or clearly marked as drafts, and any PR that isn’t marked as such is considered final, is a fair compromise between my motivation for using PRs due to ease of collaboration and others’ concerns about PRs being misunderstood as being final submissions.

This is a really good point that I did not take into consideration. Having just gone through this process, it was really nice to just be able to click a button to incorporate edits.

So then people would mark AGPs as drafts, but then once that draft marking is removed they would not have to perform the additional step of commenting that a proposal is “finalized / ready to review / please move to stage V” comments?

Correct, the specific wording in my PR says:

After a proposal in Stage IV has been thoroughly reviewed, you may finalize your proposal by making any final changes and mark the pull request as “Ready to review”, changing the draft pull request to a ready pull request. If you do not finalize the proposal and change the pull request from “draft” to “ready to review” before Stage V is scheduled to begin, AGP Editors will consider the proposal withdrawn and close the pull request when Stage V begins.*

* If the draft proposal was submitted as a ready pull request with [DRAFT] in the title as required in the Stage IV section above, then [DRAFT] should be removed from the title when the pull request is finalized and ready for review. If [DRAFT] is not removed from the pull request title before Stage V is scheduled to begin, then AGP Editors will consider the proposal withdrawn and close the pull request when Stage V begins.

What if someone submits a PR before the community review stage without the DRAFT marking? Would it be rejected from community review or would it go through?

Again quoting from the PR:

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

* If a draft AGP pull request is accidentally submitted as a ready pull request instead of a draft pull request, the author should put [DRAFT] in the title of the pull request.