Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Poll Proposal - Draft] Determining consensus on voting outcomes for multiple-choice numerical polls #270

Open
grctest opened this issue Jan 14, 2025 · 10 comments

Comments

@grctest
Copy link
Contributor

grctest commented Jan 14, 2025

Abstract

Gridcoin has had a robust voting mechanism for several years now, with recent hardening and poll requirements definition is has become a trustworthy method of determining consensus on important Gridcoin matters. There is however a recent lack of network/community consensus regarding the matter of how to determine the outcome of multi-option numerical polls, which warrants a discussion and possibly further polling on the matter.

Motivation

The recent poll 'Determining Consensus On Future Staking And Magnitude Rewards' ran into an issue late into polling regarding how we should determine the final outcome of the poll.

In the referenced poll there are multiple numerical poll options, ranging from 100% to 2000%, at of the time of writing this poll proposal the top result has a voting support of 41% where as the other options have a combined 59% voting weight which has split opinion on how to determine the final outcome, whether we should take 100% of user votes into account by performing an weighed average calculation to determine the final reward percentage increase, or whether we should select the a singular top result which in for the referenced poll would result in discarding 58% of user vote weight on this matter.

By fully defining all aspects of the voting mechanism and establishing consensus on these matters, leaving no stone unturned, we harden future polls from issues which have troubled past/current polls.

Rational

Missing poll outcome determination methods in requirements/wiki

The Gridcoin voting wiki and previously voted upon poll requirements proposal lacks details on how to determine the outcome of polls:
https://gridcoin.us/wiki/voting.html
#227

The lack of clarity on this matter has caused upset, especially as discussions on this matter began late into polling.

There is a combination of historical precedent for both sides of this matter:

Without clarity/consensus on this matter, assumptions are being made about the methods of determining voting outcomes based off subjective historical beliefs/standards which are not written down in any guidelines/requirements/wikis; we should consider further possible improvements to the polling proposal requirements to vote upon.

Impacts of both polling outcome methods

First Past The Post

Potential positive impacts

Simpler communication of results - the one top result wins, there are no need for subsequent calculations to determine the outcome.

Potential negative impacts

If we are using FPTP to decide the outcome from a multi-variable numerical poll, then we're discarding votes entirely rather than influencing the final outcome with their votes. The current referenced poll with 41% leading would be throwing away 58% of votes, whilst the currently winning singular option has the most vote percent the rest of the vote options outweigh it yet their collective say had no influence.

If you're aware that one option is winning by a large margin, you're aware that voting on poll options with very little support will have no impact, so you'll be forced to vote for another option which has a higher chance of beating the highest current poll option.

For example if you wanted to vote 10x or 15x but the first and second place options are 5x and 20x you may have to vote 20x to have a higher than 5x outcome despite originally wanting a more moderate reward rate.

Similarly, if you voted for 1x, 2x or 3x but are seeing 20x starting to beat 5x, you'll be under pressure to vote 5x, higher than what you wanted to vote just in order to beat out the 20x vote.

These are forms of tactical voting you're pushed into participating in so that your vote has more than an abstaining influence.

If your FPTP based poll has many polling options then multiple rounds of polling may be required, as the winning option may be a very small percentage due to the large quantity of poll options spreading results around.

Proportional Representation

Potential positive impacts

100% of users votes (aside from abstaining votes) are counted in the end resulting outcome, versus potentially a minority of poll vote weight determining the final outcome (especially if many poll options spread vote weight thin).

Potential negative impacts

If using Proportional Representation to decide the outcome from a mult-variable numerical poll then the variables included within polls will need to be more strictly controlled by the poll requirements, voting wiki and through pre-poll proposal discussions. Arguably, polls with absurd vote options would already be invalidated and disregarded already by both core devs (refusing to implement it) and the eligible voting bloc (refusing to vote it past AVW).

Proportional Representation isn't free from users participating in tactical voting, for example with the referenced rewards poll if you wanted the 5x option to win, with PR the current outcome would be approximately 9.6x so you'd need to vote for a lower option than 5x to drag down the outcome closer to 5x. Likewise if you wanted 10x or 15x to win you may have to tactically vote 20x to offset the 1x (no change) voters.

