Proposal “Project-updates-via-proposal-system“ (Active)Back

Title:Project updates via proposal system
Owner:GrandMasterDash
One-time payment: 1 DASH (60 USD)
Completed payments: no payments occurred yet (1 month remaining)
Payment start/end: 2023-01-10 / 2023-02-09 (added on 2023-01-05)
Final voting deadline: in 21 days
Votes: 268 Yes / 130 No / 59 Abstain
Will be funded: No. This proposal needs additional 247 Yes votes to become funded.
External information: www.dash.org/forum/threads/pre-proposal-project-updates-via-proposal-system.53469/
Manually vote on this proposal (DashCore - Tools - Debugconsole):
gobject vote-many 0726dcda67fd99fc6e90e8d01cfc01f2abab1423c3df1002c5a8ccf95ba72f0f funding yes

Please login or create a new DashCentral account for comfortable one button voting!

Proposal description

All projects receiving funding must submit at least one project update per cycle via the proposal system.

Criteria for updates:

  1. standardized tag to distinguish them from regular proposals.

  2. must be submitted at least 5 days before the voting deadline.

  3. cost 0.1 dash and must be signed by the private key receiving funds.

  4. no payouts, no refunds.

  5. must contain at least 120 words*

  6. optional; link to image which will appear before main text (stock photography or other).

  7. prompt Proposal Owner to include milestones, due dates and KPIs, but not enforced.

  8. failure to provide at least one update per cycle will automatically and permanently de-fund the proposal.

Benefits:

  1. provides a guaranteed source for project updates.

  2. updates can be automatically extracted for blog posts / newsletters.

  3. keeps on-going proposals fresh in MNO minds.

  4. zero tolerance for no progress reports.

* The minimum word count criteria is based on the concatenated
readability of 20 live proposals; 120 x 20 = 2400 words. This number is
close to the recommended word count for fintech blogs / articles, which
typically expect higher word counts.

Source: https://neilpatel.com/blog/long-blog-articles/

Work to be carried out by owners of the dash protocol (currently DCG) within
6 months of this proposal passing. This proposed work is deliberately
simplified and absent of Platform functionality. Technical documentation
and a reference HTML/JS form is expected.

Automated blog posts / newsletters are expected to be built by independent community members and NOT by DCG.

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
0 points,8 days ago
It's fine. This vote also means DCG can not do this in the future because the DAO has voted against it.
Reply
2 points,11 days ago
Dash-Ru community votes "yes"
Reply
1 point,10 days ago
Thank you.
Reply
2 points,14 days ago
Every PO should be able to write 120 words even when there is no visible activity. I feel it should be relatively easy for a PO to talk about their motives and passions on any given day, it doesn't have to be specific to one specific proposal.

People like updates but, more importantly, they seek passion and inspiration. This is the very reason why people get into DAOs in the first place.
Reply
1 point,21 days ago
If this passes I'll focus on it being implemented in the Incubators governance site (this uses platform for proposal content & comments along with DashPay users for all actions). This would act as a front-end for the users to provide these updates in a consistent (and immutable, blockchain hosted) manner which any other governance site can also implement or pull-from. Protocol level enforcement of such would probably come from DCG.

I'm always more in favor of empowering MNOs with choice. So I would believe more in 'vote for 1 cycle'/'vote for all cycles' options where MNOs can use their own discretion to vote each subsequent cycle than to force defund if a PO doesn't hoop jump.

I have no issue providing monthly (or more regular) updates; when I first started with Dash I did weekly updates and even recorded vlogs, would be fun to do again. A single source of truth is important here, Kickstarter is a good analog with their updates section.
Reply
0 points,21 days ago
Thank you for your response.

I think you are saying, the resumption of updates should resume payments? I am not convinced this is a good idea. Ideally, the Proposal Owner would submit a new proposal explaining *why* an update was missed. There might be a legitimate reason, in which case their new proposal would likely pass for all the reasons it passed in the first place. This should not be a problem given the price of submitting a proposal is relatively affordable.
Reply
2 points,21 days ago
No, I'm saying MNOs should have an option to:
- Vote for all cycles
- Vote for just this cycle
and they can then choose whether they revisit their vote and check for updates. I'm not keen on forced fund/defund, I am keen on empowering MNOs with choice.
Reply
1 point,21 days ago
Choice is the status quo, POs going dark without consequences. The network deserves better.

