Extra Mandatory Fields During Proposals Submission

Governance
1

This discussion aims to highlight the current problematic practices during proposals submission and identify the best possible approaches to improve the process.

We propose a simple yet effective solution to set the standard and encourage everyone to share their feedback or alternative suggestions.

Overview

OpenGov on Polkadot has been operational for just over a year.
In this brief period, it remains in an experimental and developmental phase, with significant room for improvement across various areas.

With over 500 proposals approved to date, the outcomes have been diverse. Some initiatives have proven highly beneficial for Polkadot, while others have been less effective or not effective at all.

This situation has led the community to engage in discussions about how to minimize unnecessary and ineffective spendings on proposals, aiming to enhance overall efficiency and accountability.

The main problem begins during proposal submission rather than post-approval!

One of the key reasons this occurs is because a significant number of proposers fail to clearly display crucial information during proposal submission.

Let’s take a closer look at this info:

  • Brief Context
    • Every proposal should start with a brief, clear description of its purpose, goals, and anticipated benefits for the Polkadot ecosystem. It is important to be able to describe your project in a few sentences. “If you can’t describe your business model in ten words or fewer, then you don’t have a business model.”
  • Duration
    • Accurate time estimation is vital for effective project management.
      Proposers must include a specific timeframe, detailing how long the proposal will take to be fully completed. This practice not only helps in the accurate calculation of the total funding request by ensuring realistic expectations but also plays an important role in the final direction of the vote.
  • Deliverables
    • To enhance clarity, proposals must list clearly the expected deliverables, ideally each with a brief explanation. This practice helps voters quickly grasp the key tasks and their benefits for the network, making the proposal more accessible and understandable.
  • Direct Point of Contact
    • It’s essential to provide direct contact details within the proposal, even if submitted by a third party or intermediary. This ensures that stakeholders can easily reach the responsible parties for any questions or further information.

What do we propose

With the focus being solely on Spenders track,the extra mandatory fields we suggest to be added during proposal submission are:

-Expected Deliverables
-Proposal’s Duration
-Direct Point of Contact

There are mainly three things we would like to achieve with this implementation:

1. Familiarize proposers with this common good practice
Many proposers fail to clearly provide this simple yet extremely important information which results in a lack of clarity and consistency across proposals. In addition, this makes it difficult for voters or other teams to assess and evaluate them effectively.

By familiarizing proposers with this common good practice, we aim to standardize the submission process, ensuring that all necessary details are provided in a clear and concise manner. This not only improves the key structure of proposals but also facilitates a smoother review process, ultimately leading to better decision-making.

2. Automating data fetching
New emerging tools and teams are being developed around OpenGov as it matures even further. Even if you can collect some available data automatically from existing sources in an instant, there is no other way at this current stage than to manually clarify and extract deliverables or proposals’ duration.

This inevitably will be unsustainable, especially in the long run where the frequency of OpenGov proposals will continue to grow even further.
Automating data fetching directly from an API streamlines this process, drastically reducing the time needed and eliminates potential human errors. It also ensures that all data is consistently formatted and up-to-date, making it easier to manage and analyze.

3. Eliminate the risk of altering promised tasks
Most proposers provide crucial details using Google Docs format, which are easily editable and untraceable.This poses a significant risk as the promised tasks and other important information can be altered after submission, leading to potential deviations and trust issues.

By having this data clearly presented in existing OpenGov tools or even on-chain, we can ensure that all information is immutable and always identifiable.This enhances transparency and accountability, as any changes made post-submission would be always visible and verifiable.

Solution

There are three possible approaches to accomplish the goal:

1. Simple Format on Description section
By utilizing our existing options, proposers will include this information in the Description section during the proposal’s submission. To accomplish this, it is essential to onboard the entire Polkadot community, current or future DVs and other key players to reach consensus on instantly NAYing any proposal that does not follow this route.
However, this is a temporary solution as it does not automate data fetching, it relies on the involvement of many third parties and does not mandate the act, making it easy to overlook.