Specifications

Determining voting outcome for future poll requirements/wiki documentation

Depending on the outcome of the proposed polls:

  • First Past The Post

    • Define FPTP as the method of determining poll outcomes
  • Proportional Representation (Weighted Average):

    • Define PR and the weighted average calculation steps for this poll type in the docs
    • Declare consensus on calculation for converting the result of an existing client poll result
    • Explain the conditions where FPTP would still remain the default (for yes/no/abstain polls).

Documentation requiring an update depending on the poll outcome:
https://gridcoin.us/wiki/voting.html
https://github.com/gridcoin-community/Gridcoin-Site/blob/master/wiki/voting.md

Required blockchain polls

  1. How should we standardize determining the final outcome of multi-choice numerical polls including the recently completed rewards multiplier poll?

    A poll to decide between First Past The Post and Proportional Representation

    • First Past The Post (The highest voted individual poll option wins)

    • Proportional Representation (Calculate a weighted average of all votes to determine the final outcome)

    • Abstain

Discussion

How would First Past The Post affect voting participation?

It's possible that users could be disheartened that their vote was discarded in favour of an overall minority percentage poll option winning over all other options; in effect voting anything other than the winning option is arguably a wasted vote, which could drive voter apathy in the future. This is a well observed IRL voting behaviour, when people feel their vote has no impact they tend to disregard future political polls (e.g. tens of millions of democrats chose not to vote in 2024 despite spending ~$1.5B campaigning - voters lost are not easily regained).

If voting participation lowers enough the impact could be that AVW targets are tougher to meet in the future. Polls can however easily be recreated with longer durations to try again to reach the AVW target (delaying the proposal), or like in the past the AVW could be lowered through a future poll proposal (as has been done before).

Users may recast their ballots to help the 2nd (closest to 1st) poll option to win over the first place poll option if they decide they want their ballot to count instead of having no impact if currently cast against a far-losing poll option - this is likely a one-off recast ballot within a poll if they choose to participate in tactical voting.

How would Proportional Representation (Weighted averages) affect voting participation?

It's likely that users are to cast their ballot multiple times over the course of a poll, to tactically vote as opposed to a one-off recast ballot under FPTP. A greater quantity of cast ballots would contribute additional fees to network key stakeholders.

It's possible that users who thought FPTP would be used could be dismayed by the outcome being different than the top voted poll option, however this could drive them to increase their participation in the poll proposal/discussion system in the future and increase the quantity of higher quality polls in the future. With regards to the referenced rewards poll future changes to the rewards multiplier would not require a mandatory client upgrade and so would face fewer hurdles between proposal and implementation - these changes should not be considered set in stone unlike the network properties of Bitcoin for example.

Which historical polls have had multiple numeric options?

For reference the poll which led to this draft proposal:

Title Creator pre polling discussion duration URL
Determining Consensus On Future Staking And Magnitude Rewards grctest 72 days link

The following polls are the new version, their stats can easily be tracked:

Title Creator pre polling discussion duration URL
Treasury And Mandatory Sidestaking Structure Poll j-ringo 6 days link
Grc To Create A Poll Aurum420 ? days link
Mrc-fee Treasury Split Poll j-ringo ? days link

The following polls are an older version, manual TXID parsing is required to parse the outcomes:

Title Creator pre polling discussion duration URL
Boinc Workshop Reimbursement Poll - Outreach jamescowens ? days link
Cbr/research Rewards Rate N/A ? days link
Constant Block Reward (cbr) Proposal And Poll jring_o ? days link
Meta Poll : What Is The Minimum Vote Weight That Should Be Required For Mandate Behind A Poll To Be Valid? erkan 7-188 days link
Poll Mechanism : Should There Be A Minimum Vote Weight Required For Foundation Polls? erkan 4 days link
Vote On Grc Mumble Hangout Reward Distibution And Payment grctest 13 days link