Maybe you should submit an alternative proposal.
Reply
0 points,21 days ago
Which POs are going dark without consequences?
Reply
2 points,21 days ago
Come on, really? Don't have to go far to find proposals that went dark. Your boy Mr Francis gave his last update about CTX when and where?

Or, perhaps we can talk about another one close to home, the Arizona State University. Do any of the following ring a bell?

----------
Dash-and-ASU - 350K USD!

"This proposal is for a charitable grant in student scholarships, research labs, open source research projects and a blockchain course creation totaling $350,000."

https://www.dashcentral.org/p/Dash-and-ASU
----------

----------
Or how about this one, ah this one's a cracker!

dash-core-group-research - 100K USD

"This proposal is to provide a grant for specific blockchain research related to zero knowledge proofs on the Dash network."

https://www.dashcentral.org/p/dash-core-group-research
----------

Anyone care to remember the endless payments to Alt36 whom literally only came alive when they wanted more money?

----------
Or maybe an example of Long Living Spam Proposals...

Allocate-100-DASH-to-Dash-Crypto - 50 - 450 DASH accumulator over 5 proposals

24 months (2019-07-16 - 2021-07-01)

Dash price per month in USD:
119, 94, 90, 70, 60, 49, 122, 120, 43, 75, 73, 72, 69, 93, 73, 66, 79, 97, 126, 259, 220, 347, 349, 169, 136
----------

Anyone else care to give examples of leechers who could not bring themselves to type 120 words per month?

A list of Proposal Owners can be found here:
https://mnowatch.org/proposalowners/
Reply
-1 point,20 days ago
How would your proposal solve this?

ASU didn't come back for funding. -> this doesn't solve things

The DCG ASU one from 2019... I have no idea what happened there. Was before my time as an officer. -> this doesn't solve anything unless you plan to defund DCG if I don't find a way to give an update from a proposal 4 years ago. Also that was a one time proposal it seems like.

Allocate-100-DASH-to-Dash-Crypto -> Well... that never passed, doesn't solve anything.

What I'm asking you for are example of something recent where we would benefit from this system.
Reply
2 points,20 days ago
You asked me which POs went dark, I answered. I gave you a recent example, Ash's CTX.

I do not think it fair to dismiss older proposals as the proposal system is largely untouched throughout, including under your role as CTO.

From what I remember, the PO for "Allocate-100-DASH-to-Dash-Crypt" was previously funded, They made several good comical ads for dash. The content was not the problem, it was the POs attitude that sucked. That is why they were de-funded.

As always, these POs come and go like a bad smell. They grab the money and eventually run.

What is wrong with the Alt36 example, besides being before your time? For years Ryan Taylor would sing their praises, tease MNOs with crumbs while defending no updates as a consequence of NDAs. This proposal says the POs must defend themselves, not someone else.

Here we are with a proposal for minor changes and a path to full protocol compliance, and you are effectively saying that not trying to change things is somehow going to be better.

Perhaps an analogy. In many countries there is a tax on disposable plastic bags - we are talking pennies. Personally, I think the tax is unwarranted but it actually works to reduce litter and harm to the environment. When a PO has to pay a monthly tax and, eventually, the protocol is enforcing updates, perhaps then POs will be re-considering the value they bring to the dash network.

Maybe there are different incentives to try, let's hear them. But right now this is the ONLY ONE on the table and I really do not understand what you have to gain or lose by rejecting this. Indeed, I fully accept that six months down the line we might need to tweak things, why not?

The crux of this proposal is to put updates on the same or parallel rails as proposals. To have a common and authenticated source of truth that can be pulled off like an RSS feed. You don't see the value in forced textual updates, fine, so why challenge the detail to avoid the better good?

Heck, you don't even need this proposal to pass for you as CTO of DCG to actually do _something_ about this without kicking it into the long grass for later. This is exactly why I tried to keep this simple. I failed because here we are arguing over the small stuff.
Reply
0 points,17 days ago
If a proposal goes dasrk, the MNOs that supported it shoud pay the loss.

https://www.dash.org/forum/threads/pre-proposal-if-there-is-no-lamassu-deliverable-should-the-masternodes-who-voted-for-it-pay.12369/
Reply
2 points,23 days ago
@GrandMasterDash Can you confirm the following is the way you intend this proposal to work? It wasn't very clear to me. Is seems like you expect enforcement of this on the protocol level? I believe you expect people to write the update directly to the blockchain? And then only having a payout if the amount of data written exceeds a certain number of characters? Is this correct?
Reply
2 points,23 days ago
I am proposing the mechanics for updates follows a similar path to proposals i.e. the text is not stored on-chain. @TroyDASH has raised the concern that the word limit can not be enforced at the protocol level, and I understand this, but then again the editing of text in regular proposals can also not be enforced / scrutinized. I will come back to this point...

