Separate compensation request submission and voting periods

[sqrrm]

Background

During the last few voting rounds I have found that some requests for compensation might have needed more time for review and discussion.

Problem

In general, out of self interest to get a reasonable proposal accepted it's good to post it early if there is any reason to believe it might be contentious. Additional discussion around it could help to make voters understand the reason and perhaps give some time to modify the request. The reverse is true for an unreasonable proposal (eg, asking for compensation for work not done, changing parameters to weaken the DAO). By posting it late and giving no time for review and discussion voters might choose to abstain and with only a few yes votes the proposal would get passed.

It's expected that contributors understand what they vote on and should thus reject unreasonable proposals. However, with the idea of delegated voting and that the default is to abstain when not sure that opens up for passing unreasonable proposals.

Proposal

I propose to prolong the break (BREAK1) between proposal (PROPOSAL) and voting (BLIND_VOTE) phases to have time for reasonable review and discussion. Two or three days rather than just a few blocks would give sufficient time for contributors to voice their opinion on any unreasonable proposals.

Potential Issues

By adding more time between proposal and vote resolution there is a potentially longer time between work and reward.

[ManfredKarrer]

Agree!

[ManfredKarrer]

@ripcurlx @flix1 @cbeams @alexej996 @HarryMacfinned - Can you upvote/downvote so we can close the proposal?

[ghost]

This proposal seems at first to concern compensations requests.
And I agree that submitting 1/ lately 2/ for unusual amounts, is not a very good way to proceed. (I myself did it, and I apologize for that).
However, I'm not sure that creating a hard and general rule to avoid that is the best solution.
One drawback I see, at least for compensation requests, is that requesters will stay longer in the uncertainty zone ... which I consider as certainly bad. The actual model is already quite unusual ... and we would add even more over it ... ouch.

For my part, I would prefer that we try to work with incentives, well written in the documentation.

In september, @ManfredKarrer asked us to fill our compensation requests earlier this month.
imo, this is a better way to proceed. I find it's a good idea, and I'll try to better organize myself in order to proceed this way.
Ok for extending the submitting period. (Which extends the discussion period).
Not ok for extending the voting period.

[cbeams]

I've given this a 👍. Specifically, I am for the concrete proposal which came up elsewhere to separate the submission period from the voting period by one week.

My understanding is that the submission period would continue to take place on the last 3 days of the month, and that the voting period would now take place on the 7th–10th of the following month. I suggest we call the week in between the "review period". No new submissions would be allowed during the review period, only modifications based on feedback received during review.

So we would have 3 days of submission followed by 7 days of review followed by 3 days of voting.

Strictly speaking, contributors could submit as early in the month as they like, i.e. submission does not need to happen during the 3-day period, but we would keep the 3-day period in place for the purpose of announcements, calendar reminders, etc.

Does anyone have a different set of specifics than the above in mind?

Also, as an aside, please form the title of proposal issues as a proposal statement. "DAO Proposal Review Period" does not propose anything. It forces the reader to dig through the text to figure out what is actually being proposed. For example "Separate compensation request submission and voting periods with a one-week review period" is a title that clearly states what is being proposed. It may be hard to come up with the perfect title at first, and the title can be revised as the proposal becomes more clear, but please nevertheless endeavor to form titles as a proposal in the first place, thanks.

[joachimneumann]

I agree with this proposal

[sqrrm]

@cbeams Updated the title to actually propose something. The timing is up for discussion. I'm ok with a 7 day review period but I don't see that much benefit to a period longer than say 3 days.

My main concern is to avoid late submissions in bad faith that don't get proper review. If modifications are allowed during the review period that concern is not handled. Someone could add an innocent looking request and change it last minute. For submissions in good faith it makes more sense to submit in good time before cutoff for submissions and only treat the review period as a time to review and decide if -1 is warranted or not.

To those interested how it will work once the DAO is activated in software. The process will be, with phase as defined in code in parenthesis:

1. (Any phase) Create github issue with details of compensation request (and perhaps ask for review if it's likely to be contentious).
2. (Any phase) Wait for comments and feedback if needed.
3. (PROPOSAL) Create compensation request Proposal inside bisq app referring the github issue. This is basically the work that @ripcurlx is now doing for us in the spread sheet. During the PROPOSAL phase the Proposal can be changed.
4. (BREAK1) Review period, this is what I suggest should be 3 days. Proposals can no longer be created or modified but discussion can occur in the github issue. This phase doesn't exist in our current spread sheet way of doing the DAO.
5. (BLIND_VOTE) Voting, 3 days. Refer to the github issue for discussions and details about each compensation request, just like we do now.
6. (BREAK2) (VOTE_REVEAL) (BREAK3) (RESULT) (BREAK4) For completeness, the phases that handle the vote resolution. These phases don't need much time.

[ManfredKarrer]

I agree to @cbeams suggestion. Maybe 7 days for review is not required and 3 days is enough? Then all 3 phases would be 3 days -easier to remember as well ;-). But no strong opinion here, 7 days is fine for me as well.

[cbeams]

I'm fine with a 3-day review period.

[sqrrm]

@ManfredKarrer @cbeams To clarify, do you think proposals should be possible to modify during this review period? I would be against that as I think it adds no value to the current system.

[cbeams]

I might be confused, @sqrrm. Compensation requests are proposals, and the idea of having a review period is to be able to modify them accordingly based on review feedback, so it seems that by definition proposals must be modifiable during that period.

Do you mean to ask here about non-compensation request proposals? If so, I think I agree that they should not be modifiable once submitted. Would be helpful to think it through with a concrete example, though. I'm not familiar enough with the way proposals in the DAO software work to be sure about anything, but in principle it seems like non-compensation proposals should just be an up or down vote, and that any review should have happened before being submitted. I'm assuming here that we'd still have the proposals GitHub repository for that review? Or maybe not. Again, I'm not sure what the thinking on this has been so far, or what the actual implementation expects.

