you are arguing with worst case scenarios which isnt very helpful. also if the popularity of xgov grants rises significantly we could change the rules again
And you are not arguing with any arguments.
This way people who has funds will become xgovs and will fund their own projects. Noone else will get the opportunity to get the funds for their ideas.
people saw something in the last xgov period that they didnt like thats why they are against the reserve list. they dont need any arguments besides that they didnt like that.
is no reserve list scalable in the long run? probably not but at this moment it seems like there isnt enough demand
The pilot is the right time to experiment @scholtz. We donāt want hundreds of proposals right not, whilst we are still building. The objective of the program is to distribute Algo to the proposals that the community like, not distribute all Algo every time.
Voting session 1 success rate was pretty bad, because it lacked participation. We needed a mechanism to distribute Algos in case the big wallets didnāt show up again.
However, voting session 2 passed 10X the amount of Algo allocated in voting session 1, including 2 proposals above 100K A. This showed us that quality proposals can pass.
If you had only one proposal, it couldāve passed too.
We will not rename the reserve list, at this point, nor change the algorithm.
Weāre inclined to pause it for voting session 3 and see what the vote, as originally designed, can do when more people participate.
I think the idea behind the reserve list has a point: projects that missed āfor a few votesā are different from projects that were completely ignored. Since the current mechanism favors ādispersion of votesā (because you can vote only one project with 1 algo), itās suboptimal to prevent projects that miss a few votes to be funded. Moreover, the more projects will participate the more vote dispersion will happen. In retrospect, 60% may be was too low, but the idea behind it can still be effective with a higher percentage. Obviously the definition of āfew votesā is somewhat arbitrary. As we are seeing already in this discussion, everyone sees it differently, so why not ask a proper poll, including the choice of 100% (which is equivalent to No reserve list)?
i could support 90% reserve list, with a max cap.
Vote dispersion is an issue, but itās an issue of the future and tbh, i donāt think weāll see it before we see hundreds of rpoposals being postedā¦ For now single entity proposed one or two porposals(with some exceptions), so if they managed to engage xgovs they got ther proposal passedā¦ becase there were plenty of votes to go around.
Right now reserve list does not serve a function itās supposed to serve - e.g. compensate for vote dispersion. It would only work when there is more demand than there is algos available e.g. when tehre is a lot fo interest for the funds from reserve list.
I think where the biggest issue is there has been a lack of push for xGov by the people in charge and the council. Community should step up but a lot of them donāt even know how to get started.
A lack of participation will equal bad results for a āreserve listā.
I have just created a poll to try to reach a consensus on the particular percentage to be adopted for the Reserve List in the next Voting Session.
Please participate in the poll here.
Spread the word, so we can make a decision based on a robust number of participants.
Agree ! No reserve list for me as well.
As i have suggested, disable voting for already passed proposals in a session.
This will make the voting process more efficient.
There is no point in giving extra votes for already passed proposal.
Also keep a Null proposal to which people can vote if they donāt like any proposal. Abstract of Null proposal should explain what it is.
100% agree.
To add to that, we should make it so if someone weāre to allocate more than necessary it should split the difference.
For example, i try to put 100% of my voting power on a proposal that only needs 60% to pass, it should notify me and adjust the amount Iām voting towards it automatically.
fyi ā the 60% reserve list is a thing of the past - rn itās being voted on 90%, 95% or no reserve list
regarding the UI, iāve suggested a āslider/dragā approach on the UI, which visually shows you that you either used up all your voting power, or the proposal already passed and you donāt need to allocate more.
Doing on the fly caluclations about % allocation on 50 different input boxes is a UX nightmare as is atm(especially if you wish to allocate 30% to proposla on top of the list and 20% to one in the middle and spread the rest between 3 others).
Donāt really expect the change to be done on time, but if it will be, the AF xgov team will earn a whole bunch of respect in my mind.