So here's the thing, I understand you want to move governance to Platform at some point in the future, and I did not want to submit an overly complex proposal with such dependencies. So how I envisage this, for now, some parts can be enforced at the front end and some parts at the protocol level. When you are ready to move governance to Platform you will have something to work from and you can make it more robust. For example, the HTML/JS front end could enforce the word count and the protocol can enforce de-funding of a proposal where 0.1 dash was not submitted on time.

My thought process is to get something done now with minimal work. At this point we just need:

a) a HTML/JS front end for submitting updates.

b) a standardized way to distinguish between proposals and updates.

c) modify the protocol for permanent de-funding where an update fee of 0.1 dash was not received on time.

d) the natural thing to do would be to put both proposal and update text on Platform later when you are ready. At that point I imagine enforcement would be relatively straight forward.

DCG would be providing the means to collate and authenticate updates that the community can use.

For now, if a Proposal Owner did go to the trouble of avoiding the minimum word count, it would be patently obvious and it would perhaps inform MNOs of their intent.
Reply
0 points,22 days ago
a) Okay, so for the "HTML/JS front end for submitting updates." I believe this would need to be a feature in DashCentral. Since DCG doesn't control DashCentral Rango would need to be okay with coding up this change.

b) okay

c) okay

d) okay

I think the biggest issue I have here is that I'm not so sure why we need blockchain for this. Obviously everyone is going to submit the 0.1 Dash update every time even if they don't really post an update.

Let's run down a scenario, 12 month multi-proposal.

Either:

a) DashCentral adds a section to give updates on proposals. Every month the PO posts a 0.1 Dash "update" but might not actually write text on Dashcentral. Well... MNOs either vote the proposal down or not.

b) DashCentral adds a section to give updates on proposals. The PO posts an update or not. MNOs either vote the proposal down or not.

Posting a 0.1 Dash "update" doesn't really serve a purpose other than to slightly inconvenience the PO.

I believe what you really want is consensus that POs must give updates on Dashcentral.
Reply
0 points,22 days ago
Updates will use the same or paralleled rails as proposals. You might want to create a standardized tag to distinguish them from regular proposals, as listed in point 1 of this proposal. In the same way any governance tool pulls its list of proposals as a central point of truth. The proposal data / metadata within the Core desktop wallet does not differ from those at Dash Central or DMT.

Community tools - such as Dash Central or even MNOwatch - may or may not choose to use DCG reference code on their site for updates, it is their choice. What are their incentives to allow empty updates, more so if they are themselves masternode owners / voters? Who's side are they on?

*** Keep in mind, in the medium term DCG will of moved governance to Platform and you will be enforcing this rule at the protocol level anyway i.e. text stored on Platform ***

In the meantime, Proposal Owners using the sub-domain "proposal.dash.org" will be required to meet the minimum word count.

Finally, I am assuming these changes pose little to no risk to the network.

I am not quite what you are saying about Dash Central, they point users to the sub-domain "proposal.dash.org". They do not have to post proposal updates but the whole point of this exercise is to give them the tools to easily pull authenticated updates using the same or similar methods to proposal data.

DCG is providing the tools and reference code for others to adopt. As protocol owners DCG is leading by example and incorporating these changes at proposal.dash.org.
Reply
2 points,22 days ago
https://proposal.dash.org/ sucks.

You have better use https://mnowatch.org/proposal-generator/
Reply
1 point,24 days ago
And what about the goverance decisions?
I think that kind of decision should be allowed to be multi month without requiring to report every month.

For example, the 4k_HPMN proposal should last 24 months! It is a terrible mistake to have a governance decision last only one month.

Because after 24 months, many masternodes who voted now in favor or against it they may have sold their masternodes, so a new vote outcome for this governance decision should be calculated by taking into account the opinion of active ones after 24 months.
Reply
2 points,25 days ago
This is unenforceable - POs will update mnos in whatever cadence and manner that they think is sufficient to get funded. In the past we had some POs opt out of dashwatch reporting and they still got funded. I dont think we can, and I don't think we should, box in POs into a specific rigid structure like this
Reply
0 points,12 days ago
Could the PO signal when launching the specific proposal whether or not the intend to remain within the reporting structure, in the future this could be a modifiable parameter that says the PO will report every cycle, 2 cycles or whatever, for example development doesnt often benefit from monthly reporting.

