Grant Round Improvements Discussion

Secured
#91
IF the consensus is that's it's a problem we should deal with at this juncture, then I'd suggest that the grant recipient not be able to choose the sponsor, they simply budget for it and the community chooses the sponsor after the fact.
100% agree. I never understood why the grant recipient got to pick in the first place. This should definitely be implemented.
 
Secured
#94
100% agree. I never understood why the grant recipient got to pick in the first place. This should definitely be implemented.
I'm not sure I agree with this. It's a tough one. On one hand yes, its infinitely easier to just get a sponsor thats in your pocket if you get to choose.

On the other hand, there are cases where the grant recipient is willing to give the sponsor more in depth info (even signing an NDA possibly), and there may be times that a recipient feels uncomfortable dolling out that information to a sponsor selected by other parties, even under an NDA. We don't want to disinsentivize recipients from sharing extra info with sponsors.

On this issue I lean toward a more free market approach. A recipient can come to the table with their own sponsor set out before the grant, they can have an empty slot that the community can fill, they can even have an empty slot they will fill later. It's all just different grants that the standing parties can judge and decide whether they support them. Why enforce additional rules and bureaucracy, and take a step closer to having the Factom Protocol's governance system itself be deemed a centralized entity with operational and financial oversight of entities within the ecosystem?
 
Secured
#95
I believe that a few recent suggestions for changes, including this, are not necessarily here to solve the problems we think they are solving.

For example, is this suggestion coming from a place of our belief that these additional rules are inherently better for a grant round? Or do they come from a place of:

1. Desiring additional control over processes that we don't have the leverage we would like to because of lack of competitiveness in important grant domains (There is only 1 major grant core development grantee right now. If they come to the table with a grant with open slots for sponsors that they will fill at their leisure, do we have much choice in accepting regardless?), so we wish to gain that leverage through instituting rules within governance, and
2. We currently pay out as lump sum, so we are not able to cut off a grant that is not delivering, which means grantees do not have a strong incentive to effectively communicate progress, which in turn leads to the standing parties having an inability to effectively judge the grantee on an ongoing basis because they lack the information. So we instead turn toward sponsors as an all encompassing role to observe, judge, and communicate grant progress to the rest of the community.

These are valid concerns. They should be laid out, articulated, and understood. Are additional rules such as forcing a community voted sponsor on the grantee the best way to address the problems? I'm not sure on that one.
 
Secured
#96
I lean toward a more free market approach.
Like preceding 2008 when banks shopped around their shitty collateralized mortgages to various rating agencies so they could get an AAA mark? That worked out well.

On the other hand, there are cases where the grant recipient is willing to give the sponsor more in depth info (even signing an NDA possibly),
An NDA is needed if something is proprietary.
The vast majority of work has been for opens source
I don't envision the community putting forward potential sponsors that are not trustworthy. I don't see a scenario where this occurs. Do you?

Instead of being reactive, we are trying to be proactive for a change. There's a very real chance that grant recipients stack their proposals with a bunch of ANOs doing "side work" as well as a lot of sponsors. That gives that grant a TON of voting power that could easily override the community's best interests. That's the problem we are trying to solve for.

Furthermore, you're essentially saying that the community is responsible enough to pick Guides, ANOs, and grants... but they aren't responsible enough to pick sponsors. I'm not following that logic.
 
Secured
#98
FYI, me and @Samuel Vanderwaal have started a document summing up the discussion in this thread to identify the issues we need to clear up prior to the next round and then propose solutions to these.

The next grant round needs to start rather soon to stay on the 3 month cadence so I do not think we'll have time to a full revamp and reworking of the process, but I think we can rectify some of the stuff from the last round...

So evolution not revolution. The good thing about having a fixed cadence is however that we can ditch the things that doesn't work and bring forward the things that does; so a robust process will emerge after some iterations if we stay committed to make it slightly better every round.
 
