[bisq-network/proposals] Separate compensation request submission and voting periods (#40)

Manfred Karrer notifications at github.com
Wed Oct 10 15:55:22 UTC 2018


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 bring different valuation aspects (like @joachimneumann did in his last proposal).
2. After the proposal time is over, there should be still 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.

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 a longer as it was initially planned for re-org protection (10 blocks). I would suggest 300 blocks here (about 2 day).

The first review phase we can support in a soft form:
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. 

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.  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/40#issuecomment-428628078
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20181010/d7448755/attachment-0001.html>


More information about the bisq-github mailing list