If the PO decides not to report but asks for a large amount of Dash, then MNOs will respond accordingly.
Reply
1 point,10 days ago
I believe every PO should be able to write 120 words every month. Is there an example where a PO might not be motivated to write about their project or passion?

Let's just pick a completely random proposal example that fits your scenario. Perhaps someone is working with Japan's crypto regulators to get dash re-instated and likely the regulator is VERY SLOW...

1. Knowing it is a very slow process, why is the PO asking for monthly payments?

2. If the regulators remains silent, can the PO write about similar work with other cryptos / regulators? Can they elaborate on the processes and the people involved? I suggest a good lawyer - or the PO in communication with the lawyer(s) - would find such topics easy to write about.

3. But let's just say, for arguments sake, the PO really is incapable of writing updates, could they pay someone else to write the updates and put that cost onto their expenses?

For reference, this reply to you has 170 words.
Reply
1 point,5 days ago
When you put it like that, its pretty difficult to argue against. The only other issue is the 'how' would the reports be shared. Onchain is possibly overkill. I feel like this proposal would of benefitted from more discussion before being launched, because the overall idea is sound, but the implementation is till too vague.
Reply
0 points,4 days ago
The proposal was sitting on the official forum for 14 days without a single word from DCG. This is normal behavior, it is rare to non-existent that DCG ever respond to any proposal unless it's their own or a competitor.
Reply
1 point,25 days ago
We could continue letting proposals pass, initial votes remain in place, while the Proposal Owner goes dark and collects money every single month. Out of sight, out of mind. Where were the updates from, CTX? Where are the updates from dash incubator? And so on.

For, even if a Proposal Owner is providing _voluntary_ updates, it could be anywhere, on a gated social platform that only a minority of MNOs actually use. Not everyone is active on discord, telegram and other. In contrast, MNOs are using (or should be using) one of several front ends (dash central, DMT, Core desktop wallet) to view open (not gated) proposals. Why should project updates be any different? A signed authenticated source of truth, no less than the proposals they made. Not tucked away somewhere but in your face every month. These updates follow the same process as the very proposals they made. Apparently, It wasn't too rigid when they made their initial application.

The expectations of this updates is not high, just 120 words. Is this too much to ask from a Proposal Owner whom claims to be passionate about their work? The PO might want to provide insight of their work, why it is so important to dash and beyond. If a PO chooses to copy-and-paste the same boilerplate text every month, it would at least be in our face and we can adapt our questions and decisions while it is fresh.

I can not fathom how a Proposal Owner could be so busy (or idle) that they could not want to engage with the community.
Reply
1 point,21 days ago
Re: CTX
Last proposal was just a maintenance proposal to cover infrastructure and security / node updates - no feature updates so not much to share. I'm a pretty active communicator and always did thorough Dash Watch reports. I would be okay with doing monthly reports again.
Reply
0 points,24 days ago
Wouldn't it be simpler to just propose eliminating multi-month proposals?
Reply
2 points,24 days ago
Eliminate multi-month proposals? And what about the governance decisions?

I think the governance decision should be multi-month proposals by default, in order to give to the active voters the option to reconsider their vote.

Otherwise many masternodes may decide something in a monthly proposal, and a few months later many of them may sell their masternodes, but their governance decision will still be valid!
Reply
0 points,24 days ago
I think there are pros and cons to multi-month proposals. I am not sure I would want to eliminate them entirely, it seems to be more about incentives.

Ask yourself, are we really hiring contractors that find monthly updates of 120 words too much of a burden? Can we not find people that are passionate about their work and eager to share their journey?
Reply
0 points,24 days ago
I'm not convinced this addresses the root issues. Even if proposal owners complied (which they don't have to), I wouldn't consider getting a word salad update any different than no update at all. I think ultimately it's the responsibility of MNOs to not support POs who don't perform or communicate sufficiently. I do think we could use watchdogs of some sort, but I'd rather use the proposal system only for proposals, not adding supplemental information separately. Some proposal owners just edit the original proposal to add updates, wouldn't it be better to keep all the info about the proposal in the same place?
Reply
0 points,24 days ago
Criteria 8 says the PO must comply or they are permanently de-funded.

Updates being appended or buried inside the original proposal could easily be lost in the noise, especially if it's a particularly long proposal text. Pulling updates without the original proposal allows for some automation in the production of newsletters without regurgitating entire proposals. The current situation is that someone like Marine has to approach all POs separately before editing her final newsletter.