Secured
#99
After watching @Xavier Chen's videos on STV (Single Transferable Voting), I have to say, I think it's pretty cool. It seems to fit the nature of having a specified threshold (say 60%) as a point of success or failure, and it allows for a rank-based process that does seem to accomplish its intent of making the most voters happy. I like that excess %'s from top selected Grants flow down to next most favorably selected Grants. But does this, in any way, disincentivize smaller Grants? Such that if there are 10 Grants, and 4 of them are major Grants which would fully deplete the available FCT's for that round, and people consistently vote for big Grants because we're human and see big FCT ask and think it must mean big potential... are we limiting our breadth of development? This is why I like the inclusion of David's X, Y, Z solution for Grants of different size; maybe STV could be combined with X, Y, Z size-based Grant thresholds ... such that maybe the Grants are tiered at first (small, medium, large), and then STV comes into play?

In terms of voting when affiliated (especially when involved in any way financial) to a particular Grant, I, again, think Xavier brings up some really interesting points. We do not want to disincentivize collaboration between ANO's or between ANO's and other Standing parties. However, we also do not want a four-ANO-backed Grant, for example, to have 4 votes out of 31 total votes (all presumably voting for their particular Grant at the top of, say, a STV rank-based system). In any case, I agree that full disclosure here, in all scenarios, is best. I also agree that a worst case scenario is some mixture of (when having a four-ANO-backed Grant), only 2 or 3 affiliated parties can vote and therefore 1 or 2 affiliated parties get excluded; this would surely create some potential for major contention.
 
Last edited:
Secured
In the end, I think it's (perhaps self-evident, but) important to remember that we're striving for a best practice system rather than a perfect system. If I go by order of importance here:

1) Full financial disclosure encompassing, non-exhaustively: equity, partnership, sponsorship, direct hire, co-development for pay, etc.

2) Then - Should ANO's and financial-affiliates be able to vote on own Grant? I am not fully sure yet, and I will explain my full thoughts below:

If all affiliates of a particular Grant consist of, say, 6% of the total voter-base in a particular Grant round. Then, because they're blocked from voting, the remaining 94% of the community gets to decide the Grant fate with respect to all other Grants. Thus, the burden of proof, so to speak, of selling the 94% community on this major Grant, becomes a more difficult -- but perhaps, a more proportionally equitable task. I mean this in the sense of: if the Grant has all these affiliates, it is probably seeking some major FCT funding; if it is seeking major funding (relative to the other Grants), the theoretical "ease of funding" should be proportionally harder to achieve ... especially because this major funding award does come from the efficiencies of all pledged-efficiency ANO's. This way, all non-affiliated ANO's can vote as they see fit, and affiliated parties will have to strongly sell the community on this major Grant proposal for their Grant to pass. Bear in mind, the vast majority of the community (94%+) still gets to vote on every Grant.

My concern of when/where this breaks down: If there is some Grant where 20%+ of the voting community has some financial affiliation (hypothetically), then we are suddenly limiting a significant amount of potential voters from the voting pool with respect to the Grant. And let's say when the 80% community votes, major Grant loses narrowly. And then, for next Grant round, because it wants to win funding, say the major Grant coordinating party terminated some affiliated parties so that now only 10% of the voting community is excluded (instead of 20% excluded). And then the Grant gets funding. Is that gaming the system? What if Grant coordinator decides to hire back the recently excluded 10% parties after receiving funding? Further gaming? ... But are we ever going to have financially affiliated Grants that extreme? It's hard for me to say.

Just brainstorming at this point: What if we rolled with STV rank-based voting, and all affiliated parties with any one Grant had to vote the average score, say "5th" (out of 10 Grants) for their own Grant? Pretend it's automatically hard-coded and printed into their digital vote card. This way, affiliated parties can express that they cannot properly evaluate their own Grant with respect to others, but they do represent a say as part of the community, so they get a hard-coded 5th (average) rank for their own Grant, as an expression of: "We would like a say in our Grant being funded, but our votes won't swing the pendulum too far any which way."

I want a community-based solution that incentivizes development, collaboration, fair voting, does not discourage small Grant proposals or funding, reduces gaming, and exhibits well-intentioned Best Practices.
 
Secured
What if Grant coordinator decides to hire back the recently excluded 10% parties after receiving funding? Further gaming?
Very good point