[sqrrm]

Sorry to mix the terms @cbeams, I hadn't made a real distinction in my mind if this should be for all proposals or only compensation requests (which are a subset of proposals). I think it should be the same for all proposals though, easier to code (fewer bugs) and they all have the same issue of review comments not pertaining to what's being voted on.

I do indeed want to lock any proposal from being modified for three days to give the community time to comment on it. The fact that it can't be modified means all the comments during the review period are relevant for the proposal being voted on and they can be used to base a judgement on how to vote.

If the proposal could be changed during the review period there could be good discussion and approval from the community. At the last moment the proposal could however be changed and once it's time for vote there would be no comment and review of the actual proposal. I see this as a possible way to sneak through malicious proposals.

Example in case of modifiable proposals during review period

I create a compensation request for 2000 BSQ. After discussion during the review period it's concluded that I should ask for 3000 BSQ and I update my request. At the last moment I update it again to request 30000 BSQ.

As a voter I would read the comments and conclude that there is nothing contentious about this proposal. The only way to actually figure out that I want to vote -1 is to go through all the comments, read the details and conclude that the value should be 3000 and not 30000. Even the people that commented on this request need to read through in detail rather than relying on the decision how to vote that was taken during the review period.

Words

The word review might be a bad name for this, and in the code the phase is called BREAK1. I also want there to be proper review with a chance to adapt the proposals to something that has rough consensus before actually publishing the proposal through the bisq software. Maybe we should refer to the last three days of the proposal phase as the review period and just refer to BREAK1 for the time when a proposal can neither be created/modified nor voted on.

[cbeams]

IIRC, what led to the creation of this proposal to introduce an explicit review period is that we've had some compensation requests where feedback was given to adjust the requested amount of BSQ, and that people felt that there wasn't enough time to discuss that feedback and make those changes prior to the voting period beginning. Especially in the case of a compensation request that's submitted near the end of the 3-day period, there's no opportunity to read and provide such feedback prior to the voting period. So I've seen the new (now 3-day) review period as an opportunity for everyone to have a look at the compensation requests out there, provide feedback saying, e.g. "hey, this requested amount is way too high and I'm going to vote it down, please reduce the amount if you want my vote". Obviously this implies that proposals must be modifiable during that period. If this is undesirable or infeasible to implement (e.g. for the reasons you've provided above, @sqrrm), then we could compromise with a review period with immutable proposals, meaning that the only option compensation request submitters will have to respond to negative feedback is to re-submit their request the next month. That seems non-ideal and unintuitive, and IMO diminishes the value of / need for the review period in the first place.

[ManfredKarrer]

I think there are 2 types of review phases:

1. The requester awaits feedback and is able to change the proposal. Best would be in cases of uncertain amounts and/or bigger projects to start an early discussion in which range the amount should be and discuss different valuation aspects (like @joachimneumann did in his last proposal).

Note: In the BSQ DAO the proposal cannot be edited only removed and newly added.

2. After the proposal time is over, there should be still enough time so that other contributors can add comments, give feedback, discuss.... This will not help the proposal maker to change it as it is too late but it will help other voters to find a decision. There might be one or 2 contributors who have more insight into the topic of the request and here they can add information or their opinion. Ideally that happens already in the first review phase, so the contributor has time to adjust. Here if the discussion leads to much disagreement, the proposal might get rejected and need to be re-submitted next month.

Note: Once a blind vote is submitted it can not be invalidated by voting again. Technically we could support that but we did not support that in the UI to keep things easy.

I consider the first review as the important one but here we have no technical means to enforce or clearly define it. The second one we could easily implement with the BREAK1 phase between the proposal phase and the blind vote phase. I think it is good to make that break longer as it was initially planned for re-org protection (10 blocks). I would suggest 150 or 300 blocks here (about 1 or 2 days).

The first review phase we can support in non-enforcing way:
Lets keep the last 3 days of the proposal phase reserved for review. If the user makes a new proposal here he gets displayed a popup explaining that it is recommended to make proposals early and by submitting a "late proposal" he risks that reviewers will suggest to re-apply it for next months if they don't find enough time to review it. I think that does enough education to make sure that most contributors will follow the guideline to make the proposals before that "late" phase.

Note:
Please keep in mind that as the time will be based on blocks we have no way to sync with calendar months! i think it might be a good idea to keep blocks to even numbers like 150 block for 1 day instead of 144 blocks to make it easier to remember phase changes. The UI will show of course those events and also the estimated date based on the average 10 min. block interval. If we start the genesis block at an even number as well we might stick to a certain grid.

Periods can be changed by voting so that will not be a hard restriction anyway. I will make a new proposal to suggest the lengths of those periods but it will be roughly based on a 1 months cycle.

[ManfredKarrer]

Here is how the UI looks like for displaying the phases and cycles. Any suggestions for improvements welcome!

[sqrrm]

I think @ManfredKarrer has explained quite clearly what I wanted to say, thanks a lot. It's sometimes hard to get out of the bubble when you're too focused and I guess I have had the DAO on my mind for a long while most of you haven't.

I still think a BREAK1 of 450 blocks would be appropriate but 300 is ok with me.

Having a customary 3 day review phase before the last chance to submit the request is exactly what I would like.

[ManfredKarrer]

@sqrrm Do you see that proposal as resolved? As the break will be increased (we can discuss actual duration in the other proposal for the default values of DAO parameters) anyway I don't see more required action here.

[sqrrm]

Yes, I consider this proposal resolved.

At this point, since there were no more comments after your clarification I think we can say this is resolved and the details will be worked out in the DAO parameter proposal #46