How to make payroll without multiple delegates per developer

[zerosum]

I am sorry, but this kind of legalistic penny pinching will kill BTS and hurt morale.   
Incentives are aligned

Sure, "incentives are aligned" 

I will be as honest as possible (as always). I was virtually searching for the final straw, to divest at least 1/3 from my favorite project...

- 15 Mil BTS and 100K annual pay for the marketing guy that did nothing...The incentives are aligned. 


- 500-700 K USD for the marketing guy, cause he is 'VOTE' and the next better thing than BTS... (but do not worry he is not getting 2K/mo. delegate, so he is OK).

- 3Mil BTS bonus for Stan, for posting obscure and/or condescending comments on the forum.

- 3Mil BTS bonus for Agent86 for almost finishing an article in 45 days; [striving for the most expensive piece of literature I guess]


- as far as developers go.... well drltc will need 4 delegates voted in to get a fair compensation, after Feb15th. That of course was needed for no other reason but to  get all of the above 'greater good' achieved!



If this is not example of 'The incentives are aligned', I really do not know what is! 

[Rune]

I support core developers making six figures, and I support a single person running several 100% delegates whenever it is required. (or runs their own delegate and gets others to run support delegates)

But strategically I think right now a bad time to begin negotiating salary. It's a debate that is most definitely required in the near future, but can it wait until we have a working full node, a working lightweight client, and a working mobile wallet?

[sumantso]

I thought that having business people and block signers overlap would result in a lot of people like me spending a ton of time dealing with delegate IT issues, feeds, etc.  Which has certainly turned out to be the case.

It also increases the barrier to entry, especially for non-technical people.

It also complicates the judgement process - if the block production is erratic but the delegate is working well, do you fire him? He may be asked to get a different block producer, but thats just asking to spend time doing stuff he may not be proficient in.

[theoretical]

The centralization issue can be easily avoided if the block producers and employees are separated. I have given the proposals several times elsewhere.

I proposed a concept along these lines back when dilution was first being considered.

I think the main reason my proposal was not implemented was that it was considered desirable to make as little change as possible to the code.

As a secondary effect, it produces an incentive for delegates to have high uptime (downtime is a lot more expensive for 100% delegates than 3% delegates), and get some connections to the community.

I thought that having business people and block signers overlap would result in a lot of people like me spending a ton of time dealing with delegate IT issues, feeds, etc.  Which has certainly turned out to be the case.

[sumantso]

This is the main issue.  Some discussion in the other thread led me to believe that multiple 100% delegate registration for developers was being discouraged due to increased centralization.  This thread started out as a technical proposal for mechanics that would achieve the same economic outcome for developers as multiple delegate registration, without the drawback of increased centralization.

The centralization issue can be easily avoided if the block producers and employees are separated. I have given the proposals several times elsewhere.

EDIT: Not the original proposal, but a quick later ones https://bitsharestalk.org/index.php?topic=12730.msg167577#msg167577

I have your back, I don't intend to let any developer go underpaid.

 

[lovejoy]

Yes, Let's go all in...

On our developers, and creatives, and strategists, and... everyone who has the courage to go all in.

This whole endeavor may well indeed be won by the balance of those willing to go all in.

Without some pretty core folks being all in none of this would even be happening right now.

Let's take care of those who are advancing this vision --- end of story.

If you're willing to relocate and give your all to this game changing experiment in truth, I have no problem backing you 100%.
I support making sure your financial needs are taken care of so you can focus on what's important.

I applaud your example, you've been plenty transparent.

[Gentso1]

Thanks for taking the time to explain your pay.

I would support you running another delegate.

[roadscape]

If it means keeping a kickass developer, who cares about a temporary sag in decentralization.
Compromises must be made.. we have all the tools we need, just need to be creative with them.

[arhag]

I don't like creating complexity when such simple work arounds are in place.

You are trading off code complexity for social complexity. I prefer code complexity.

Code complexity like you suggested creates new social complexities.

It changes the social complexity, but it IMHO simplifies it compared to your work around.

Now we need to deal with the social complexity of separating the blame from a helper delegate doing a good job from the developer it supports doing a bad job or vice versa. Managing the total biweekly pay of a developer/worker is much more complicated with a system of multiple helper delegates paying their salary than simply adjusting a single BitUSD number in the blockchain through BTS stakeholder consensus. We require the workers to create the accounting proof that they burned the excess profits above their negotiated salary and we require stakeholders to monitor these proofs and vote them out if they refuse to supply them rather than just letting the blockchain automate all this work for us.

[bytemaster]

It sounds like you got duped...I am quite surprised that in an industry where everyone exclaims to not invest more than you can lose, that you would be asked *or you would commit to flip upside down your life to work for a not guaranteed wage and with possible total loss of all earnings if BTS price dropped.