The following polls used an average of the results to determine a fairer outcome to all participants:

Title Creator pre polling discussion duration URL
Vote Weight Rebalancing Cruncher Poll grctest 388 days link
Vote Weight Rebalancing Investor Poll grctest 388 days link

Summary for stakeholders

Existing Gridcoin Users

You won't need to remember Gridcoin's 10+ years of history in order to decide how to evaluate poll outcomes.

Additional poll requirements documentation will improve your future proposed poll quality.

This proposal is a proposal for rules documentation definitions/changes, depending on the outcome a leisure client update could be in scope (likely both GUI and CLI) in the future.

You may need to change how you vote on multi-option numerical polls in the future, depending on the outcome of the proposed poll.

New Gridcoin Users

You won't need to look far back (10+ years) into Gridcoin's history in order to determine what the outcome of a poll will be.

Exchanges & Services

Voting stats websites may need to calculate weighted averages to show the final result, however this is primarily a documentation change proposal.

See Also

#19 (comment)
https://steemit.com/gridcoin/@erkan/gridcoin-poll-how-should-we-interpret-the-outcome-of-a-poll-vote-until-march-29
https://www.mixcloud.com/gridcoin_hangouts/ (several hangouts remain during the first FPTP/PR poll duration - numbers 25, 26 & 27)

@barton2526
Copy link
Member

I really do not think the conjecture on price and voting is adding anything to this proposal. You are neglecting to mention that almost the entire crypto market had huge gains in 2017. There are far too many variables to say the CBR poll affected the coin's price.

@grctest
Copy link
Contributor Author

grctest commented Jan 14, 2025

It's included as a side discussion, it's not highlighted as part of the primary motivation/rationale for the proposal; price action is mentioned in the other proposal's discussion section too (comparison to doge).

I'd be interested to hear counter arguments as to why having your votes discarded under FPTP does not degrade your perceived value of GRC if your vote doesn't influence final outcomes. I find plenty of people IRL have completely given up on politics because they feel their vote has no impact, so I wouldn't say it's a non-factor, just not the complete picture.

If individuals feel disheartened by their vote not having a say, that could have an impact on their decision to hold GRC. People buy/sell emotionally all the time, it might not be wise but that's what hedge funds have preyed on for decades now.

If the whole crypto market increasing was the cause, then why have similar rises not occurred in previous and current cycles of BTC reaching new all time high prices? With BTC hitting $100k we aught to try and sus out what has been holding GRC back, no matter how small/insignificant it may be perceived as being.

Whilst I may have neglected to include that, it's currently a draft and we're discussing it in the comments here, all inputs will be reflected in the final version prior to any poll being created, I welcome all input on this proposal as a whole.


Added some extra info in that segment to reflect your input @barton2526

@GRC-Sparrow
Copy link

GRC-Sparrow commented Jan 20, 2025

First, the whole section on “Was there a direct influence on the market cap based on indicated PR/FPTP usage in GRC's voting system?” is irrelevant so I will not be engaging with it. Including it “as a side discussion” is unnecessary and, to piggyback off what barton2526 said, it ignores external market factors, mandatory code changes, and how the community has evolved over time.

With that said.

Weighted voting can be gamified by the poll creators and the voters. This creates a serious problem. If we take the answers:

100 * (W 0.05) = 5
500 * (W 0.40) = 200
1000 * (W 0.10) =100
1500 * (W 0.15) = 225
2000 * (W 0.30) = 600

We get a weighted result of 1130 which is higher than what 55% of the users wanted.

If we change the answers ever so slightly, we change the outcome

200 * (W 0.05) = 10
500 * (W 0.40) = 200
1000 * (W 0.10) =100
2000 * (W 0.15) = 300
2500 * (W 0.30) = 750

Weighted result = 1360

OR

100 * (W 0.05) = 5
200 * (W 0.40) = 80
300 * (W 0.10) = 30
400 * (W 0.15) = 60
500 * (W 0.30) = 150

Weighted answer 325

