Thanks for the explanation @Luka. Unfortunately, it appears the CodeGov neuron has reached consensus on all three proposals already and our vote has been cast.
It appears we made the incorrect choice for proposal 128086 because we voted to adopt. I will summarize the reviews later when they are all complete, but I suspect that none of us realized that the second url is a fallback url. I don’t recall the functional purpose of it being discussed in the past among our team. I do recall thinking it was odd that there are two release package urls and that they are the same url, but never realized the payload actually needs both. I now realize this is something that I should have asked for clarification about previously, especially since it is information in the payload. Fortunately, DFINITY can and will still reject this proposal.
We voted to reject 128087. I would have been uncomfortable adopting 128087 anyway since the summary is not accurate due to the copy/paste error you described (the wrong change log since git revision and the claim that it implements the p2p for consensus). Hence, I’m glad we did reject that one in this case.
At this point, my suggestion is that both 128086 and 128087 should be rejected and a new proposal submitted to correct the issues.
Our vote on proposal 128086 highlights a flaw in how the CodeGov neuron is set up. We’ve known about this issue and have plans to mitigate it programmatically in the future. We are building an app that we will use as our primary tool for submitting reviews, summarizing results, casting votes, paying bounties, and keeping records. We are currently calling this the GaaS App (Governance as a Service), which will be open source for anyone to copy and will also be designed for other organizations to use off the shelf independent of CodeGov. Anyway, the voting mechanism that we plan to implement will account for the issue we experienced here where a small minority of reviewers identify an issue with a proposal that justifies a reject from the CodeGov neuron, but too many other reviewers have already cast their irreversible votes. Since our reviewers are configured as Followees for the CodeGov neuron, we currently cast our vote according to the consensus rules built into every neuron. A better approach would be for us to wait until all reviewers have completed their work and cast a vote after evaluating all information that comes from our reviews. It’s a more complicated voting mechanism to do it programmatically and we don’t have that feature available yet. We could do this manually at this time, but so far have elected to stick to automatic voting. It’s something we should reconsider based on this result.