Also, on the opposite end, people with competing grants may tank a grant that is going after a lot of FCT simply to help ensure their own grant gets approved.

What if we rolled with STV rank-based voting, and all affiliated parties with any one Grant had to vote the average score, say "5th" (out of 10 Grants) for their own Grant?
This is a really interesting solution. I'd want to give it further thought, but I really like this.

I want a community-based solution that incentivizes development, collaboration, fair voting, does not discourage small Grant proposals or funding, reduces gaming, and exhibits well-intentioned Best Practices.
Very well put.
 
Secured
Given the challenges, the community had with the previous grant round the Cube 3 team would like to pose some questions that may inform how the next round is run.

What underlying principles should govern a grant application round?
We propose that a grant application round should be:
  1. Transparent
  2. Fair
  3. Clear
How do we ensure that we are really clear about the purpose of a grant round?
In the spirit of this latter principle, there should be clear guidelines for what is expected.

We would propose two ways of conducting grant application rounds:

  1. Hold an open round where only an outline is given. An example of such an approach can be seen here https://apply-for-innovation-funding.service.gov.uk/competition/243/overview (with apologies for a UK centric example!)
  2. Hold a specifically targeted round which fits the roadmap of the protocol. Here the ANOs would decide the purpose. For example, if for the next 3 months the protocol really needed core development we would only request applications on this topic.
The only downside of the latter approach is the potential to miss out on the more blue-sky applications which the community may have not thought of yet. Having a general open grant application once a year with a larger pot of say 60% of the annual grant pool FCT plus quarterly specific calls may alleviate this.

How do we ensure clear, thorough and consistent applications?
It is suggested that grant applications should include a mini business plan, comprising:
  • Specific clear, concise objectives
  • Achievable and probably limited goals, not aspirations
  • Outcomes that should be easily measurable by both the community and the sponsor
  • Outcomes that are relevant and beneficial for the community, now
  • Confirmation that the grant work will be owned by the community or open sourced
  • Project Plan showing exactly how the outcomes will be achieved and on what the grant will be spent
  • Consortium or single entity details with an explanation of why they are the right team to do the work
  • Why the applicant believes that it is a sound investment and gives a genuine return which should be quantified
How do we get a portfolio of applications that we can afford?
The grant application process should provide guidance on what an appropriate grant size is. Ideally, this should never more than ¼ of the total funding pot, to prevent the whole pot being swallowed by one or two large grant applications.

Who should assess the grants?
There are some suggested principles:
  • ANOs with any involvement with that grant should not be allowed to vote on that grant.
  • Standing parties who have contributed FCT to the grant pool should be deciding where the funds are spent.

How should the grants be assessed
?
The primary method we currently have is through discussion and questioning of applicants.

It is suggested that future grant applications be reviewed wherever possible by an independent expert in that field if the grant is not general enough. The review should be provided to the standing parties eligible for voting who can then make a better-informed decision.

Grant application discussions should be open to all members of the community but the discussions should be limited to questions and answers, not opinions. The last grant round was potentially biased by ANOs declaring support prior to voting. For the next grant round the forums should be moderated to avoid this. In a similar vein grant applicants criticising other applicants should be discouraged.

How should Grants be scored?
It is possible that in the previous round the scoring was gamed with ANOs voting for more grants that could be afforded.

To simplify this the ANOs should be allowed to allocate only the available FCT. Various techniques could be employed to do this.
 
Secured
Paul posted some good comments about how the grant rounds could be improved in the INC thread :

We have a huge problem of currency risk that just has no good solution.

To clarify the problem, we have the following issues:
  1. At the time of a grant proposal, the price at the time the tokens will be issued is unknown.
  2. At the time of the payments being scheduled, the price when the tokens will be issued (a week later) is unknown.
  3. The income reported and the taxes due is determined at issuance, and is unknown until tokens are issued.
  4. The value of the tokens when liquidated will be unknown.

[...]

Some mechanisms that are possible but not discussed (to my knowledge) so far:
  • Carry overs -- Applying previous grant payments to new grants to split the reward of price rises between development and the grant pool
  • Risk payments -- Additional payments to split the risk of price falls between development and the grant pool
  • Long term lockdowns where tokens issued are not liquidated for longer periods (Create long term incentives)
  • Risk margins, increasing grant amounts by some percentage as a payment to take on risk