To the average voter these may all seem like very reasonable options on a well-crafted and reasoned poll, but this gives a lot of power to the person generating the poll; It creates a situation where the answers themselves can be carefully crafted to generate a desired outcome. This also creates a situation where people may try to swing their vote wildly, by choosing an extreme position, to balance out the final answer. In the end, no one wins. A system with unnecessary complexity is created that generates confusing results and alienates its users.

One answer of -100 or 5000 could have wildly swung the outcome in either direction.

Weighting the answers also invalidates the current poll as the option "100% (no Change)" was designated to be “the same” as an Abstain vote; Weighting those answers changes how the math works. If there would have been an Abstain and 100% vote it also would have altered the numbers.

jringo, using First Past the Poll in their example, explained this very well on Discord so I’ll quote them here:

Let's say:
The "no change" is considered the "abstain" option
There must be: 1,000,000 vote weight for a poll to be validated.
There is 450,000 vote weight on the option for 1000%.
There is 350,000 vote weight on the option for no change.

This means:
There is 800,000 vote weight so far.
Option for 1000% increase is winning.

Now:
Someone wants to ensure the poll is validated.

So:
They put 200,000 vote weight on "no change"

This means:
There is 1,000,000+ total vote weight, poll is validated
450,000 on option for 1000%
550,000 vote on option for "no change"
"No change" wins, even though the validating party did not want to sway the vote in any way.

That same logic has even greater consequences when one considers that Abstain means: to choose not to vote. By choosing anything in the second poll a person is altering the weighted answer’s outcome, not just putting their support toward validating the poll. That disincentivizes people to vote in the second poll. Words have meaning and if this is how the vote is going to be interpreted then I would argue the poll is invalid, and cannot be used in a set of polls, Per what was written on the official website when the polls where created: https://gridcoin.us/wiki/voting

Especially since a vote, once cast, cannot be retracted.

Ranked voting fixes all this, making it so all users can vote with their heart first and then move on to what their preference would be if their choice was eliminated.

If we take the first example again:

100 * (0.05)
500 * (0.40)
1000 * (0.10)
1500 * (0.15)
2000 * (0.30)

500* is winning but doesn’t have over 50% consensus. In this scenario 100% has the lowest winning percentage so they would be eliminated from the results allowing for their second choice to kick in. Even with that 500 still can’t have a consensus, so the next lowest after second choices were accounted for would kick in… And on and on until a consensus that would make the majority content is found.

That’s not the voting system currently in place. The reality is, only two votes matter.

  1. The Developers maintaining the project
  2. The User who adopt their code changes.

While polls are nice, one of the reasons I didn't speak earlier during development debates on github is I felt unqualified to speak on the forum. The polls are a great way for the developers to get feedback from the community about proposed changes. I’m not, nor do I have the skills to be, a project maintainer. Recent events, specifically this situation, is starting to change my point of view on that matter; So here I am.

I can say that discussions about this, and the polls that brought about this situation, have been destructive in my trust in Gridcoin and the projects direction. Previously I would vote in most polls just because “I could” and thought it was a fantastic idea to support the process even if I didn’t necessarily agree with what was presented.

Moving forward I’m less likely to vote for any poll unless I agree with what is being proposed, can validate the motives of the person creating the poll, can validate how the results of the poll will be processed, and can confirm the major contributors to the project are on board with the proposed changes. Trust is everything and stirring the pot like this, so close to the polls closing, does nothing but erode trust in the project and the system it's designed to support.

Unfortunately, this situation says to me “a small, vocal, minority didn’t get the desired outcome they wanted so they are trying to alter how the results will be interpreted after the fact.” I have many more thoughts, but, as I am late to speak out on GitHub and Reddit, have truncated it to this specific discussion thread.

@grctest
Copy link
Contributor Author

grctest commented Jan 20, 2025

First, the whole section on “Was there a direct influence on the market cap based on indicated PR/FPTP usage in GRC's voting system?” is irrelevant so I will not be engaging with it. Including it “as a side discussion” is unnecessary and, to piggyback off what barton2526 said, it ignores external market factors, mandatory code changes, and how the community has evolved over time.