Untitled-1-Recovered
Untitled-1-Recovered758×754 25 KB

2. UI Level Changes
By having Polkassembly/Subsquare add these extra fields during proposals submission on their UI, it mandates the act and also allows tools or other teams to retrieve the data from their API. While proposers can surpass these requirements through pjs, presumably very few due to its unfriendly environment, this implementation marks a significant progress and a positive step forward.
Quick preview on how could be displayed from a UI perspective:

-During Submission

Untitled-1
Untitled-1644×1061 47.6 KB

-Post Submission

Untitled-2
Untitled-2750×759 18.5 KB

Untitled-3
Untitled-3754×915 50.4 KB

3. Protocol Level Changes
Targeting these changes directly at the protocol level is the ultimate outcome. It mandates the act, making it enforceable for everyone, and we truly set the standard.
However, something that could raise concerns is the probability of overloading the chain with ‘not-so-useful’ data, especially for the expected deliverables part, as the data can vary pretty dramatically from one referendum to another.
Or maybe not… :sunglasses:

Final Thoughts

This is an initial attempt to further improve the overall experience of OpenGov and enhance accountability.
Setting the standard is not an easy task and it needs a collaborative effort to be accomplished.

Getting community’s input and reaching consensus is vital as a first step.
We invite everyone to share their thoughts and any further recommendations on the topic.
Appreciate all the help and any kind of feedback is more than welcome!

You can always contact us on X or at contact@ogtracker.io

3 Likes
2

While I fully agree that the ecosystem should work towards finding the best framework for presenting and analysing a proposal, and there are some good ideas about this in the post, I strongly believe that they should remain as recommendations about how to design your proposal and nothing more.

Ultimately, I’m not sure that raising the barrier to entry is the best way to go. It’s just going to make Polkadot more of the technocracy it already is, and may discourage really good players from other ecosystems from interacting more with us.

Bad UX is already what’s plaguing our ecosystem, and a real struggle for those curious enough to come. Let’s not deliberately create more.
Worst of all, in addition to wasting blockspace, i beleive it will only enable “professional grifters” to grift even more because they will have fewer competitors.

I believe there are other ways to improve accountability, holder due diligence and the overall quality of proposals than on-chain complexity.
We’ve reached 1000 ref, yes, but how many “please vote no”?

Firstly, the Head Ambassadors should of course guide external projects and the biggest spenders, making sure they’re well informed about OpenGov best practice. This should only help us to raise the bar in terms of the quality of proposals and set a better the standard.

Secondly, fund decentralised voices so that they can actually spend some time discussing, giving feedback and communicating better with proposers.
It would be nice to have more places like AAG or OpenGov office hours.
We could even make it mandatory. DVs are supposed to be ecosystem agents, I don’t mind raising the bar for them. Especially if it’s funded by the Treasury.
At the moment, DV is a priesthood, but we definitely need the plurality of opinion it brings to OpenGov.

Thirdly, on altering promises, we could have a body dedicated to tracking/storing/reporting on proposals. I understand that part of OG Tracker’s mandate was to do something similar, but maybe you should increase your funding if there is an aspect of OpenGov that you cannot fully cover today.

Finally, if we really want accountability, let’s do what any company of our size would do. Let’s hire some lawyers.

Our problems don’t come from the Spender selection process or the way they are presented (although we can always improve it for QoL reasons), our problems come from the fact that someone doesn’t have much to lose, other than their reputation, by cheating the Treasury. (Hello Brad). And as nice as OpenGov can be, it will always fail to actually enforce anything funded for an off-chain activity.

We’re supposed to be getting some Cayman Island legal wraper soon, and I would be very much in favour of looking at a way to get medium and large spenders to sign a binding contract with that entity or one of its local chapters. That’s how we will create real enforceability and accountability. It’s also a way of setting a standard.