Also I am not sure it has ever been discussed but I think it would be wise to accumulate a minimum of unspent Factoids at some point. Considering that the currency risk are huge and that we, potentially, now have a few recurring projects, it would be sad to have to stop something like "code refactoring" at 70% because of a big price drop in a given quarter.
 
Secured
Ok, I'm now trying to work up a document for the next grant round with a few changes to make it marginally better. I think we're still going to need a comprehensive voting solution figured out but there's not really time for this round. We might be able to implement the binary system but there doesn't seem to be complete consensus on that yet and we'd have to amend Doc 001 which adds quite a bit of overhead.

Regarding prohibiting ANOs from voting on their own grants I'd appreciate if people help me figure out appropriate wording. I added the following to Section 4.7 "Voting on Grants" but it might be too vague so I welcome input. @Shuang Leng and @Nikola in particular if you guys can give me proper language to accomplish prohibiting ANOs and affiliated ANOs from voting on their own grants that would be helpful.

All Standing Parties in the Factom ecosystem are eligible to vote on submitted grants except for those materially affiliated with the Grant. This includes, but is not limited to, ANOs directly collaborating on a Grant and ANOs who have direct financial ties to ANOs who are proposing a grant or collaborating on a Grant.
The draft document is here. I've enabled commenting if people have suggestions they want to make to it directly.

I'm going to put up a straw poll for people to express whether they think grants should be denominated in FCT, USD or a mixture of the two. I don't see any better solutions we can implement in the next couple of weeks on this topic. We'll continue to work towards solving these problems for future grant rounds.
 
Secured
@Samuel Vanderwaal "All Standing Parties in the Factom ecosystem are eligible to vote on submitted Grants except for Standing Parties whose vote has the potential to create real or perceived lack of impartiality. Such real or perceived lack of impartiality exists when a Grant, if awarded, affects the financial interests of a voting Standing Party, or the financial interests of a Standing Party’s members and their families. This includes, but is not limited to, ANOs who directly collaborate on a Grant with Grant applicants and ANOs who have direct financial ties to Grant applicants."

I'll make more suggestions tonight in the document (and probably edit what I posted above), after I finish working on a draft of the foundation bylaws that we are working on with Shuang right now.
 
Secured
I'd like to quote Paul Snow from the "Guide Election and Removal Process" thread. Paul wrote the following in response to the topic of -- "All ANO's except for Guides will be allowed to vote."

"Keep in mind, if 5 guilde are also ANOs, and 6 ANOs decide to run for Guide, that means 11 ANOs out of 26 (currently) are not allowed to vote, while any one of these ANOs only has a "conflict" (if that is even true) on 1 out of the 5 guide positions being decided. Even as we move to 65 ANOs and fold in other standing parties, this is a great portion of the most informed that are sidelined from the decision.

The uninvolved at the guide level, and often the people with the least insight into the effectiveness of Guides become the biggest decision makers."

I feel that, at this time, blocking ANO's from voting on their own Grants and/or affiliated Grants severely reduces the pool of applicable voters able to vote on any one Grant. I honestly think that this level of reduction of the voting pool, at this time when we only have about 31 voting Standing Parties, would be fairly radical and have too large of an effect. At a time when we have more Standing Parties, in the future, implementing something like this would make more sense as the voter pool would be larger and the effects of implementing vote-blocking would be far less. We already know there are at least a couple Grants with multiple parties involved; do we really want to block 10%+ of Standing Parties from voting on those couple Grants?

Also, alluding to what Paul states above regarding voting Guides into Guide roles, people that are involved with a Grant or a number of Grants have intimate knowledge of said Grant and should probably be able to vote for that Grant. Grant competitors, who would have the same level of intimate knowledge of their own Grants, could also vote for their own Grants. As a community with few Standing Parties eligible to vote, I just don't see enough of a value-add from full vote blocking in the Grant scenario.