I can appreciate your sentiment, people should base their decisions primarily from the motivation, rationale and specifications sections, the discussion section includes both positive and negative aspects, you're welcome to not engage with the negative aspects of first past the post, however without engaging further on these matters the content may not improve to address the points you raise.

I wouldn't say it ignores these factors, given that it was updated after barton's comment to reflect his comments, however you agree that CBR mandatory change which used FPTP was a contributing factor?

Weighted voting can be gamified by the poll creators and the voters. This creates a serious problem. [...] One answer of -100 or 5000 could have wildly swung the outcome in either direction.

I'd expect bad quality poll options to be called out and rejected in the poll discussion phase. It's a good thing that -100 nor 5000 weren't included poll options then, because they'd have been absurd poll options to use.

Lowering the rewards was not in scope of the referenced poll, and 25x+ was highlighted as excessive so the poll was limited to reasonable ranges.

This also creates a situation where people may try to swing their vote wildly, by choosing an extreme position, to balance out the final answer. In the end, no one wins.

Both first past the post and proportional representation have their own tactical voting which can occur throughout the polling period, as mentioned in the rationale section. Continuous voting is a good thing, it means people are both using the blockchain and spending fees which go to good causes. I don't see tactical voting as a 'nobody wins' situation.

A system with unnecessary complexity is created that generates confusing results and alienates its users

I'd argue that FPTP similarly alienates users, especially when 59% of votes are discarded, taking only 41% of votes into account for an important matter.

That same logic has even greater consequences when one considers that Abstain means

The topic of abstaining should be reserved for the other issue as it's out of scope here.

If there would have been an Abstain and 100% vote it also would have altered the numbers.

Doubtful, abstaining in the other poll is only at 1.66% so the impact would be quite small.

That same logic has even greater consequences when one considers that Abstain means: to choose not to vote.

They already had the perfectly valid option to choose not to vote - abstaining in the process, as the poll didn't require 1.66% to reach the minimum AVW in the end.

Especially since a vote, once cast, cannot be retracted.

You can vote again, overwriting your previous cast ballots, as many times as you want.

Ranked voting fixes all this, making it so all users can vote with their heart first and then move on to what their preference would be if their choice was eliminated.

This is mentioned within the discussions section if you want to do the math on the overhead this would introduce.

Fees would need to increase for voting, and a considerable amount of change would be necessary both in wallet and in external services to support ranked voting.

That’s not the voting system currently in place. The reality is, only two votes matter: The Developers maintaining the project & The User who adopt their code changes.

With this sentiment why are you upset at all about anything relating to the voting system? You would prefer to revert to a benevelent dictator project structuring rules when the times get mildly disruptive?

I can say that discussions about this, and the polls that brought about this situation, have been destructive in my trust in Gridcoin and the projects direction.

Sorry to hear that, however with 93% of voters voting in support of the rebalancing poll, and 94.5% of voters voting in support of raising the rewards (regardless of how much), your sentiment does not seem to be shared by everyone else.

I'd remind you that Gridcoin is a trustless system, with no roadmap and no warranty of any kind, user discretion is advised.

Moving forward I’m less likely to vote for any poll unless I agree with what is being proposed, can validate the motives of the person creating the poll, can validate how the results of the poll will be processed, and can confirm the major contributors to the project are on board with the proposed changes.

Excellent, proposals are open to such participation and engagement, the last proposal was open for discussion for 72 days to accommodate such actions by network stakeholders.

Blindly voting is inadvisable, it's why rewarding voters would be inappropriate - because people would vote without doing their basic due diligence.

If you choose to elaborate on these matters within the scope of this thread, their points will be included in the draft proposal after a period of time.

Trust is everything and stirring the pot like this, so close to the polls closing, does nothing but erode trust in the project and the system it's designed to support.

The discussion regarding rewards polling is in the other thread: #268

I'd say though that you shouldn't be letting the actions of one user on the blockchain change your beliefs in the blockchain itself, however remember this is a trustless system by design (trust is literally nothing), further Gridcoin is massively separated from BOINC, what happens in/to GRC does not reflect on BOINC itself (by design).

