Opened an Issue in the Aragon AGP GitHub repository to formulate the ideas in this thread into a cohesive call to action:
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.
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.
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.
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
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.
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.
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.
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.
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.
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 **
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.
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:
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:
- The Emergency Votes folder
- Aragon Network vote alerts newsletter
- #announcements channel in Aragon Chat
- @AragonProject Twitter account
- Aragon Project LinkedIn account
- /r/AragonProject subreddit
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.
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.
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:
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.
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
The AA has voted to approve a delay. Announcement here: