Ratified Doc 153 - Grants - 2019-01

Public: Only invited members may reply

  • Viewed Bedrock Solutions Bedrock Solutions Blockchain Innovation Foundation Blockchain Innovation Foundation Blockrock Mining Blockrock Mining Brian Deery BuildingIM BuildingIM Canonical Ledgers Canonical Ledgers CryptoLogic CryptoLogic Cube3 Cube3 DBGrow DBGrow De Facto De Facto Factom Inc Factom Inc Factomatic Factomatic Factomize Factomize Factoshi Factoshi Federate This Federate This Go Immutable HashnStore HashnStore Julian Fletcher-Taylor LayerTech LayerTech Luciap Luciap Matters Matters Multicoin Capital Multicoin Capital Niels Klomp PrestigeIT PrestigeIT Quintilian RewardChain RewardChain Samuel Vanderwaal Stamp-IT Stamp-IT The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed None

Should the document be ratified or amended as specified by the thread type?


Have not voted

Authority Nodes Blockchain Innovation Foundation Blockchain Innovation Foundation

  • Total voters
    29
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.

CryptoLogic

Crypto Logic
Thank you for putting this together @Julian Fletcher-Taylor and @Nic R!

First off all, we think this solves all the problems related to grant vote in the first round and think that we will not even need STV in the future.

It sorts out the problem width some people voting binary and others on a scale

It makes so people can actively state if they support a grant or not making that part unambigious

It is easy to handle both for voters and the guides/administrative side

It migt be easy to automate on chain in the future

--
Some suggestions

- Support limit 3/5 instead of 2/3 (60%. In accordance wit governance document for support, and also identical with other votes requiring support for anos (3/5 is specified we think).

- Instead of doing PDF uploads for making the actual vote the guides should make a simple form (like the one you made), and a forum named "Grant Voting" could be made in this forum. Each standing party can make a private post with their ranked vote, which can be revealed/made public after vote ends. The guides can import the votes to google spreadsheet like last time the spreadsheet automatically sum it up.

The best solution is of course a factomize forum change to accept voting like this, but maybe David and his team is to busy before next vote?... :)


We strongly support this way of making the voting this time.
 
Do you think it's possible or likely that we'll see a behavior that will mimic a binary vote with this system ?

Could someone vote 1-1-1-10-10-10-10-10-10-10 (assuming 10 grants) ?

Don't we also end up in a state where parties are incentivized to vote 1-10 only to maximize the likelihood of a project they like to go through?

Maybe I am missing something with your example "The parties votes for a series of 10 grants are 1, 2, 2, 2, 4, 5, 7, 8, 9, 10"
 
@Miguel Proulx

So we either can go with option 1 in the document which would programatically enforce that you are ranking 1-10 with each number used only once (like a proper ranking).

If we go with option 2 or 3, then we employ that scheme I have at the bottom to re-balance your vote.

So in your example voting of 1-1-1-10-10-10-10-10-10-10 , what would happen is each of those first 3 grants would receive a score of (1+2+3) / 3 = 2. So it actually de-leverages your vote because you aren't actually giving any grants a rank of 1.

What your example does point out to me though is the wording needs to change to start averaging in vacant ranks from left to right rather than next-vacant to the right so that clumps at the end of the range get de-leveraged as well. Thanks!
 
@Tor Paulsen

Agree its not too hard and I hope no one does that, but I just like to have frameworks that cover those scenarios if they arise.

I think recusals could work just like they work now?

Take example: 1, 2, 2, 2, 4, 5, recuse, 8, recuse, 9

Maps to rankings
1, 3.67, 3.67, 3.67, 4, 5, recuse, 8, recuse, 9
So those 3 tied votes for rank 2 are averaged through scores 2, 3, and 6 to 3.67, rank 7 and 8 are unused, and 2 grants have recusals. It may be visually messy but I dont see it being hard to implement or causing any problems withe the actual rankings. Am I missing any issues here?

So the most extreme voting you could do is 1, recuse, recuse, ... , recuse, 10. So you only have voted on 2 grants, one a 1, one a 10, but you already "have the right" in this system to give 1 grant a 1 and 1 grant a 10. You don't have any extra leverage on grants past that because you are recusing from them.
 
Regarding ANOs voting for themselves on grants - Here's a simple compromise (maybe):

Disallow ANOs from voting on their own grants. However, add in a sunset provision to this clause that is triggered when we move to on-chain voting, as we'll hopefully we'll be adding another standing party at at that point, which means we will have way more than a few dozen entities voting, so "grant stacking" wont be as much of an issue.
 
I believe the way this is implemented that we could still have situations where ANOs are voting binary to maximize their vote impact. If enough ANOs do that we would end up with a lot of "legit" grants being voted out.

Is there a way to do away with the A-D and simply have a ranked 1 to 10 system with no duplicate ?

An "optimal" voting strategy would be for most ANO to vote 'D' everywhere and only 'A' for the grants they are involved with or grants that are of paramount importance to the ecosystem. We could end up with something worse than the other grant round.

We only need 10 people voting 'D' everywhere to refuse any given grants and last round quite a few voted binary or close to.
 
I'm understanding correctly that even if I vote against a grant I still have to rank it? And that rank does matter because if the vote is not rejected by ranking will be taken into account? That part seems a bit counter intuitive. Didn't you have a proposal before that was not a two-part voting, but we just didn't rank the grants we wanted to? Why did you discard in favor of this new system?
 
I'm understanding correctly that even if I vote against a grant I still have to rank it? And that rank does matter because if the vote is not rejected by ranking will be taken into account? That part seems a bit counter intuitive. Didn't you have a proposal before that was not a two-part voting, but we just didn't rank the grants we wanted to? Why did you discard in favor of this new system?
I think ranking grants you don't support is not really an issue. You get to state that view in the binary "support / not support" vote that is done in parallel, and you also get to put them at the bottom of the list to provide them with as little chance to pass as possible...

I think it is a good solution and that we should give it a go this time around. It's an evolutionary process and if we find issues with it we can always discard it or amend it for the next grant round.
 
Not saying it is a critical flaw, overall I do prefer that solution over what was used last round and would support it.
But I still a bit odd. Let's say I'm a contrarian voter, and I want to vote in only 1 out of the 10 grants. I still have to rank 2,3,... those grants I dislike, and if the threshold for not approving them is not met then the fact that I ranked them 2nd, 3rd does matter significantly. So my vote doesn't reflect my contrarian view anymore.
 
@Paul Bernier 's point is very valid.

We seem to be operating under the assumption that it is always in the community's best interest to spend all the FTC. For the first two grant rounds, I would agree with that. However, I think that may change soon. There is a very good argument to be made that it is in the community's best interest to hold back 15% (or whatever) of the pool each grant round so we can ensure essential projects, like core development and sharding, will continue to be developed months down the road.

None of us has any idea what the price of FCT will do. Therefore, if the choice comes down to funding a project that is non-essential and will barely move the needle vs. saving some FCT to pay for core development that we can use during a potential worst-case-scenario event, then I'm voting the later. I'm sure I wont be the only one.
 
Paul, I think your point is sound and provides a good example of why it's really important to stress test the extremes of a new system. I agree with what you said -- that you could disapprove of all but one Grant, but still have to rank them, and if the global eligibility threshold is met for all of those other Grants, then your rankings would hold weight. I do think that's somewhat problematic.

In the RBV system in the Voting Proposal, the idea would be that if you find a Grant or a few Grants ineligible (D), you rank it low (say at 9 or 10). If most people (30%+) find it ineligible (D), just as in the above example, it will remain ineligible for funding (so this part is uniform in both examples). If it is globally eligible in the RBV voting proposal, then at least your rank devalues the Grant or few Grants -- as opposed to the same Grant/s being globally eligible but -not- devaluing them in your example. In the extreme case where you find most all Grants ineligible, well, I agree that does leave you in a pickle as you'd have to rank some Grants highly or at mid-weight even when you believe they should be ineligible.

So I guess, from my POV, it boils down to whether you find a few Grants insupportable -or- most all Grants insupportable. In either system, if the Grant is ineligible (via breaching the threshold), then it's ineligible. So we're talking -only- about cases of global eligibility.

- In the RBV voting proposal, you can lowly rank some Grants u deem ineligible (as a hedge against global eligibility), but cannot lowly rank most Grants.
- In the altered case, you can not rank whatsoever when finding Grants ineligible, but then you leave the larger community to decide a Grant's fate (when a Grant is globally eligible).

To me, there just isn't a "perfect" way to evaluate a voting system. Maybe, if we're able to implement full-on STV next round, we can get even closer to that ideal system. But for now, RBV, as we have it presently described, does reduce between-group ambiguity in the way voting and scoring is perceived (which was our main goal in departing from the 0 - 100 scoring method). For the record, I am also personally open to the alteration such that a given Party could recuse on any number of Grants -and- by doing so, not be forced into any such ranking, favorable or unfavorable because:

I also agree that Matt's assertion (that the Grant pool does not need to be fully exhausted in a given Grant round) makes a lot of sense. There are major needs in terms of code refactoring and core development, and having leftover funds from prior Grant rounds to potentially spur greater development in these most crucial areas of need sounds smart to me. My only thought here is it's totally possible that many Standing Parties may vote in a way that does rank most Grants, and we would still have more eligible Grants than there are FCT's to fill these Grants in the Grant pool, and in that case, we would not be preserving any leftover FCT's anyway.

I really appreciate your thoughts on all this, and I admit that it's hard for me to wrap my head around an ideal solution in a short timeframe. You both bring up good points.
 
@Nic R I’m excited with your proposal on Rank based voting. I fully support this and think, that although it’s not the perfect voting system, but it’s really close to be perfect & it’s definitely much better than 0-100 scoring.

I think we should implement ranking voting in this grant round. Then we can see the results and discuss further improvements :)
 
So far I've seen strong support for the ranked voting proposal so unless I see some dissent I'm going to include it into Doc 153 in the next couple of days.

I've seen no one complain about the wording prohibiting affiliated ANOs from voting on their own grants being removed from the document. You still have time to voice your opinion but I'm going to leave it out unless people initiate the discussion about why to put it back in and also unless they put together a solid definition of affiliation so it's not too subjective and doesn't cover too many ANOs in the community.
 
It’s a tough one Sam. A community project which isn’t remunerated would be perfectly fine to vote for.

Non-Essebtial work someone proposes for personal remuneration should probably recuse themselves.
I can understand this position, truly I do. I just can't find the hard and fast lines to draw. Larger grants with multiple ANOs could be split up into smaller grants with a single ANO per grant. So then you have define how closely related projects are to consider being affiliated and I believe that gets tricky. It seems simpler to mirror the system how it will be once the fully on-chain solution is implemented than get bogged down in setting up a number of complex rules that could introduce more gaming.
 
Yeah the system is subject to manipulation, conflict of interests, and voting blocks. But I agree it’s hard to draw the line exactly. At this stage we just have to trust people will act honourably.

It will have to rely on some social enforcement as we saw some eyebrows raised last round.

The real issue is whether social enforcement is an effective tool with so few standing parties unless unanimous, allowing for flexible standards in ethics.
 
Also add how long you think the discussion should be open for. Forever? Or until the round is finalized?
I believe discussions should remain open until after voting in general, and in this case.

(Not a big fan of closing discussions even afterwards, but there is a point at which further discussion has no value.)

Can you create a thread specifically for this so we don't bring the discussion off-topic here?
And my comment here is on topic, as the discussion period is specified in this document.

If we remove the requirement that the discussion be closed prior to voting from this document, and simply say that discussions and voting will be handled in the "standard way" or something, then we can have another thread on the general principle. But we would be out of compliance if we decided elsewhere that we would not close discussion just because the voting period starts, if this document requires it.

*edit* I guess we just refer to this in the timeline, so (maybe ?) I'm just being a pain. Ignore this.
 
Last edited:
I believe discussions should remain open until after voting in general, and in this case.

(Not a big fan of closing discussions even afterwards, but there is a point at which further discussion has no value.)



And my comment here is on topic, as the discussion period is specified in this document.

If we remove the requirement that the discussion be closed prior to voting from this document, and simply say that discussions and voting will be handled in the "standard way" or something, then we can have another thread on the general principle. But we would be out of compliance if we decided elsewhere that we would not close discussion just because the voting period starts, if this document requires it.
There are two different types of discussions now being talked about here:

1) Ratification-type discussions as governed by Doc 002, section 2.3.5:
The default discussion period shall be eight (8) days but can be extended or shortened using the built-in features of the Timed Discussion threads on the forum.
and;

2) The discussion timeframe for the individual grant applications in the coming grant round in the document currently being ratified:
- At 2019-01-31 00:00 the public discussion on the grants will be opened via threads on the Factomize forum.
This is the start of the public questions and review process by means of discussion on the Factomize forum (Section 4.6). The grant proposal can be amended/updated during that time by the grant proposal creator based on input from the community. Any such edits shall be described in the ORIGINAL grant-proposal post preceded by this text:
“GRANT PROPOSAL EDITED YYYY-MM-DD:”
- At 2019-02-08 23:59 the public discussion will be closed.

You are stating that we should keep the discussion in this thread due to it being relevant for this document. Only 2) above is relevant in reference to Doc 153, but I am happy to discuss that.

The reason we have stated that discussion closes before voting is that parties voting should not be swayed by questions and comments during the voting period, as the grant applications might not have the ability to answer before standing parties start to vote.

If there is community support for amending Doc 153 to allow for discussion during the voting period I'd be happy to facilitate the change.
 
Hi everyone!

I and Sam has spent today (or rather; my day and his night) finalizing Doc 153 and the voting solution for this Grant round.

Over the past few weeks we have conducted a few polls on discord, and there has been extensive discussion in the governance channel. Based on the polls, the discussion and DBGrows suggested voting system we have included the following in the updated grant document:

- Ranked voting ( first -> last grant application).
- Governance defined grants (anchor master, guide compensation, oracle master) will be voted on as approve/disapprove only and require 3/5 support to be approved.
- Approve/Disapprove for each grant by each standing party. Grant needs 3/5 (60%) approvals to pass.
- All standing parties are allowed to rank every grant.
- Recusals are possible and optional. Recusals will have to be ranked, but they will not be taken into consideration in scoring.
- A voting template to be used when voting by all standing parties.

As the current voting infrastructure does not support ranked votes nor approve/disapprove we are proposing the following way of submitting the votes:

- The standing parties fills out the template below, ranking all grants, and ticking off checkboxes for abstain/approve for every grant.
voting_template.png

- The standing parties uploads the scoring sheet as a pdf through a google form, including an optional hash if they like.

- When the voting period has concluded the guides populate a scoring spreadsheet with the votes, as well as making the submitted PDFs public for transparency. A spreadsheet has been created for this purpose, where each standing party has a spreadsheet identical to the scoring template.

Final_Scores-spreadsheet.png


- After inputting the data, the sheets are sorted, and the data automatically transferred to the "master scoring sheet":
(with 20 grant applications there will be 1800 datapoints)
Master-Scoring-Sheet.png

- The scores will be automatically calculated and populated in the "final scores" sheet:
final-scores.png

The score calculation uses an average of the rankings.
Example:
Grant A is ranked 5, 2, 6, Abstain and 1 by five standing parties. The score will be 5 + 2 + 6 + 1 / 4 = 3.50.


We have asked @Shuang Leng to take a look at the document and she has agreed to do so later today (thank you!).

This discussion period will end tomorrow, and the document will be put up for a vote.


Please take this last opportunity to comment on the document so any errors can be discovered before the voting period starts, and potential issues discussed.

Sam & Tor.

Edit: math is hard.

Edit 2:
Link to Appendix D - Final Scoring Sheet - Please feel free to fork it and play around with it to verify that it is working as intended.
 
Last edited:
There are two different types of discussions now being talked about here:

1) Ratification-type discussions as governed by Doc 002, section 2.3.5:


and;

2) The discussion timeframe for the individual grant applications in the coming grant round in the document currently being ratified:



You are stating that we should keep the discussion in this thread due to it being relevant for this document. Only 2) above is relevant in reference to Doc 153, but I am happy to discuss that.

The reason we have stated that discussion closes before voting is that parties voting should not be swayed by questions and comments during the voting period, as the grant applications might not have the ability to answer before standing parties start to vote.

If there is community support for amending Doc 153 to allow for discussion during the voting period I'd be happy to facilitate the change.
So what happens if Doc 153 is updated, but this document is ratified with a requirement that is in conflict with Doc 153? Have we specified a hierarchy of documents to resolve conflicts? Or a high court to rule where change is constrained by spreading around requirements across documents? Or do we have to update all the documents?

This requirement should be removed from this document.
 
So what happens if Doc 153 is updated, but this document is ratified with a requirement that is in conflict with Doc 153? Have we specified a hierarchy of documents to resolve conflicts? Or a high court to rule where change is constrained by spreading around requirements across documents? Or do we have to update all the documents?

This requirement should be removed from this document.
Paul,
I saw your comment about withdrawing the comments here but I just wanted to clarify one thing.

We have taken the document hierarchy into consideration when creating the process documents so there is no conflict.

- Doc 002 (the document governing creation/amending and removal of community documents) states that when we are ratifying a new document the discussion period shall be 8 days and then close before voting starts. This is to ensure there is no ambiguity regarding what document is actually being voted on (if there is an ongoing discussion with multiple amendments and suggestions it might get confusing fast).

The thread is kept closed after the voting is over both because there isn't automation for opening it up again, and because the process is then over. If the document got ratified and someone wants to continue debating aspects of it they can create a new thread for discussing those specifics, or they can initiate an amendment process to change the document. If it didn't pass a new process will have to be started anyway due to allow for a new vote.


Right now we are currently in the discussion phase described above for ratification of Doc 153.

- Doc 153 is a single use process which describes how the grant process for grant round 2019-01 shall be handled. It states that there shall be an 8 day discussion period for the submitted grants.

Even if Doc 153 specified a 2, 6, 20 or 500 day discussion period this would not be in conflict with Doc 002, as Doc 002 is only valid in reference to the creation/amendment/removal-process of community documents, and not for the upcoming grant round which will be done in accordance with Doc 153 (if ratified).


If you would prefer to keep the discussion open when voting (and/or after) for document ratifications/amendments/removals, the way to go about having it changed is to put an amendment process up for Doc 002. It would however require changing the forum software, so before going there we might want to discuss it with David first to see if it is viable.
 
Status
Not open for further replies.
Top