Unfortunately, this situation says to me “a small, vocal, minority didn’t get the desired outcome they wanted so they are trying to alter how the results will be interpreted after the fact.”

So you believe there's nothing that can be changed nor improved upon within the voting guidelines, and that there's no need to define standardized methods of determining polling outcomes, where none exist before? That past polling on this exact matter was right to be discarded?

You are free to believe what you want, but that doesn't mean it's reality - the desired outcome was for a rebalancing and a rewards increase and both seem to be happening, pretty sure it seems like the desired outcome from both proposals have in fact been achieved :)

If you feel upset by the outcome of polling then future changes to the rewards will not require a mandatory client upgrade, thus there would be fewer roadblocks between you and achieving what you want, if you can follow the polling guidelines, make a good proposal and net sufficient AVW.

In the mean time, this poll means there will be a buffer between the mandatory and rewards increase, so we'll see what effect both proposals have in the end, and we'll have achieved consensus on this matter to boot.

@jamescowens
Copy link
Member

A few comments on this discussion so far:

  1. We DO need to clarify the interpretation of poll results.
  2. The mode of poll results should be specified in the poll write-up so as to prevent confusion. We should create a poll that cements this requirement in the poll standards.
  3. We do not have the resources to implement ranked choice at this time
  4. Any new poll discussion meant to qualify a poll should clearly state how the poll results will be interpreted
  5. For the specific poll that resulted in this discussion, namely "Determining consensus on future staking and magnitude rewards", we need to do a follow-on poll to get the community to opine on how the results are to be interpreted. This poll should have an abstain option.
  6. The change in Gridcoin market cap and the interpretation of polling cannot be linked via causation. Any correlation is by chance, as there were many underlying changes in the market conditions.

@grctest
Copy link
Contributor Author

grctest commented Jan 22, 2025

What about a middle-ground option of if a single vote option gets 51+% of participant vote weight that it uses first past the post to determine the outcome, otherwise it would be determined by an average weighting?

If there's many poll options then perhaps a second round of polling between the top results with the 51% vote option otherwise proportional represented weighted averages are calculated?

Gridcoin core has a limit of 20 poll options, it may be less likely that a 51% vote weight is achieved from a 20 poll option poll versus a second round of top 5 voted poll options from the first poll.

This upcoming poll is likely to also have a different vote weight distribution, the magnitude vote weight increase is quite substantial.

@GRC-Sparrow
Copy link

GRC-Sparrow commented Jan 22, 2025

It would be reasonable for people who have been around for a few mandatory updates to assume that the current poll for determining the reward increase would be FPTP based on similar issues polled within the last 5 years; for example MRC distribution:

https://www.reddit.com/r/gridcoin/comments/t0jx57/mrcfee_treasury_split_poll/
#250

To bring up weighting the results of the current poll, towards the end of the process, after the decision to make tandem polls were made, is where the controversy lives. Just like having values in the poll that where “out of scope” and “absurd” should be called out, so should changing the meaning of the vote towards the end of the polls closing; That should be called out and rejected by the community.

We shouldn’t be turning the Gridcoin polling system into an E-Bay style auction where people gamify, and automate, decisions at the last moment to manipulate the outcome.

Polling should be simple, inclusive, actions used by the dev team to guide their decision-making process and form a consensus around changes.

Clarifying how future poll results will be interpreted is fine. Needing to use a follow-up poll to determine the meaning of the current poll should invalidate it altogether.


I don’t see a middle ground in this situation between a re-poll or using FPTP. There were two polls to show flexibility to the system. That flexibility was abused to try and manipulate the poll result.


Since anyone can technically make a poll if they have enough GRC in their wallet, May I also recommend that the community clarify that for all future Protocol Development & Governance polls to be considered valid they must come from the foundation address or by a developer found on the https://github.com/orgs/gridcoin-community/people at time of polling?

@grctest
Copy link
Contributor Author

grctest commented Jan 23, 2025

