[Phase 1] HIP-?: Include submission details on Phase 3 HIPs

DAO
#1 
HIP: ??
title: HIPs that require governor submission must include details
author: @juanu 
status: Phase 1
created: 2022-05-31

Simple Summary

When reaching a Phase 3 HIP that reaches consensus, and requires an update to the gorvernor, the specificc details for submission must be included on the Implementation section of the Phase 3 HIP

Abstract

There has been a long discussion about HIP submission guidelines. This HIP is one more step to make them more clear.
When a Phase 3 HIP reaches consensus, and requires an update to the governor contract, the actual last step of sending the transaction with the submission, generates some friction. This is because not every HIP author knows what it’s required to make the submission, or, if they do, they don’t know how or where to do it.
By implementing this HIP as part of the submission frameworks, a submitter MUST include the details of the actual transaction to be submited to the governor contract, including any extra information such as the updated Proof of Humanity Policy document (if it applies).

As a bonus, having this definition mandatory on the HIP, it allows the community members to validate that proposed submission is correct. This validation might not be achievable by ALL members since it requires some technical knowledge, but it can be learned.

Implementation

In order to make Phase 3 HIPs implementation more clear to the community and easy to validate, all Phase 3 HIPs, that require a submission to the governor and that were created after this HIP acceptance, must include:

  1. The details of the transaction to execute to the Governor. This can be done by creating the transaction without submitting it, using the Kleros submission tool for proof of humanity. To do this, some technical knowledge is required in order to understand what it takes to create the transaction. If the HIP proposer doesn’t know how to achieve it, they should ask for help on the community. [NOTE: THERE IS A GUIDE THAT WAS WRITTEN ON THE TELEGRAM CHAT BY @fnanni on how to do this**. If this HIP reaches interest to be moved to Phase 2, I, @juanu, pledge to edit and turn it into a simple step by step, explaining each step involved.]

  2. If an update to the Proof of Humanity registry policy is needed, the updated document should be included on the Phase 3 proposal. This should be included as an IPFS url, in order to rely on a verifiable file URL, rather than a centralized storage service, which can be compromised. If teh submitter doesn’t know how to upload a file to IPFS, they should ask for help to the community.

  3. In the case where the Phase 3 HIP requires an update to the Registry Policy Document, the source of truth of what should be on the new Registry policy, will be taken as the included document. This will also be true even if the HIP has differences in the HIP text vs the updated document text. In the end, what is what the updated Registry Policy states. This is only true as long as the HIP is congruent with the proposed update. It is recommended to not include registry policy text on the HIP, but on the final document to avoid interpretation issues.

8 Likes
[Phase 1] HIP-52: Change POH Governance
#2

I belive this Is a a step forward to have an order in the reglamentation of the hips.
I think Is necesary to do this, and I think that the HIP maybe can content the manual of the steps to configurate the IPFS node and also the steps to learn how to do correctly the implementation part of the HIPs.

1 Like
#3

Thank you! Yes, I have pledged to build the guide to do it. I am waiting for HIP-42 to finish to start generating some buzz around this and get the community interested

2 Likes
#4

There is a risk that HIPs become hostage of tech-savvy gatekeepers and this would be a huge barrier to members participation in the Democratic Process (true DAO-ness). Not mandatory, but it would be nice to have mechanisms that prevent this in some sort of way (but may be not codified in the HIP itself).

One thing that can be useful to make submissions transparent, is to add a way that changes in the primary document PDF can be tracked. At the moment, the Primary Document is a PDF which I’m not sure where the source file comes from or how it was authored into PDF format. A solution would be to have the text for the primary document in a markdown format in a public repo and any changes made could be tracked there. If future HIPs change submission rules, a new PDF files can be very easily converted into PDF (for example, via pandoc).

2 Likes
#5

I belive that would still be an issue without this HIP, since you still require tech saavy users to execute them. The HIP tries to make life easier for those users that end up executing the transactions on the governor.
Also, it could attract more people to learn how to do it. Since its mandatory, if they want to avoid depending on someone else, they can make an effort on learning.

Bothg of this can be solved by generating a good guide that explains.
I pledged to make one, but after that it could even be improved.
As you said, this guide doesnt have to be part of the HIP. The HIP only looks to make Phase 3 more robust and avoid the risk of challenge as much as possible.

I’m onboard with open sourcing the original doc.
In the end the PDF is just the final “compiled” version, so any source format should be fine.

2 Likes
#6

I have added points 3 to the proposal.
please, leave any feedback

1 Like
#7

If +2 HIPs that intend to change the policy are voted simultaneously (like 40, 41, 42), the final policy will be a combination of all the HIPs changes. Therefore, it’s not possible to know beforehand what the policy sent to the governor will be. I’m not sure what’s the best way to deal with this.

#8

Thats actually a great point.

This HIP could define a framework for that such as:

If more than one HIP change the policy rules simultaneously, the last HIp should contains the final submission details, including the submission details for the HIPs it aims to apply to.

Do you think that would suffice?

#9

Ok that would also present an issue, let me see if I can explain it:
Lets say 3 phase-3 polls (A, B, C) that are ready to be launched for a binding poll in snapshot.Each one lasts 7 days. A is sent to snapshot Monday, B wednesday, C friday.
There could be no way to concatenate or append the last approved poll with the previous ones without knowing the result beforehand.
Solutions could be (brainstorming here):

  • Have fixed slots or periods for proposals and only send one snapshot poll per slot (slow, not recommended)
  • Have fixed slots or periods and have the authors commit to have a submission that could include their details in case it passes, within that period.
  • Create an tier of proposals in terms of emergency and let the ones that the authors that are ok to wait to be lumped together in a short meta-HIP that only specifies the submission details of this lump of proposals.
  • If is an update of the metaevidence have the policy converted to a text-only format like md and work with the specific lines that each HIP is trying to change. Do not allow to be sent HIPs that are trying to change the same lines.
  • After passing a binding vote update each policy one at a time at the Governor. (also not ideal because two hips could be changing the same paragraph).
#10

This is still an Issue without this proposal, since Proposal B might require Proposal A to be accepted, but its being voted on while the results of Proposal A is not known.
in that Case maybe a separate HIP is required to deal with those cases?

#11

You got a point. We would need to have one binding poll at a time, it seems.

#12

There are 2 ideas that come to mind to solve this issue:

  1. we could make another HIP that restricts from running multiple Phase-3 at the same time, when one is dependent on the other.

  2. Create a framework for “linked” HIPs that can run simultaneously, but restrict them from being valid (even after passing Phase 3), until all of the linked HIPs pass Phase 3. If one doesn’t pass, the “bulk” is automatically invalidated.

Would love feedback on either of this 2 (or other alternatives)

#13

Hi!
(1) is the easy way to handle this, but maybe is not efficient. Every “session” with submissions is a on-chain tx with deposit and gas cost, am I right? It’s a shame if something like the hip 40/41/42 happens and we make 3 different sessions. Knowing that KlerosGovernor allow this, I think we should take it.

In the other hand, (2) has some bureaucracy which I don’t like, but seems the way and we can discuss a little further. Following the A, B, C HIPs example, the A-HIP authors should worry just for defining the submission’s details, as this current hip suggest. If another author put a hip in phase 3 two days after, and it don’t pass, invalidate HIP A is a little unfair. So we should transfer that complexity to subsequent HIP’s authors (in the example, B and C).

Another thought is that subsequent hips with “merge conflicts” are unlikely. For that to happen, they has to be contradictory and one of both should not pass. With the policy in MD format it’s easy to see, i don’t know if there are other changes with possible collision.