Threshold
Referendum 911 didn't entail an explicit retroactive second milestone hence it cannot be treated as a "pre-approved" milestone, specially when the original milestone 2 was already presented to OpenGov as non-retroactive (Ref 1325). It seems it was meant to be approved first and then implemented.
Hopefully it can be agreed by team and referendum advisors that opting for a retroactive bill specially when a non-retroactive referendum continuation was already presented (1325) and the new referendum (1499) was unannounced and un-discussed entailed an enhanced risk for OpenGov and the proposer, which is why these retroactive approaches should be considered high risk and discouraged from being commonplace. So better alternatives that align better with the will of tokenholders should be presented to OpenGov instead.
Our rationale for referendum 911 was that continuation approval would be subject to adoption so,
it will still remain as one of the two reasons for the vote in addition to the other, already discussed fact.
Dear Proposer,
Thank you for your proposal. Our first vote on this proposal is AYE.
The Medium Spender track requires 50% quorum and simple majority of non-abstain voters according to our voting policy. This proposal has received five aye and two nay votes from ten members, with two members abstaining. Below is a summary of our members' comments:
The voters expressed a mix of support and reservations regarding the referendum. Many highlighted the need for improvements in the website's user interface and functionality, suggesting features like list views, better sorting and filtering options, and clearer visibility of curators and their bounties. While some appreciated the efforts made, others felt that a stronger alignment with bounty curators and a more comprehensive long-term roadmap were essential. Overall, the feedback reflected a desire for enhanced transparency and usability in the Polkadot bounties system.
The full discussion can be found in our internal voting.
Kind regards,
Permanence DAO
Hello I am Vikk, casting this comment on behalf of the 🌶 Hungarian Polkadot DAO 🌶.
All in all, a well-designed and useful Bounty Manager tool that supports curators in their daily tasks—helping them efficiently track and initiate on-chain actions—is definitely needed.
What we find lacking in this proposal, however, is any indication that this tool is actually being used within the ecosystem. We deliberately waited 20 days before casting our on-chain vote, hoping to see supportive comments from current bounty curators confirming that the tool is needed and valuable, but none has been arrived. Since none of the members of the Hungarian Polkadot DAO are currently curators, we were unable to access the Curator View and, therefore, couldn’t evaluate the usability of this interface either.
Suggestions for the next OpenGov proposal submission:
The best "Ecosystem Fit" is when members of the ecosystem—in this case, the bounty curators—actively enjoy and benefit from using the Bounty Manager. Since we saw no evidence of this in the proposal or in the comment section, our DAO voted Nay, even though we generally support such useful and much-needed tools.
So, we suggest the following:
You can view how the 🌶Hungarian Polkadot DAO 🌶 evaluated this proposal on our public page here.
Thank you for your understanding and wishing you all the best!
We will be voting NAY on retroactive referenda of these characteristics, specifically of high value. To us, it is a better way to outline a plan of action to follow what deliveries were fulfilled and what deliveries were not fulfilled as opposed as this high value retroactive approach which leaves the tokenholders footing the bill
for work that was not approved beforehand. For this referendum in particular, there is a denied precedent with referendum 1325 so any specific changes proposed to OpenGov should have been presented as a non-retroactive referendum presented for approval instead.
So we prefer that well known teams such as these one as well as newcomers to take the non-retroactive route exclusively. This idea will be heavily enforced on our vote starting on cohort 4's term as described on our DV cohort 4 application: https://forum.polkadot.network/t/decentralized-voices-cohort-4-saxemberg/11868