Needing to use a follow-up poll to determine the meaning of the current poll should invalidate it altogether.

Interesting ideas, do consider throwing together your own protocol proposal on this matter to be voted upon if you feel this way.

If anyone talks about making a poll following up on any other poll topic, you believe the prior poll should be invalidated? Does that apply to all? Because in that case multiple past polls would be invalidated by the two recent polls as they alter the outcome of both then?

IMO having another poll on the final outcome is beneficial, we get to test out the new vote weight system and can push back rewards boosts away from the mandatory which has its own large changes, whilst concluding on what final result people want from the prior poll which failed to achieve a 51%+ polling option.

That should be called out and rejected by the community.

I appreciate your input, best of luck creating a poll proposal on this matter. At the moment there are no such poll requirements/rules which cover such actions, there's effectively no polling rules aside from the poll listing requirements, nor any established code of conduct.

I don’t see a middle ground in this situation between a re-poll or using FPTP.

OK, so you don't want the suggested combined FPTP+PR option idea to be included, just FPTP vs PR? Understood.

There were two polls to show flexibility to the system.

There were two polls because one had scope of the rebalancing, the other had scope of rewards increase size solely.

Both passed AVW and participants voted in support of both (implementation and raising rates) overwhelmingly.

May I also recommend that the community clarify that for all future Protocol Development & Governance polls to be considered valid they must come from the foundation address or by a developer found on the https://github.com/orgs/gridcoin-community/people at time of polling?

Interesting, however you do realize my account is in that developer list too?

Since your account is not in the list, would you not feel being excluded by such a difficult barrier to entry? Commenting in issues (and in discord) doesn't count towards being included in the list, you'd likely need to work on one/several Gridcoin GitHub projects for a few months to be included & list inclusion isn't an automated matter neither. There's only 35 people on the list so far.

It'd probably be easier to increase the min grc to create a poll to 1 million+ GRC instead in the wallet, versus users trying to work to join the org.

@GRC-Sparrow
Copy link

Whether or not https://github.com/grctest was in the organization list found here: https://github.com/orgs/gridcoin-community/people or not was not why I made the suggestion. If we are making changes to how the community understands https://gridcoin.us/wiki/voting.html then we should add the requirement that only those capable of making changes, understands what is required in altering the code, and is currently recognized as a primary contributor to the project, should be able to make valid polls in regard to all future Protocol Development & Governance items. It should be clearly written in the documentation so no one 5 days, or 5 years, from now can try to "force" changes and cause a rift in the community.

And You're right; technically all fees, not already based on a percentage, should go up by the percentage of reward increase to account for the added inflation. If 500% ends up winning, then currently the minimum balance to create a poll should increase from 100K to 500K. The cost to create a Poll is 50, so that would increase to 250.

With the Added inflation rate, unless demand and circulation drastically increase, there will be a lot more people able to earn 100K of GRC or purchase 100K of GRC in a short period of time. At the moment it looks like there are only (508?) wallets that can generate a poll. I'd imagine that would increase quickly year over year, so raising the threshold is warranted.

@grctest
Copy link
Contributor Author

grctest commented Jan 23, 2025

The AVW poll validation requirement creates a substantial barrier for proposed changes which could cause a rift, eg if nobody votes on the matter it's not binding to begin with, so absurd polls created by spammers can be ignored and will by default be invalid.

Nobody can force through any change from the outcome of polling, say for example someone with no coding experience proposes a change back to POW (or another heavy core code change), it's simply not going to happen if they lack core developer support, don't have the ability to code themselves nor if they are unable to contribute code to the main gridcoin-research github repository.

I would also remind you of the influence the core contributors have when they vocalize which voting option they support, for example one poll option gained substantial vote support after developer analysis, so polls & poll options which may cause rifts are less likely to pass/validate already.

Mind there's already a 42 day vote period and a higher AVW requirements or protocol poll topics, that's higher than the other categories, there's also no defined time to implementation requirements/expectations in either of the proposals rushing anyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@jamescowens @grctest @barton2526 @GRC-Sparrow and others