I think seeing a separate monthly "word salad" is entirely possible, but this in itself informs us (or newsletter editors) of the POs commitment. It is a "comment bump" to keep it fresh in our minds that the PO should be held to account. I believe history has shown that out of sight is out of mind.
Reply
1 point,23 days ago
Remember that the proposal text is not stored on-chain, so any word count requirement can't be enforced by the protocol. Also I think that as a general policy, anything that goes out in a newsletter from DCG needs to be manually reviewed no matter what.

All this being said, I do agree we have a problem with proposal updates, but for now I am more inclined to look for a solution that are not at the protocol level. Everything we do at the protocol level consumes valuable dev resources and is hard/takes a long time to make even minor changes to it. This might be another case of just because we can do it this way doesn't mean we should.
Reply
1 point,23 days ago
Not only the final proposal text that leads to a monthly reward should be stored on-chain, but also the required project update text should also be stored on-chain.

It is that simple, force the proposal owners to write here --> https://mnowatch.org/history/
Reply
1 point,23 days ago
Or maybe use the dashplatform to store.
Reply
0 points,23 days ago
Regular proposals too can be cheated e.g. text can be added or removed without any enforcement. A Proposal Owner can make promises and then edit and deny any such claim, and there is nothing in the protocol to prevent this from happening.

We trust in third party apps (such as Dash Central) and of the watchful eye of the community that such poor behavior comes to our attention. So I don't see what the difference is with project updates. Most of the criteria can be captured at the web front end. The proposal can be de-funded at the protocol level if the PO fails to submit 0.1 dash.

As for newsletters being manually reviewed, please refer to the last line of this proposal:

"Automated blog posts / newsletters are expected to be built by independent community members and NOT by DCG. "

Automation here is referring to the collation of updates, not to the final edit or actual distribution. It is akin to an authenticated RSS feed.

Whoever is building a newsletter does not have to reach out to every PO and wait on them. The newsletter editor can be sure the updates are coming from a genuine source and they can readily see if the PO has cheated the system.
Reply
0 points,23 days ago
Even then, there are a growing number of algos and AI tools that can further automate. Again, this is not the expectation or responsibility of DCG. Such things can be built by the community.

This proposal is simply saying, here is a verified source of truth that is held to the same standard as a regular proposal.
Reply
1 point,23 days ago
We already have the tools.
Proposal owners, in order to be funded, they should submit their final proposal to OP_RETURN https://mnowatch.org/history/ or the the DashPlatform.

But then, a protocol change is needed, and DCG must be involved to this, not to pay proposal owners who do not submit their approved proposal and their project update text in OP_RETURN or in the DashPlatform.

Thus, DCG is also involved somehow, not to write the entire code but do some slight changes.
Reply
0 points,23 days ago
DCG has already said they intend to port governance to Dash Platform. At which point all proposal and update criteria can be fully enforced at the protocol level. This is why I deliberately made this proposal straightforward without any complication or dependence, I didn't want people saying "DCG are too busy". Someone who knows their way around the treasury code can do this work in a day (not including testing and documentation).
Reply
1 point,24 days ago
Comment bump! I will certainly use it, because my proposal (mnowatch) is just for the hosting of the site, thus my proposal is ideal for comment bumping.

If comment bumping is allowed, and if the mutlimonth governance decisions are allowed NOT to submit a montly comment, then i think I will vote in favor of your proposal.

But then, and in case your proposal pass, who is going to code your proposal? And more importantly, what will be the concequences if DCG refuses to codes it? I think you should vote the numbers, and propose a reward to the one who will code your proposal, by using the base4 vote the numbers system.

https://www.dash.org/forum/threads/pre-proposal-would-you-like-to-be-able-to-vote-with-number-v2.52643/#post-233231
Reply
3 points,23 days ago
If the proposal passes we will code it up, if we can understand what exactly to code up :)
Reply
1 point,23 days ago
I assume DCG's work should be to check OP_RETURN or the DASHPlatform, and if no text is submitted there by the proposal owner, then the protocol should not give the reward to the proposal owner.
Reply
0 points,24 days ago
DCG claim they are responsible for the dash protocol. By voting Yes, the masternode network (the legal owners of DCG) are directing them to make these changes in good faith on the basis it does not pose any substantial risk to the network.
Reply
2 points,25 days ago
interesting.
Reply