BitShares Forum
Main => General Discussion => Topic started by: pc on August 23, 2017, 03:41:05 pm
-
Do we need shareholder approval for these bugfixes?
Can we decide on that question? Not just specifically for the PRs in the OP, but generally.
-
IMHO No
Shareholders should vote for trusted witnesses who, in the end, are expected to make that kind of call on behalf and in the best interest of the same shareholders
-
IMHO No
Shareholders should vote for trusted witnesses who, in the end, are expected to make that kind of call on behalf and in the best interest of the same shareholders
I agree. In general s/h don't have the expertise to evaluate bug fixes. IMO it would be counterproductive and slow progress.
This is the type of issue (approve / disapprove fix) we should have a direct voting mechanism for. What I'm thinking of is the DASH masternode governance model. If BitShares had a website that witness node operators could authenticate on and vote yea or nea on things, such decisions could be made before going thru the trouble of creating and testing a bug fix that won't be approved by witnesses.
Also, such a website would help to keep witnesses informed about upcoming changes, and provide shareholders with more info on which witnesses are active and how they vote (or don't).
-
IMHO No
Shareholders should vote for trusted witnesses who, in the end, are expected to make that kind of call on behalf and in the best interest of the same shareholders
Agreed
-
features that require a hard fork or general rule changes - yes.
bugfixes - no
-
features that require a hard fork or general rule changes - yes.
bugfixes - no
Some bugfixes may require a hardfork however this is a good guideline. The more visibility into any hardfork upgrades is good for the whole community and those who are building businesses around the chain.
-
Community can Always Propose changes as needed and witnesses can choose accept or not. They are voted in by community anyway.
-
Thanks guys. Looks like there is consensus.
@bitcrab @xeroc - you're the biggest proxies, what's your position?
-
I think there should be a decided, known place where these bug fixes / hard forks are announced, with a "please speak now or forever hold your peace" kind of setup. If there is a big controversy about something, then we can take it to stakeholder vote. If not, then the update can be done without it.
Ideally, this should be done on-chain. This is how I imagine it:
1. A committee member creates a "hard fork proposal", which includes a brief description of the problem to be fixed or feature to be implemented.
2. At this stage, other committee members are assumed to a "yes" vote and must veto to "no" proactively. Otherwise, the feature is green-lighted to be developed after a certain amount of time, perhaps 15 days. If shareholders don't like the proposal and there are not enough vetos, then they can vote in committee members that agree with them.
3. After the feature/bugfix is developed and a release candidate is created, a committee member creates a "hard fork commitment proposal" which references the previous "hard fork proposal", and also includes the release hash and block number for the fork.
4. Witnesses commit to this, and when a supermajority of witnesses do, then the hard fork will activate at the block number.
-
I think there should be a decided, known placewhere these bug fixes / hard forks are announced, with a "please speak now or forever hold your peace" kind of setup. If there is a big controversy about something, then we can take it to stakeholder vote. If not, then the update can be done without it.
Ideally, this should be done on-chain. This is how I imagine it:
1. A committee member creates a "hard fork proposal", which includes a brief description of the problem to be fixed or feature to be implemented.
2. At this stage, other committee members are assumed to a "yes" vote and must veto to "no" proactively. Otherwise, the feature is green-lighted to be developed after a certain amount of time, perhaps 15 days. If shareholders don't like the proposal and there are not enough vetos, then they can vote in committee members that agree with them.
3. After the feature/bugfix is developed and a release candidate is created, a committee member creates a "hard fork commitment proposal" which references the previous "hard fork proposal", and also includes the release hash and block number for the fork.
4. Witnesses commit to this, and when a supermajority of witnesses do, then the hard fork will activate at the block number.
that must be the blockchain itself
-
that must be the blockchain itself
While I ultimately agree, pragmatically it makes sense to not halt everything else to implement an on-chain solution. Besides, how would we implement this on-chain without a hard fork?
-
We have a mechanism in place, in the form of worker proposals.
But the overhead of creating worker proposals is rather high and not really appropriate for stuff like small bugfixes.
-
We have a mechanism in place, in the form of worker proposals.
But the overhead of creating worker proposals is rather high and not really appropriate for stuff like small bugfixes.
I read this as "Thanks for the suggestion, but we already have a mechanism, and that mechanism isn't suited for this."
Do you have any direct criticism of the method I outlined?
-
Your steps 1+2 are basically the same as the worker proposal mechanism, but reduced to committee members only.
I don't see how reducing the scope would make that any better. It only creates more work for the committee. Keep in mind that committee members receive no compensation for their work, so we should not place any unneccessary load on them.
Also, my original question refers to *small* bugfixes. It does not make sense to create an approval process that takes an order of magnitude more work than the actual issue to be solved. That's why I see the proposal/vote mechanism as inappropriate.
Step 3 is something entirely new which we've never had before. In my understanding, once a change has been approved the actual execution is put into the hands of developers and witnesses.
Step 4, i. e. witness approval, seems to have the biggest support in this thread. Witnesses are responsible for keeping the blockchain alive, so ultimately they decide which code to run.
-
Your steps 1+2 are basically the same as the worker proposal mechanism, but reduced to committee members only.
I don't see how reducing the scope would make that any better. It only creates more work for the committee. Keep in mind that committee members receive no compensation for their work, so we should not place any unneccessary load on them.
Also, my original question refers to *small* bugfixes. It does not make sense to create an approval process that takes an order of magnitude more work than the actual issue to be solved. That's why I see the proposal/vote mechanism as inappropriate.
Step 3 is something entirely new which we've never had before. In my understanding, once a change has been approved the actual execution is put into the hands of developers and witnesses.
Step 4, i. e. witness approval, seems to have the biggest support in this thread. Witnesses are responsible for keeping the blockchain alive, so ultimately they decide which code to run.
This!