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

published proposal about polls #17

Open
Erkan-Yilmaz opened this issue Jan 21, 2017 · 29 comments
Open

published proposal about polls #17

Erkan-Yilmaz opened this issue Jan 21, 2017 · 29 comments

Comments

@Erkan-Yilmaz
Copy link
Owner

Erkan-Yilmaz commented Jan 21, 2017

gather criteria, e.g.

  • how long should a poll last ?
    • based on type of poll
  • see hangout 2: a poll shall not acted upon before it ended
  • minimum balance/magnitude participation required ? (see also hangout 3: 2:15:39)

and later let community vote on these

mentioned in hangout 2: see WuProp section

@grctest
Copy link

grctest commented Jan 21, 2017

14 days for a whitelist poll (unless there's proven evidence of issues requiring a more prompt removal from the whitelist).
7 days for a casual/fun poll.
21-28 days for an expense?
I was thinking that for technical polls regarding development direction we should make polls which last two or three months to bring as much attention to the subject as possible? Is there a maximum poll length?

@Erkan-Yilmaz
Copy link
Owner Author

another question about:
whitelist poll:

  • e.g. recently, CPDN was voted out due to a reason.

If that reason was fixed, and no other issues would exist. Still 14 days ?
May become less relevant when greylisting comes (task #6)

@grctest
Copy link

grctest commented Jan 21, 2017

Yeah, I'd say that CPDN's situation where it was not exporting statistics correctly should remain 14 days, less than 14 days for projects that are hacked & distribute malware or something equally bad.

If a project fixes an issue before the end of the whitelist poll, it shouldn't invalidate the poll. They should have to campaign for being whitelisted again, this amount of bureaucracy could be reduced via the theorized grey listing mechanism.

@Erkan-Yilmaz
Copy link
Owner Author

added above: "minimum balance/magnitude participation required ?"

@Erkan-Yilmaz
Copy link
Owner Author

Erkan-Yilmaz commented Jan 22, 2017

Should investors be able to vote on whitelist project removal/addition ?

chat excerpt:

xXUnRealXx: So I have a seriour question / concern. The POLLs that are created for projects SHOULD NOT allow INVESTORS to VOTE. Theres 2 INVESTORS with Lots of PULL Voting to REMOVE Projects Yet they do none of the work.

Gunde> INVESTOR could be users that still does boinc but use an investorwallet.
Gunde> some user do use both part an split wallets
Gunde> INVESTOR still have interest to health to gridcoin and to do it better
Gunde> It could be do to security and be anon to split it
Gunde> No trackback when vote is one part other is to not get a track of ip or other info as mail

xXUnRealXx> if so than a 51% attack is eaven easier then they say it is
Gunde> As cm point out the lost grc that is not staked is biggest issue not those investors that vote today.
Gunde> There is no trackback as they are infisible today, make POSv3 would be best or even make a sytem to burn after limit as it is so high amount of hidden coins.

@47an
Copy link

47an commented Jan 22, 2017

If no exporting of stats is done or the RAC reached below 100 from users it would be de-listed auto do to how NN works. This happend before and Denis/MindeModeling/CPDN have show that it will be out. This could be used as a grey-list but today the time is to long to use for this. Solution could be to set rules to NN to keep rac in NN in shorter timerange.

If projects that are hacked & distribute malware we should be able to shutdown reward without asking or use poll for it as it mainly bad and would hurt not only Gridcoin but boinc community it self. Same rules as to community platform or wallet or site we use we would not ask to act to protect these.

@grctest
Copy link

grctest commented Jan 22, 2017

Should investors be able to vote on whitelist project removal/addition ?

Yes, I believe that investors should be allowed to vote on project whitelist removal/addition.

  • It encourages project owners/volunteers to buy GRC to keep their project voted into the whitelist.
  • It increases the security of the whitelist, pools would otherwise be able to vote projects in/out at will.
  • If a bad quality BOINC project is voted into the whitelist which results in negative press or damages team Gridcoin's computer environment (malware) then the value of GRC could decrease which would affect an investor.

@grctest
Copy link

grctest commented Jan 23, 2017

RE: Technical polls --> several month long poll & a minimum vote weight required of 50% before a change can pass? This way, low stake weight participation in a poll does not allow mandate for change to be valid without a majority of the network agreeing with the proposal.

@barton2526
Copy link

Idea: Foundation Expense polls should require a minimum voting weight of the community in order to be considered binding. I suggest 10% minimum. Current active foundation poll activity is:

  • 9.4% for Faucet fund
  • 3.8% for AdWords Campaign
  • 3.2% for Hangout Expenses

@NeuralMiner
Copy link

NeuralMiner commented Feb 6, 2017

Though I agree there should be a minimum, if a minimum were to be set now at 10%... no foundation poll except one (and barely) would've passed in the last 4 months (at least). I'd say if the average was 15% participation in polls and a handful that were below 10%, then absolutely make 10% a minimum, but making 10% a minimum when just one poll in recent memory has even reached that 10% is just asking for trouble; no foundation polls will ever pass.
You can't force people to vote if they don't want to. And they shouldn't vote if they don't understand the poll anyway; some people just want to crunch and don't pay attention to anything else that goes on.
I don't think the minimum should be set at 10% when the average is 5% or less.

@Erkan-Yilmaz
Copy link
Owner Author

there is a poll currently about this topic also:

current standing:

  • 53% of the shares want a minimum weight of 10%
  • 22% want 15%

@Erkan-Yilmaz
Copy link
Owner Author

the vote ended:

  • most voted answer is: "yes, 20%"
  • 20% or more vote weight wanted by 56.85% of voter shares

see pic + summary here

@grctest
Copy link

grctest commented Feb 27, 2017

How should we evaluate the outcome of polls?

  • First past the post? (Most voted = only winning option)
  • Proportional representation? (We take % of each option into account, work out a representative value for polls which have a numeric outcome)

@startailcoon
Copy link

Regarding whitelist polls and Investors. Make the polls only Magnitude, not Mag+Balance.

@mistermarmot
Copy link

Currently there are two investors with something like $50 million in GRC stored and they can vote down any whitelist attempt. They currently haven't TMK, but that doesn't disallow potential future barrons from blocking all whitelist attempts.
Is there any project, whatsoever, that has made a large GRC investment to influence GRC activities related to their project?
I also strongly suggest MAG only voting on whitelisting.

@Erkan-Yilmaz
Copy link
Owner Author

"14 days for a whitelist poll (unless there's proven evidence of issues requiring a more prompt removal from the whitelist)."

Personally, for e.g. this poll, I'd have liked to create it for 7 days, since the reason is obvious (no WUs anymore)

@startailcoon
Copy link

Personally I think removal should be quicker than including. Removal is usually due to something happening. No WUs, flawed credit system, cheating etc. Of course we need to give users enough time to vote about it, but if the reason is obvious it should be automatic. What are we to do if 'No' get the most votes when its a matter of network security. We need to set up some ground rules regarding this instead so the network can make an automatic consensus without a poll.

@Scalextrix
Copy link

Because of the way RAC works, it takes time to build new RAC on a new project. So if we have 1000 RAC on a project to be delisted, that will decay over a number of weeks, to rebuild an equivalent RAC on a new project will take a similar amount of time. So with ATLAS for example, its no longer active, but its going to take time to rebuild that RAC on LHC@Home. In these circumstances (where the project is properly managedd and communication is clear) we have a 2 week vote on the dates on which the project will be removed, immediately, 2 weeks or 4 weeks.
If a project admin is lazy, distributing malware etc. the vote should be quick and the removal immediate.

@Erkan-Yilmaz
Copy link
Owner Author

see also @grcjamezz ' comment about investors in the Pentathlon polls (see comment here)

@barton2526
Copy link

barton2526 commented Apr 20, 2017

Perhaps in the future, for polls such as this one we should consider @grcjamezz 's suggestion above (see comment here)

@XaqFields
Copy link

XaqFields commented Jul 12, 2017

Just a few ideas:

  1. I think we need to have a published set of rules on how certain types of votes should be cast (IE: whitelist polls) and those rules should be agreed-upon by the community via a vote. Currently it seems we are using suggestions made in this thread to govern polls (or at least this is how @Erkan-Yilmaz is doing it). We should get a firm, voted on set of rules to avoid confusion on what makes a poll invalid. If we don't have that in place, we have no basis for which to challenge the result of a poll.
  2. If a poll is published which does not follow those rules, it should be deleted (if possible). If deletion is not possible, the poll should be allowed to run its course and a second poll should then be launched with the correct parameters. (A second poll should not be created in parallel as this causes confusion and consternation should the polls produce different results.)
  3. As it relates to Whitelist polls, I think it should be considered to allow Magnitude to be the driving weight for these polls unless there is a reputational risk related to the project under consideration for addition/removal. There is already a lot of fuss being created in the mining community that they feel they don't have enough weight in many of our polls --- I think at least letting them have the highest weight in Whitelist polls would go a long way toward improving that perception.
  4. As part of our published rules, we should also agree on ways in which a user can have their poll creation privileges revoked. Since these polls are important to the development and reputation of Gridcoin, users who abuse the system and/or create unnecessary/confusing/aggressive polls should rightfully have this privilege revoked. I have noticed polls in the past created by @Erkan-Yilmaz which seem to be passive-aggressive in nature and intended to undermine other polls. This behavior should not be tolerated as it discredits the blockchain polling system we have in place.
  5. Any official poll should have details available to inform the voter. Many whitelist removal polls were published this morning by @Erkan-Yilmaz with no explanation. For example: Removal of Sztaki from whitelist is a new poll, but the voter isn't given any information on WHY we would want to remove Sztaki from whitelist.

@denravonska
Copy link

Filed an issue over at gridcoin-community/Gridcoin-Research#433. In my opinion all the options bug mag+balance are redundant.

@Erkan-Yilmaz
Copy link
Owner Author

Erkan-Yilmaz commented Jul 13, 2017

@XaqFields about https://github.com/Erkan-Yilmaz/Gridcoin-tasks/issues/17#issuecomment-314790867:
#4 those polls you mentioned in chat are not created by me, but I can tell you who created those, or he can step up himself here + explain
#5 sztaki: I have added after your comment a little more info (but I had given links before so users can read there, in words formulated not by me). In general I put less info than too much in polls, b/c as you suggest, it can "influence".

@denravonska
Copy link

I think all whitelist polls, add or remove, should come with a basic TL;DR. Something like

- Reason for removal: Owner is a douche
- SSL: No
- Work units remaining: 90
- Estimated time to completion: 4 years

If we can get that info, that is.

@Erkan-Yilmaz
Copy link
Owner Author

see also:

@Erkan-Yilmaz
Copy link
Owner Author

Erkan-Yilmaz commented Jul 26, 2017

how to act in situations where voters have problems like these ? magnitude zero, stuck in blockchain, ...

@Erkan-Yilmaz
Copy link
Owner Author

Erkan-Yilmaz commented Aug 4, 2017

see also:

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

10 participants