From what I understood, I was to be paid in US dollars, discounted by the USD value of my delegate income.  At the time, I believed I3 still had a ton of AGS funds and was only employing ~10 people.  It didn't seem risky because the plan seemed to be that I3 would use AGS funds to indemnify me against exchange rate risks, problems with the chain itself, or delegate IT screwups.

To be fair to bytemaster, it was suggested around this time that people begin to run inflationary delegates to preserve AGS funds (at first on DNS chain, after the merger on main chain), and that this would be the long-term vision:  People paid by inflation rather than AGS.

However, it was not at all clear -- or at any rate, it was not clear to me -- that compensation arrangements were going to change at the end of the year.

It's still been less than 24 hours since I first saw the post detailing the new compensation arrangements, and I am not going to make any big life decisions for at least a week while I consider the implications.

I have your back, I don't intend to let any developer go underpaid.   

[bytemaster]

I don't like creating complexity when such simple work arounds are in place.

You are trading off code complexity for social complexity. I prefer code complexity.

Code complexity like you suggested creates new social complexities.   

[theoretical]

It sounds like you got duped...I am quite surprised that in an industry where everyone exclaims to not invest more than you can lose, that you would be asked *or you would commit to flip upside down your life to work for a not guaranteed wage and with possible total loss of all earnings if BTS price dropped.

From what I understood, I was to be paid in US dollars, discounted by the USD value of my delegate income.  At the time, I believed I3 still had a ton of AGS funds and was only employing ~10 people.  It didn't seem risky because the plan seemed to be that I3 would use AGS funds to indemnify me against exchange rate risks, problems with the chain itself, or delegate IT screwups.

To be fair to bytemaster, it was suggested around this time that people begin to run inflationary delegates to preserve AGS funds (at first on DNS chain, after the merger on main chain), and that this would be the long-term vision:  People paid by inflation rather than AGS.

However, it was not at all clear -- or at any rate, it was not clear to me -- that compensation arrangements were going to change at the end of the year.

It's still been less than 24 hours since I first saw the post detailing the new compensation arrangements, and I am not going to make any big life decisions for at least a week while I consider the implications.

[arhag]

I don't like creating complexity when such simple work arounds are in place.

You are trading off code complexity for social complexity. I prefer code complexity.

[bytemaster]

Multiple delegates held by one person taxing the blockchain will definitely kill this.

Which is why I proposed the system in OP where bytemaster decides who deserves what, issues IOU's, then the shareholders vote in delegates held by multiple different owners to redeem the IOU's by buying and burning them.

The real solution would be to have the blockchain scale delegate income within the supply envelope, i.e. if max inflation is 5050 BTS / round, and you have 11 delegates at 100% and 90 delegates at 3%, then you just figure 11 * 100 + 90 * 3 = 1100 + 270 = 1370, make each percentage point worth 5050 / 1370 so the 100% delegates get 368.61 BTS and the 3% delegates get 11.05 BTS, the total is 11 * 368.61 + 90 * 11.05 = 5049.21.  Now the "%" has become kind of a misnomer and we just have arbitrary weights.

You should be able to have the delegate specify maximum as well as a weight, then you pour the round's supply allocation into each delegate proportional to their weight, removing a delegate whenever its max pay is reached.  You should be able to specify the maximum as a BitAsset, so you can specify e.g. "I want $200 / round" and the blockchain will give you $200 worth of BTS when your slot comes up (or even better, front-run the market and buy you BitUSD automatically).

All of these features would be hardforks and need lots of testing, the main selling point of OP is it captures 80% of the value and can be implemented by a simple script on today's blockchain, no complicated, potentially exploitable exchange rate discovery / market maker bot logic or hardfork required.

There are all kinds of complex formulas that can be adopted, but you can have the same level of decentralization by simply nominating a few "helper delegates" that simply take 3% and give you 97%.   I don't like creating complexity when such simple work arounds are in place.   Especially if the work arounds have the benefit of making it easier to "fire" and "redirect" the pay of an underperforming developer.   IE: if a developer wants $10K per month and thus needs 4 delegate slots that are managed by 4 different people then those 4 people collectively hold the delegate accountable by reviewing their work.    The more pay the more accountability.   Far better than having a single delegate with no peers to keep them accountable.   This is why I very much like the "buddy system" for delegates.   One person receives the money from the blockchain and then pays the real developer.   

[arhag]

I'm just going to leave this here: https://bitsharestalk.org/index.php?topic=10969.msg147860#msg147860

Not my ideal solution, but a quick and easy one to avoid needing multiple delegates per developer and avoid requiring the developers to provide accurate accounting to prove they are burning the excess wealth they realize through BTS gains above their negotiated rate.