Introduce a new BSIP threshold
- Dominant language
- No language data
- Stars
- 59
- Forks
- 86
- PR merge metrics
- No merged PRs in 30d
Description
The current mechanisms to consider a BSIP as approved is as follows:
1. there is only one worker proposal. The BSIP is considered approved once the worker proposal becomes active, as in receive part of the daily BTS payout
2. there is a YES and a NO worker proposal. The BSIP is considered active when YES has more votes than NO. Now there is already debate here if the YES worker proposal ALSO needs to be active, as in receive part of the daily BTS payout. Either or, this should be defined in the corresponding BSIP
The committee is apparently seeking a third option to consider a BSIP as approved. A new threshold has been created `1.14.158 | threshold-bsip` that has the intent to be the new barrier for when a BSIP is considered active. To make it clear, the above a) and b) would then be
1. there is only one worker proposal. The BSIP is considered approved once the worker proposal has more votes than `1.14.158 | threshold-bsip`.
2. there is a YES and a NO worker proposal. The BSIP is considered active when YES has more votes than NO, and YES has more votes than `1.14.158 | threshold-bsip`
Depending on how many votes `1.14.158` has the BSIP worker proposal may never receive part of the daily BTS payout and still be considered approved.
This issue is to discuss how to transition from the previous model to the new `1.14.158 | threshold-bsip`. Discussion has arisen [here](https://github.com/bitshares/bsips/pull/265#issuecomment-595650519) which triggered me to open this issue. These new guidelines may be part of [revision of BSIP-01](https://github.com/bitshares/bsips/issues/250).
In my opinion it is not enough that the committee simply creates the worker. This needs approval in the old way (i.e. a BSIP must be written that then is approved by becoming active, as in receives part of the daily BTS payout).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading this issue, the discussion in BSIPs pull request #265, and the proposed revision of BSIP-01 in issue #250. Identify the unresolved transition rules for threshold-bsip and document the agreed policy in the relevant BSIP once the committee reaches a decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- blockchain
- Domain
- blockchain, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100