This work was approved by the council as motion #355 under gov1, but the proposal is currently failing with only 29% in favor.
The changes introduced with OpenGov left a few proposals like our own in the shadow realm.
The reason I’m writing this post is because some of these proposal including our own were passed under Gov1 by the council.
And there was a social contract to pay for the final milestones AFTER delivery.
Now we’ve delivered the promised work, but proposals like ours are currently being denied the payment for the same under OpenGov.
Since info for reimbursement wasn’t stored on-chain, there aren’t any special provisions for proposals like ours under the new OpenGov system… this means if the proposal doesn’t pass, we need to pay the development cost out of our pockets.
I believe we should respect everyone’s right to vote as they please and feel that they do not owe any explanation for their voting decision.
However, if builders acting in good faith are left at loss due to the recent change without a notice period, I believe it sets a bad precedent.
I personally believe it’s IMPERATIVE to attract and retain teams that act in good faith and try to contribute to a flourishing DOT economy.
And an event like this can be discouraging, even severely damaging for builders.
I can definitely agree that if the council originally approved some multi-milestone proposal, that generally OpenGov should approve paying out successful completion of that work.
In this case, it seems the payout will cover the entirety of the approved proposal as milestone 2 + 3 were the last things noted on the overall proposal.
However, speaking hypothetically, I don’t think all such contracts should fit into being legacy supported. For example, previous support for reoccurring infrastructure projects from the council should not imply that these projects will perpetually be approved by OpenGov. Similarly, there are maybe some projects which have extremely long timelines, and many milestones, and these should be re-evaluated by OpenGov. Finally, there may also projects which council has approved, which token holders may not find valuable.
In general I might loosely suggest the following:
We as token holders should mostly support the teams which have been approved by council and do good work for the next year (till June 2024), as we transition from Gov v1 to OpenGov.
Teams which have milestones or projects which extend beyond a year should create a signaling proposal through OpenGov to at least see if there are any clear outstanding dissent for the proposals.
If there are projects or teams which are getting shut down by OpenGov, when council has previously given support, we should call on previous council members to write an updated response on why token holders should support the proposal, or why their perspective has changed since their last commitment. Conversation can continue from there.
One last note is that I do not think the forum would benefit from having many posts which are “support my proposal #X”. In generally, I think we should ban such posts where there is no discussion around the proposal, just begging. (cc @Remy_Parity@rhee)
Clearly, this post does have a relevant topic to discuss, but you can see how others might read this differently.
P.S. I have submitted an AYE vote for your proposal.
Thanks for your comment, Shawn. I completely agree with your thought process.
I think one year is enough time for teams to figure out alternative strategies/plans and create a mitigation strategy for funding.
One last note is that I do not think the forum would benefit from having many posts which are “support my proposal #X”. In generally, I think we should ban such posts where there is no discussion around the proposal, just begging.
Clearly, this post does have a relevant topic to discuss, but you can see how others might read this differently.
I’ve changed the topic to better represent the topic of discussion. Thank you for the feedback
P.S. I have submitted an AYE vote for your proposal.
Love your ideas and feedback, especially this part:
And of course “support my proposal #X” related topics will be warned & deleted (instead of insta-ban).
In that sense, @batman please remove all the emotional wordings from your contents and give us a summary of the key metrics/deliverables your dashboard has been contributing so far for the sake of Polkadot Ecosystem, so that the audience can clearly see what brought you here to highlight about your proposal, thanks in advance.
Yeah, I agree that this situation is probably temporary in nature, and better handled using some manual work than building superfluous details on chain.
@shawntabrizi - I think that’s a good point, If theres no actual ‘discussion’ taking place within the post then it’s safe to say that it’ll be deleted or at minimum ask them to revise it so it includes a relevant discussion point.
Following up on this, recently there have been a couple of discussions/proposals put forth by the community that highlight the need for more flexible funding mechanisms.
The Teddy DAO proposal seeks a DOT loan to pay for their expenses using staking rewards.
The Incentive Pools proposal suggests a commission based funding solution to align incentives of the builders with the treasury.
Of course, commission based funding requires a good deal of scrutiny due to the subjectivity of what metrics to incentivize, how to verify them, etc. so I’ll refrain from discussing it in this post.
But I do believe that the need for a “pre-approved” funding track could greatly help with predictability for the following use-cases:
Recurring Payments
Multi-Milestone Payments
How it might work
Proposer submits a request to the treasury under OpenGov with a “payment_type” argument (one_time, recurring(until_time), multi_milestone(num_of_milestone)) - there can be a max cap for until_time (1 year probably) and num_of_milestone (6 milestones)
OpenGov approves/rejects proposal
Post the initial execution when the proposer submits a follow up request for payment of milestones/reimbursement of costs, the payment request could be fast-tracked with a “pre-approved” track, with a shorter decision period and maybe a lower threshold?
Seems that the discussion has been up for about a year now, curious if it’s something that’s still under consideration/development?
On a tangential note, I really like the idea for a reputation system and a user-friendly mobile app with customizable notifications.
Not sure if someone has built/is building this, so thinking out loud here.
A team’s reputation for any given “category” (e.g. DeFi Infra, DeFi App, Dev tooling, Gaming Infra, etc.) could be broken down into the following variables IMO:
Team Reliability %
100 * no. of projects shipped successfully / (no. of failed projects + no. of projects shipped successfully)
Failed projects = Projects abandoned prior to completing the promised work
Average Project Quality Score
Quality of shipment can be measured across 2 metrics with public ratings (e.g. 1 = poor, 2 = fair, 3 = good, 4 = excellent, 5 = world class):
User/dev experience
Robustness
Total funding received by team from treasury till date
I do believe that it’s important that the reputation score is displayed alongside the “Category” Benchmark, for how people vote about the project quality could greatly vary between different types of projects.
Would love to know what you think about the reputation logic.
I’d be happy to draw up some mockups and build a PoC over the coming weeks.