Also, to echo Xavier once more, disincentivizing collaboration between ANO's by vote-blocking is probably not the best solution. If you're trying to build out and contribute to an awesome idea or piece of technology, but you know that by materially helping with that effort, you won't be able to vote on its potential for fruition (via Grant funding), you would surely second guess whether you want to be helping. Our collective goal should always be to spur development and collaboration.

Last, if I could solicit some brief commentary and opinions from all of you about the idea of STV-based voting and the potential for a hard-coded, average "5" score (when out of 10, for example), as this would barely swing the pendulum any which way and would not lead to full on vote-blocking, that would be awesome.
 
Secured
Also, at least in America, something that I believe happens pretty frequently (this is my opinion btw, and not intended to spur any sort of political debate) is that developers or scientists think up amazing ideas and apply for funding. But if there is a politician who can game the system through having intimate knowledge of how voting works or through campaigning in a particular manner, that politician can "out-game" the good idea by the developer or scientist, and the good idea goes un-funded.

A simple voting system (with fewer complexities) is ideal because everyone can understand its rules and eligibilities, and this reduces gaming because the politician mind can't really take advantage of possible attack vectors since there are very few points to attack within the framework of the simple voting system. Just my two cents from a real world example.
 
Secured
I feel that, at this time, blocking ANO's from voting on their own Grants and/or affiliated Grants severely reduces the pool of applicable voters able to vote on any one Grant. I honestly think that this level of reduction of the voting pool, at this time when we only have about 31 voting Standing Parties, would be fairly radical and have too large of an effect.
Well to remove yourself from voting on the grants you are participating in is a must at this time IMO. Exactly for the same reason you mention. We have seen several grants with 3, 4 or more parties. That constitutes almost 15% of current votes (30 parties)
 
Secured
@Niels Klomp - I definitely understand that counter-point, too. It's tough to find an equitable solution for all Parties involved. Would implementing something like STV-based voting with a hard-coded, average score be too much work prior to the next Grant round? If it is, I understand, of course.

Just wondering what your and others' thoughts are, conceptually, regarding that possibility.
 
Secured
I agree with the results we are trying to achieve here. We need to protect against conflicts of interest.

What I wonder though is if this is a good way to achieve those results.

So we are trying to avoid a situation where, lets say 5 ANOs get on a grant, now they have 5 votes in favor and split the funds 5 ways. This is the same result as 5 ANOs each putting in a grant for 1/5 the amount, and agreeing to vote positively for eachothers, right? (Further than that, if its an actor trying to do this in secret, we can easily have a situation with undisclosed equity stake in the grantee that we would not be able to protect against)

The truth is enforcing against such conflicts of interest in a decentralized protocol is just not that simple. We cannot think that barring 5 ANOs from getting on a grant and voting 100% to split the grant payout protects us in the least. It feels like it protects us though, which in my opinion makes it a counterproductive solution because we feel safer with a solution that doesn't actually solve what were trying to solve.

A concrete example that doesn't even involve bad actors, just normal voting: I will use FAT so no one feels targeted, we had 4 ANOs on the grant, so the grant automatically had 4 affirmative votes. Split into 4 grants, we each surely would have voted affirmatively for those other grants, so now we just have 4 grants that each have 4 affirmative votes, totaling the same size. I'm not sure how we end up in a better position in that case.

My opinion on this topic is the same as guide voting.

I lean toward a strategy of distributing standing wide enough that centralization-based gaming becomes infeasible (ie a party voting for something with conflict of interest doesnt matter because standing is so distributed).

Then we can simplify everything to just be, on any vote, the sum of the total standing in the ecosystem that is voting.