Having been the first truly decentralised body of token holders, perhaps we could be the first powerful enough to sue our own grifters.

1 Like
3

This is An important step towards protecting open gov from bad actors.

It might be more advantageous to make it as a minimum to summarize in the simple format.
Then depending on the proposal origin eg big spender it should be made compulsory to fill the extra fields in polkaassembly or sub square.
This way excess unnecessary info might not overload the chain.

4

This is not about raising the barriers to entry but to guide proposers and lead them towards the right direction.

OpenGov is a funding mechanism, along with many other things, with teams, individuals or businesses proposing an idea that could be very beneficial for the network and its holder.
In many cases these requests exceeding 6 or 7 digits and the very least we are expecting from them is to convey a clear message and provide all the crucial details needed to help the community get a comprehensive understanding and make an informed decision.

Strongly believe that the extra fields we are suggesting are the bare minimum and the absolute basics.

We totally agree that it’s not necessarily has to be mandated.
However, it is extremely important for these practices to be highly recommended by the vast majority of the community in a regular basis.

Take on-chain id for example. This specific act is not mandated but we managed to reach unofficial consensus and make it the standard. (Approach #1)
Also the recent UX improvement helped a lot on that front as you are now able to verify your identify with just a few clicks through Polkassembly.
By taking Approach #2 and even keeping it as an optional requirement, it still needs the combination of Approach #1 to effectively work.

About HAs and DVs: Yes! They can tremendously support these efforts, and their contribution is highly anticipated.
However, both are quite new concepts and are still in an experimental phase, trying to figure out what works best.

Most community members are completely detached from what is the actual current state of OpenGov behind the scenes, which is normal.

At the moment there are very few teams that going deep with extensive research and get a clear picture of the whole situation. OG Tracker is one of them as it tracks, reports and stores this data, looking for answers on missing information and communicate with proposers.
This is an attempt to improve the overall experience for all parties involved, targeting long-term sustainability, based on our experience throughout these months and the extensive talks with other teams or ecosystem agents.

We are more than happy to explore any other alternative approaches, like Cayman, and we are always seeking to collaborate with other members or join forces towards the same goal moving forwards.

Many thanks for taking the time to express your thoughts on the topic! Constructive feedback is totally appreciated!

5

Unfortunately bad actors will always be around. Even if a full prevention is challenging we strongly believe that by joining forces we can minimize or even completely eliminate these incidents.

While our suggestions might tackle the problem above to some extend, the main goal from these implementations is to set the standard, form the best practices and improve the overall experience for proposers and all parties involved.

In addition, if we had to choose one track that would be the Medium Spender due to the high frequency of submitted proposals there.

Totally agree on the simple and straightforward format part. Its always a priority to keep it as simple as possible especially in a complex environment like OpenGov. Any help is more than welcome and much appreciated!

Many thanks for your input and your support towards these efforts!

6

Using some bureaucracy to deal with this problem is certainly a possibility.

However, I would love if we could also come up with something more web3, like, for example, reputation on chain.

If you are a new team, you start small, and go gaining reputation, as reputation grows so does the project size. And then we minimize the risk.

As somebody also mentioned, there will always be bad actors. There may also be honest failures (which are part of the innovation process), but by matching size to on-chain reputation we will certainly minimize risk, or the overall cost of risk to our community.

For example, It would be great if we could record on chain delivery reports too, and our community could also express/vote for those in a way that the quality of the work could be recorded and used to build up reputation.

1 Like
7

I agree that this is important, but it is contingent on the will of tokenholders. I know that many voters share this view, and I hope it continues to gain favor.

8

We could also use UI, such as displaying reputation together with the proposal, and system warnings. something like:

“this proposal is 4.2 times bigger than the average size of proposals for teams with this reputation”.

I mean, token-holders are obviously free to vote what they want. Perhaps is a new team made of well known members, etc. But the system can point key metrics to the voter.

1 Like