Pre-poll Discussion: Poll Definitions

<p dir="auto"><span>Below is an introduction to a proposal followed by the proposal itself. There will be a two week discussion period before the proposal is put to a poll. Thanks to <a href="/@barton26">@barton26 and name831 for helping proofread! <p dir="auto"><h1>Introduction<p> <p dir="auto">Gridcoin polls are a tool that help guide decision-making on the Gridcoin network. It is difficult to use this tool without clear polling definitions and validation parameters. This will become increasingly difficult as we continue to grow and decentralize as a network and community. <p dir="auto">I propose defining requirements and validation parameters for polls. To do this I propose defining seven types of polls with appropriate requirements and parameters for each. I propose this split because a major protocol change, for example, is much different than a minor marketing proposal and should be held to a different standard. Additionally, a protocol change and a marketing initiative, for example, are going to have different aspects to their proposals. Lastly, the new GUI assets have the potential to set a poll type when making a poll. This will help organize polls in the client so participants can more easily see what is happening. <p dir="auto">I am looking for feedback, concerns, questions, and suggestions during this discussion period. I think a particular focus should be put on AVW validation parameters and required poll times. As this is a fairly significant proposal, I think it is appropriate to use the poll time we decide on for this proposal as a standard across other major polls. <p dir="auto">Please comment on the steemit or reddit threads, or reach out on slack or discord. Thank you! <p dir="auto"><h2>Timeline of this proposal<p> <p dir="auto"><strong>Introduction and preliminary discussions on slack: Already done<br /> <strong>Presentation to the larger community: Now<br /> <strong>Discussion period: 2 weeks - Ends March 6th<br /> <strong>Poll: 2-6 weeks depending on the discussion <p dir="auto"><h2>Notes on discussions and decisions:<p> <p dir="auto">Below are some notes based on the preliminary discussions that took place on slack. <p dir="auto"><h3>On AVW validation values<p> <p dir="auto"><span>Several weeks ago we spent some time discussing possible AVW values on slack in the <a href="/trending/poll-definitions"> #poll-definitions channel. The values in this proposal represent the outcome of those discussions. <p dir="auto">AVW was introduced with the CBR poll. Since then I have been following as many polls as I can taking note of the AVW before and after whales enter their votes. It seems as though all major polls have breached 100% AVW (super-validation). Major polls without significant whale participation seem to break 30% AVW. Major polls with limited whale participation seem to break 60% AVW. We are going to need to continue to observe poll results as we get deeper into the CBR economy as CBR has stabilized the network difficulty at a higher level than under the APR model. <p dir="auto"><span>If anyone wants to break things down into real data, please do! All the information is in the blockchain and there are several explorers that might help break it all down. I used <a href="https://gridcoinstats.eu" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://gridcoinstats.eu. <p dir="auto">The goal with this proposal as it stands is to get things moving by setting AVW values and implementing a process to change these values in the future. A <em>management poll is that process. Management polls are set at 30% AVW so they will be validated with relative ease. This should force us to have a conversation and make a decision when a change is proposed. <p dir="auto">The two week discussion period on this proposal will hopefully give us time to discuss this concept and these values as a community before putting it to a poll. <p dir="auto"><h3>On the extent of this proposal<p> <p dir="auto">The goal with this proposal as it stands is to get things moving by defining poll-types and requirements/validation parameters. We could poll each poll-type individually, however I believe that this will consume a significant amount of time with minimal return when compared to defining a foundation for all poll-types at once. We have much to do and since polls play a significant foundational role in guiding our decisions, I think we should get this over with as quickly as practically possible so long as there is a reasonable way to change things in the future. <p dir="auto"><h3>On Outreach<p> <p dir="auto">Outreach in this proposal is seen as: <p dir="auto">Legitimizing community representation - If someone and their proposal (documentation, presentation, talking points, etc) is voted as a representative at a specific event they can say they represent the network. If not, they are an individual that is part of the network. <p dir="auto">Compiling, building, and maintaining proactive documentation - Shared presentation material, for example. <p dir="auto">Maintaining channels of communication for those outside of the network and community - Contact with BOINC projects and exchanges, for example. <p dir="auto">Allocating resources to take advantage of opportunities as they present themselves - cross-community partnerships, for example. <p dir="auto"><h3>On unvalidated polls<p> <p dir="auto">If a poll is unvalidated it is not considered actionable. This means that the proposal would need to be reworked, ideally through collaboration, and presented again. This encourages collaboration and discussion from the start which in turn helps ensure quality proposals. <p dir="auto"><h3>On flaws with AVW<p> <p dir="auto">They exist and I believe there are solutions. I also believe AVW is a better metric than TVW. I detail this in the proposal. For now, I think the most important thing is to get these requirements and parameters defined so we can move forward with other developments. This proposal defines a process by which we can tweak the system as we grow. <hr /> <p dir="auto"><center>____________________ <strong>MAIN DOC ____________________<br /> ____________________ <strong>START ____________________ <hr /> <h1>1.0 Voting <p dir="auto">Gridcoin utilizes a protocol based voting mechanism to: <ul> <li>Gauge interest <li>Inform development and organizational direction <li>Utilize foundation funds <p dir="auto">Any network participant with a balance of 100k GRC in a wallet can create a poll. A poll must meet all requirements for the appropriate poll type to be considered valid. <p dir="auto">There are seven types of polls. <h1>1.1 Vote Weight and Active Vote Weight <p dir="auto"><strong>Vote-weight is the power given to a vote cast on the Gridcoin blockchain. It is measured as a modified sum of balance and magnitude. The formula for vote-weight is: <p dir="auto"><center><code>VoterBalance+VoterMagnitude((TotalMoneySupply/TotalNetworkMagnitude)/5.67) <p dir="auto"><strong>Total vote-weight (TVW) is the total possible vote-weight of the network. It is calculated as a weighted sum of total minted coins and network magnitude. The formula for total vote-weight is: <p dir="auto"><center><code>TotalMoneySupply+TotalNetworkMagnitude((TotalMoneySupply/TotalNetworkMagnitude)/5.67) <p dir="auto"><strong>Active vote-weight (AVW) is a calculated average of the coin weight actively securing the network for the duration of the poll, plus the network magnitude, less the magnitude of any crunching pools. The formula for AVW is: <p dir="auto"><center><code>AV-W = (Average Difficulty* 9544371.769) + ((TotalNetworkMagntiude- Average Pool Magnitude)* (Average MoneySupply/TotalNetworkMagnitude)/5.67) <p dir="auto">AVW as a metric solves the validation problems of total vote-weight validation, including missing vote-weight due to lost and burned coins, coins in cold storage, coins held by exchanges, and vote-weight frozen by crunching pools. <p dir="auto">AVW enables high weight validation via active network participants. <p dir="auto">AVW enables super-validation. Super-validation is a validation percentage greater than 100%. Super-validation implies that inactive balances were brought online to vote on the proposal in question. <p dir="auto"><em>Note: TotalNetworkMagnitude = 115,000 <h1>1.2 Poll Validation by Active Vote Weight <p dir="auto">Poll validation requirements are intended to ensure no proposal passes without significant network support. Each poll type has its own AVW validation parameter initially defined in this proposal. Validation parameters can be changed through management polls. <p dir="auto">If a poll is not validated no action is taken. <h1>1.3 Requesting Funds in Polls <p dir="auto">Any proposal requesting reimbursement or funding from the foundation must be approved by a network poll. <p dir="auto">Funding can be requested for all poll types except for Opinion/Casual and Whitelist polls. The following information is required if funding is requested in a proposal. <ul> <li>Intended use of funds <li>The date of work begin <li>The date of work end <li>Total funding requested (denoted in GRC) <li>When funds are released <li>How funds are released <li>The payee's name or alias <li>The payee's wallet address <li>Reliable contact information <h1>1.4 Poll Types, Requirements, and Validation Parameters <p dir="auto">There are seven poll types. All poll types except for Opinion/Casual must use "Magnitude and Balance" as weight metrics. <h2>1. Opinion/Casual <p dir="auto">Opinion/Casual polls are for early exploration of ideas or for fun. <h3>Examples <ul> <li>Do you support the continued exploration of this CBR idea? <li>Do you support the continued exploration of this protocol change idea? <li>Masternodes, DPoS, PoS, or PoW? <li>Cubes or curds? <h3>Poll Requirements <p dir="auto">NONE <h3>Validation Parameters <p dir="auto">NONE <h2>2. Development <p dir="auto">Development polls include polls to change a protocol value or for proposing changes to the protocol at large. <h3>Examples <ul> <li>Implement CBR as proposed? <li>What should the CBR value be at implementation? <li>Remove the BOINC team requirement? <li>What should the side-staking development requirement be at implementation? <li>Implement MRC as defined in this proposal? <li>Change CBR value to 3.1415? <li>Change development side-stake requirement to 2% <h3>Development Poll Requirements <ul> <li>Main Poll Discussion Thread on Github or Reddit <li>Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread <li>Minimum 6 weeks (42 day) Poll Time <li>Unbiased Poll Phrasing and Options <li>"Abstain" Vote Option <h3>Development Poll Validation Parameter <ul> <li>AVW of 60% or greater <h2>3. Marketing <p dir="auto">Marketing polls include any proposal for marketing initiatives. <h3>Examples <ul> <li>Do you support this proposal for taking out an ad in New Scientist magazine? <h3>Marketing Poll Requirements <ul> <li>Main Poll Discussion Thread on Github or Reddit <li>Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread <li>Minimum 6 weeks (42 Day) Poll Time <li>Unbiased Poll Phrasing and Options <li>"Abstain" Vote Option <h3>Marketing Poll Validation Parameter <ul> <li>AVW of 50% or greater <h2>4. Outreach <p dir="auto">Outreach polls include any proposal which seeks to: <ol> <li>Legitimize community representation <li>Compile, build, or maintain proactive documentation <li>Maintain channels of communication for those outside of the network and community <li>Allocate resources to or otherwise take advantage of outreach opportunities as they present themselves <h3>Examples <ul> <li>Do you support representation at [Conference A] as detailed in this proposal? <h3>Outreach Poll Requirements <ul> <li>Main Poll Discussion Thread on Github or Reddit <li>Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread <li>Minimum 6 weeks (42 Day) Poll Time <li>Unbiased Poll Phrasing and Options <li>"Abstain" Vote Option <h3>Outreach Poll Validation Parameter <ul> <li>AVW of 50% or greater <h2>5. Management <p dir="auto">Management polls include any proposal which seeks to modify the management or organizational structure of Gridcoin. <h3>Examples <ul> <li>Do you support the proposed management proposal? <li>Change AVW validation parameter for development proposals to 50%? <li>Change minimum required poll time for Outreach polls to 4 weeks? <h3>Management Poll Requirements <ul> <li>Main Poll Discussion Thread on Github or Reddit <li>Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread <li>Minimum 6 weeks (42 Day) Poll Time <li>Unbiased Poll Phrasing and Options <li>"Abstain" Vote Option <h3>Management Poll Validation Parameter <ul> <li>AVW of 30% or greater <h2>6. Community <p dir="auto">Community polls include any proposal or initiative related to the Gridcoin community, but unrelated to any other department. <h3>Examples <ul> <li>Do you support this community competition? <li>Do you support hosting this crunching competition? <h3>Community Poll Requirements <ul> <li>Main Poll Discussion Thread on Github or Reddit <li>Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread <li>Minimum 2 weeks (14 Day) Poll Time <li>Unbiased Poll Phrasing and Options <li>"Abstain" Vote Option <h3>Community Poll Validation Parameter <ul> <li>AVW of 30% or greater <h2>7. Whitelist <p dir="auto">A whitelist poll is used to add or remove a project from the whitelist. The whitelist is a larger mechanism within the operation of Gridcoin. Each project considered for whitelisting must meet a set of requirements, and several actions must be taken before a poll for adding or removing a project can be considered valid. A project can be removed from the whitelist at the discretion of the whitelist admin if it ever fails to meet a requirement described below. <p dir="auto">More information including discussion threads that informed the creation of the whitelisting and greylisting processes, information about each project's Work Availability Score and Zero Credit Days, and details on the greylist process are linked at the end of this section. <h3>Project Requirements for Whitelist Consideration <ul> <li>Project Work Availability Score is green <li>Number of Zero Credit Days is less than or equal to 7 out of the last 20 days <li>The project has a clear description of the work and the work is as described <li>The project allows new user registration <li>Project complies with the BOINC terms of service <li>All crunchers that comply with the terms of service of both BOINC and the project have equal access to work units <h3>Required Actions before Creation of Project Addition Poll <ul> <li>Direct contact with a project administrator <li>An affirmative public response to whitelisting by a project administrator <li>An agreed add date with both the Gridcoin whitelist administrator and project admin <h3>Required Actions before Creation of Project Removal Poll <p dir="auto"><em>These are necessary only if a project meets all whitelist requirements, is not greylisted, and is otherwise functioning as intended <ul> <li>A public attempt at contact with a project admin is made <h3>Examples <ul> <li>Add project SETI@Home to the whitelist? <li>Remove project SETI@Home from the whitelist? <h3>Whitelist Poll Requirements <ul> <li>Main Poll Discussion Thread on Github or Reddit <li>Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread <li>Minimum 2 weeks (14 Day) Poll Time <li>Poll Options: <ul> <li>Yes <li>No <li>Abstain <h3>Whitelist Poll Validation Parameter <ul> <li>AVW of 50% or greater <p dir="auto"><a href="https://gridcoin.ddns.net/pages/project-list-process.php" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://gridcoin.ddns.net/pages/project-list-process.php<br /> <a href="https://github.com/gridcoin-community/Gridcoin-Tasks/issues/194" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://github.com/gridcoin-community/Gridcoin-Tasks/issues/194<br /> <a href="https://github.com/gridcoin-community/Gridcoin-Tasks/issues/213" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://github.com/gridcoin-community/Gridcoin-Tasks/issues/213<br /> <a href="https://github.com/gridcoin-community/Gridcoin-Tasks/issues/201" target="_blank" rel="nofollow noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://github.com/gridcoin-community/Gridcoin-Tasks/issues/201