-This is far easier to code into an on-chain solution
-And this is far easier to understand, meaning we start closing off gaming via knowledge of the voting system itself (We wan't people to be able to spend as little time as possible learning about our governance systems to be able to participate in them on a level playing field.
 
Secured
Put it in another way. If so many parties decide to participate in a single grant, that means they must see value in pursuing it. That alone should be enough reason for other standing parties to think twice about the proposal and probably already brings them to vote positively (apparently several ANOs see the need to create a large(r) project). No need for the ones proposing to vote on themselves as well. As soon as every grant recipient would not be allowed to vote on it's own proposals it levels the playing field more.
 
Last edited:
Secured
I do wonder then how do we decide each time if grants are related enough to dissalow cross-voting? Are we going to have to judge, decide, maybe argue this any time related grants pop up? Then how do we write that into governance?

After that, how do we codify it when we pursue a more automated on-chain governance and voting solution? Should we have standing-party voting to vote whether a given standing party is allowed to vote on a given grant that seems related to a grant they themselves are putting forward?

Then lastly does this even begin to close off attack vectors if you have bad, or even grey-area actors? Or does it push gaming activity into the background where we'll just never see it.

It doesn't seem like a very robust solution, and I hope we don't find too much comfort in it, because in reality solutions to problems in complex systems like this don't come that easy, they are nuanced and require deep thought and modeling. If they were that easy, there would be a lot less problems in this world.

But if this is the community consensus on the direction we want to head, then by all means lets go for it and put this into the next grant round document. I hope, though, that we don't stop asking these tough questions that will come up eventually. (y)
 
Secured
Julian, I think your point about how the final on-chain standing party system will work is valid. The vision for the final on-chain system as I understand it is that Standing Parties can vote on governance matters regardless and trying to police conflicts of interest on chain isn't likely to be effective or efficient. So it probably makes sense to work with our systems as close as possible to what the final outcome will be. However, given the lack of time to really hash this out if the community wants to go with preventing affiliated ANOs from voting on Grants then in the interest of time we should probably try it out for this round. Let's continue to have these discussions and work on fine-tuning this process to improve it every round.
 
Secured
I feel like right now it might make a difference if ANOs were allowed to vote on grants they were affiliated with, but in the future when there is a larger and more diverse group of standing parties I don't think it will make as much of a difference. I agree that it will be difficult to police conflicts of interest on chain and think going with a simpler approach is the way to go.
 
Secured
First suggestion. All Grant applicants give full disclosure of ANO’s that are in anyway affiliated with the Grant. Affiliated ANO’s are not allowed to vote on that particular grant.
We need to look at this from a future perspective too. When there are full standing parties, like the FCT voting, those won't be attributable to a specific individual, so if we are going to try to emulate the future system state, then we should allow voting for yourself.

This also incentivizes either grantees setting up shell organizations and sibyls (or subcontractors), or it would encourage something like mutual back scratching. To stave off anything untoward like that, just letting people vote for themselves eliminates those incentives.

In the last grant process, Factom, Inc voted for it's own grants, because when there is the full standing parties, that would be a natural outcome.

Second suggestion. Open up a broader discussion on grant liquidation...and how we as a community at large can help not put any downward selling pressure on the price of FCT during grant distribution.
The grant recipients themselves should be the ones to determine if and when they should sell fct. I am against artificially restricting recipients from using the FCT value they were awarded. Let recipients speculate on FCT value if they want to. Don't force them to by doing some lockup scheme. I don't believe it will have much positive impact on any markets and will only limit choices that grant recipients have. The negatives far outweigh the potential benefits in my opinion.





Regarding Backpay:
...
Backpay needs to be allowed. We just need to build some rules around it.
The 2nd round grant did not disallow backpay. I read it very carefully, since I was putting in for a grant for work that had already been done. I disagree with any interpretations that it imply it disallowed backpay. If the community sees value in awarding a grant, whatever the timeframe, it should be allowed.

The 3 month limitation was there to prevent obligating the protocol for yearlong grants for example. There are a few grants that have been paid which still have funds that were allocated, but haven't yet been used (bug bounty, for example), so it seems like there is some fuzz around the edges with the 3 month timeline.


Sure thing. One reason for denominating grants in FCT is the additional complexity in coding involved when having to denominate a grant in FIAT. I mention this because I remember Briary Deery and Paul Snow talk about this issue.
yah, it was a very manual process when we were doing the legal grant during round one. I don't think the tech is ready yet for dollar denominated grants if we can help it. it can be done, but there would need to be 2x the number of fct reserved between the voting and when it gets encoded into the blockchain (this was talked about in the initial governence doc). If everyone wanted to denominate their grants in USD, we would only be able to fund 1/2 the projects than if the grants were denominated in FCT.

Efficiency based voting
While not commenting on any specific voting scheme for efficiency based voting, ANO efficiency was one of the factors that went into standing in the original governance doc. That might be one of the next standing groups to be considered.

Factomize is at 5% efficiency. You're saying our opinion isn't as valuable as Syncroblock's opinion at 60%?
The original thought was that there needed to be some incentive to not run at 0% efficiency. The only thing the protocol has to offer is higher standing weight to run more efficiently. This was one of the other standing party groupings in the original governance doc (up to 50% efficiency).

I'm not sure I agree with this. It's a tough one. On one hand yes, its infinitely easier to just get a sponsor thats in your pocket if you get to choose. ... Why enforce additional rules and bureaucracy, and take a step closer to having the Factom Protocol's governance system itself be deemed a centralized entity with operational and financial oversight of entities within the ecosystem?
I don't think most people realize the risk of looking too much like a centralized entity. Factom, Inc is especially vulernerable from this perspective, having bootstrapped this project into existence. I touch on some of the risks here: https://factomize.com/forums/thread...continuity-plan-dec-feb.1423/page-2#post-9626

One of the things that is planned for the next sponsor meeting is to record and publish it. I hope this will begin to bring more transparency to process we have been building up so far. We are all learning this process as we go along.


It is suggested that grant applications should include a mini business plan, comprising:
Specific clear, concise objectives
Achievable and probably limited goals, not aspirations
Outcomes that should be easily measurable by both the community and the sponsor
While sounding good in theory, this tends to disincentivize bugfixing, which has been the primary effort over the past 4-5 months. This kind of commentary comes to mind: https://news.ycombinator.com/item?id=18379394

it would be sad to have to stop something like "code refactoring" at 70% because of a big price drop in a given quarter.
Well, it is more a matter of timing. If there is a bad quarter and core development can't be afforded, then the network probably isn't being utilized in a meaningful way and can wait an additional 3 months or so to get closer to scale and stability. From the bug count that is pending in the next release, it is clear that the main reason it is still running is that the network is not seeing lots of utilization.

Put it in another way. If so many parties decide to participate in a single grant, that means they must see value in pursuing it.
This is a good point. If they are participating in making it happen, then they see value in it existing, and more people participating means that more see value in it. extrapolated to absurdity, if 95% of the standing parties were working on the project, signifying that it was that important, leaving the decision to move forward on it up to the remaining 5% who aren't participating seems silly.

-This is far easier to code into an on-chain solution
Yes, this is the way we should be thinking. The processes that we are going through should be viewed as emulating what can be done on chain. I don't think we are going to eliminate conflict of interest. I think the best we can do is expand the standing parties so that the interests aren't really concentrated.
 
Secured
While sounding good in theory, this tends to disincentivize bugfixing, which has been the primary effort over the past 4-5 months. This kind of commentary comes to mind: https://news.ycombinator.com/item?id=18379394
We understand your concern about a grant process that disincentivizes bug fixing and we also understand that it may be difficult to quantify the number of bugs discovered/fixed. However, being specific about aspects and making a business case/mini business plan should not be an obstacle to that.

Maintenance of core code (via bug fixes etc) should probably not even be part of discretionary grant rounds at all but be part of the normal ongoing business and be funded differently. In the absence of that then such work is going to have to compete with other grant applications. The other option is to have specific grant round calls as suggested in our previous post, some of these could purely be for core code maintenance.

Many organisations justify expenditure on things like R&D or exploration (as in the case with Oil companies). In academic research when grant proposals are submitted they are obliged to include a risk register to prove that the entity is capable of managing the unknown. It seems, therefore, wholly appropriate to expect an application for a grant to be able to make a case for it.

Certainly, as you did with the last amended submission you made, there should be a quantification of the number of people working on bug-fixing over a period. These cost and time elements cover two of the three factors leaving just the scope definition as a big variable/unknown and requiring community understanding. However, reporting during the grant fulfilment period should clarify this and show the time spent resolving certain bugs as influenced by the severity and amount of testing required.

With regard to the business case. We can easily understand how much it costs to do (number of developers x average cost per developer). Similarly, we can also describe the benefits or disbenefits of not doing it. Here you have a very powerful argument insofar as without bug fixes the code is not robust and the protocol suffers.

The original thought was that there needed to be some incentive to not run at 0% efficiency. The only thing the protocol has to offer is higher standing weight to run more efficiently. This was one of the other standing party groupings in the original governance doc (up to 50% efficiency).
We completely agree with you that efficiency based voting makes all of the other arguments about ANOs voting for their own work redundant.

There is an incentive for ANOs to lower efficiency to do the work that they would prefer to do.

The contribution monitoring is beginning to work and drive better results but we believe that what gets delivered for what investment is not as clear as that managed through the grant system (hence the arguments above to further improve the accountability of grant applicants). Running a fair and transparent grant process that quickly delivers FCT to ANOs and others doing development work would be a great incentive for appropriate ANO efficiency.

If the community sees value in awarding a grant, whatever the timeframe, it should be allowed.
We agree, indeed clearer grant applications can only help the community better judge what the grantee is actually asking for.

leaving the decision to move forward on it up to the remaining 5% who aren't participating seems silly
Grant applications which involve a majority of the standing parties should not be allowed because this presents a number of issues. They would swamp the grant pool and would be difficult to manage to a successful conclusion.

The barrier to entry for such consortia would be low, requiring to convince only 5% of the Standing parties that the project should go ahead. As you say this is “extrapolated to absurdity”.
 
Secured
Maintenance of core code (via bug fixes etc) should probably not even be part of discretionary grant rounds at all but be part of the normal ongoing business and be funded differently. In the absence of that then such work is going to have to compete with other grant applications. The other option is to have specific grant round calls as suggested in our previous post, some of these could purely be for core code maintenance.
In the protocols current state as Inc as the nearly sole core developer, I am almost certain that they would not accept having core dev handled through a separate process to grants. Brings up a host of centralization issues. Maybe once there are multiple core dev entities we can divide the grant pool into a minimum X% toward core dev and entities can compete specifically for that money, but right now thats not really an option.
 
Secured
In the protocols current state as Inc as the nearly sole core developer, I am almost certain that they would not accept having core dev handled through a separate process to grants. Brings up a host of centralization issues.
Apologies, the statement we made obviously wasn’t clear. We do want the core development being handled through grants, we stated that our belief was that the work was of the utmost importance and that we would prefer that core code development wasn’t ‘discretionary’.

Our proposal above as you said was to divide the pool up and have specific grant calls for this. The EPSRC Engineering and Physical Sciences Research Council and the Innovate UK (for higher TRL Technology Readiness Levels) in the UK do this exact process all the time. They even have some calls which are out constantly and are called ‘reactionary’ which means if a great idea comes along then that application can be made immediately.

Maybe once there are multiple core dev entities we can divide the grant pool into a minimum X% toward core dev and entities can compete specifically for that money, but right now that's not really an option.
We agree that there is currently a challenge with Inc being the main developer for core, however BIF has employed a developer who is working on core and Factomize will be shortly retasking Who to work on core development. We do not believe that this is centralised as there are other non-inc people working on core development who we have missed off here. In a future grant round having a separate core development application round should be feasible.

As stated before we believe the grant process should reflect what the community currently needs right now. This means that it should be shaped by the long-term strategy in the road map, which in turn should be translated into short term goals and thus ‘sprint’ projects, which are funded by grants. Once the road map is clear then for each grant round we should know what the community needs at that point in time and the grant round should focus on delivering that.
 
Secured
We do want the core development being handled through grants, we stated that our belief was that the work was of the utmost importance and that we would prefer that core code development wasn’t ‘discretionary’.
This is actually the part I would be a little worried about. Its pretty clear that inc is still at the absolute center of core development, they receive the most money and do by far the most work on core. Have the network that they decentralized with M3 end up setting aside nondiscretionary funding for primarily them could make them very uncomfortable from a centralization perspective from being the original issuer.