BitShares Forum

Main => General Discussion => Topic started by: theoretical on January 02, 2015, 05:18:04 pm

Title: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 05:18:04 pm
Stan / bytemaster should publish a budget spreadsheet of how much BitUSD they think is necessary to run core operations for the quarter / year, broken down by TITAN account.

Then, every day a script sends an IOU UIA to each account for each dollar of shortfall between their budget and what they were able to earn directly from the DAC with their delegate(s).

For the paranoid, public information can allow a script to audit that the IOU issuance matches the budget.  The IOU UIA can be issued by a multisig address signed by multiple trusted community members running independent copies of the script.

Then we get one or more new 100% delegate(s) who promise to use their newly created BTS (minus reasonable commission / expenses) to buy BitUSD, then create a buy wall at 1 IOU / BitUSD.  Burning any IOU they obtain (or returning them to the issuer address, I think burning UIA is actually not implemented; see https://github.com/BitShares/bitshares/issues/883 ).

Since the IOU is a UIA, there is no centralization issue simply letting bytemaster inflate as many IOU shares as he wants to and distribute them as he sees fit.  If the shareholders agree that bytemaster's budget is fair and transparent, then they will elect 100% delegates to give the IOU a market valuation backed by the power of the BTS printing press.  If the shareholders don't like the budget, they can simply kick out the delegates that support this scheme.
Title: Re: How to make payroll without multiple delegates per developer
Post by: bytemaster on January 02, 2015, 05:22:34 pm
I am sorry, but this kind of legalistic penny pinching will kill BTS and hurt morale.   

Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

I am very much against the idea of "selling your time" or "buying time".   If these guys are only working for a paycheck then we would get crap work out of them.   If they are working for more than a paycheck then we will get far more value out of them.   

Lets not remove incentive for efficiency.  Lets not begrudge someone profits earned as a result of taking great risk.
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 05:38:04 pm
Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

I think I had at most ~100K genesis block BTS.  I believed in the product so I shorted the hell out of USD -- but that turned out to be almost exactly when the exchange rate was at its peak.  I got margin called when I was in the process of moving to Virginia -- something you wanted me to do -- and didn't have time to check the markets every day.

I had to ask you for AGS funds just to get enough BTS to register my 100% delegate.

I'll have to consume a substantial portion of my 1M BTS bonus to eat over the next couple months.

If I had a guarantee that I'd be able to run a one hundred percent delegate indefinitely, then I would be able to include the NPV of a 100% delegate's future earnings in my compensation.  However, you've publicly stated that you want developers to burn any delegate income in excess of a market salary, and I assume shareholders will side with you -- I'd have no way to keep them from reneging on any promise they make now not to fire my delegate if I continue to operate at 100% after BTS value goes to the moon.

This argument does not apply to me.
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 05:51:27 pm
I am sorry, but this kind of legalistic penny pinching will kill BTS and hurt morale.   

So wait.  How exactly will paying people a fair salary for their efforts hurt morale?

Nothing is "legalistic" about OP proposal; it does not involve the real world legal system in any way, shape or form.  It's using the BTS tools of decentralized shareholder consensus and user-issued assets to create a market-based solution to the practical problem of compensating developers adequately for their time while maintaining a strong level of decentralization in the delegate slate, without any hardfork.

As for "penny pinching":  You want to refuse to inflate BTS to adequately pay developers, when the DAC has the ability to do so while remaining below the hard-coded supply envelope.  I'd say that is penny pinching.

Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 05:55:55 pm
Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

Assume for the moment I did have a large stake.  Then I have two choices:

(a) Leave and watch my stake grow x% based on the efforts of other developers
(b) Stay and watch my stake grow y% based on the efforts of myself and other developers combined

My effective salary is then (y-x)% times my stake, plus income from any delegate(s) I operate.

I am not sure that (y-x)% is large enough even if my stake is large.
Title: Re: How to make payroll without multiple delegates per developer
Post by: NewMine on January 02, 2015, 05:57:43 pm
Already happening 6 months sooner than I predicted.
Title: Re: How to make payroll without multiple delegates per developer
Post by: bytemaster on January 02, 2015, 05:58:34 pm
I think you are misunderstanding my intentions.  My intentions are for developers to be well compensated and error on the side of over compensation.  The penny pinchers I was referring to are those who are trying to nickel and dime developers and demanding excessive accountability to the point of hindering productivity.

I have no problem with developers keeping 100% pay and not burning surplus if they can convince shareholders to keep them voted in.
I have no problem with developers asking for additional delegate slots if one slot doesn't pay enough.
I have provided complete transparency on the bonus each developer received so that people would not overcompensate developers with a large bonus + paid position. 
I had no problem advancing you the funds to register your paid delegate nor trusting you with a no-strings-attached bonus

I think everyone values you and you will have no problem maintaining a good income while you have support of the community.

I am against any kind of commitment to vote for you.  People have a right to vote how they think is best when they think it.

Title: Re: How to make payroll without multiple delegates per developer
Post by: carpet ride on January 02, 2015, 06:00:28 pm
Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

Assume for the moment I did have a large stake.  Then I have two choices:

(a) Leave and watch my stake grow x% based on the efforts of other developers
(b) Stay and watch my stake grow y% based on the efforts of myself and other developers combined

My effective salary is then (y-x)% times my stake, plus income from any delegate(s) I operate.

I am not sure that (y-x)% is large enough even if my stake is large.

Just trying to understand the dev mindset more.  At the moment, what factors motivate you to work full time on the project and can you quantify how much each factor matters to you?
Title: Re: How to make payroll without multiple delegates per developer
Post by: btswildpig on January 02, 2015, 06:22:30 pm
Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

Assume for the moment I did have a large stake.  Then I have two choices:

(a) Leave and watch my stake grow x% based on the efforts of other developers
(b) Stay and watch my stake grow y% based on the efforts of myself and other developers combined

My effective salary is then (y-x)% times my stake, plus income from any delegate(s) I operate.

I am not sure that (y-x)% is large enough even if my stake is large.

In theory , if your contribution is big enough that somehow you think the project can not go to the moon without you , then (y-x) would be really huge .
Title: Re: How to make payroll without multiple delegates per developer
Post by: fluxer555 on January 02, 2015, 06:31:53 pm
In theory , if your contribution is big enough that somehow you think the project can not go to the moon without you , then (y-x) would be really huge .

Or, you can think of it as possibly:

- Without you: moon
- With you: alpha centauri
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 06:56:26 pm
Just trying to understand the dev mindset more.  At the moment, what factors motivate you to work full time on the project and can you quantify how much each factor matters to you?

What matters most to me is how interesting the problems we have are, how understanding and improving the code requires knowledge of a lot of diverse stuff from low-level computer hackery (one intermittent crash I successfully debugged involved tracing through the Bitshares client one assembly language instruction at a time), cryptographic mathematics, economic theory.  When I took an introductory macroeconomics course (in college years ago), I never imagined a career in software development would one day lead to effectively being an influential advisor to a central bank!

But the problem is that my personal financial situation isn't the greatest, and I feel some pressure to be sure I'm getting paid a fair market salary.

So I guess I would say that being paid is more important, since I'll probably eventually leave if I'm not getting paid enough, even though I love the work.  Does that make sense?
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 07:07:20 pm
I have no problem with developers asking for additional delegate slots if one slot doesn't pay enough.

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.

I have provided complete transparency on the bonus each developer received so that people would not overcompensate developers with a large bonus + paid position. 

Transparency in AGS usage is good, especially as regards the bonus.

I had no problem advancing you the funds to register your paid delegate nor trusting you with a no-strings-attached bonus

I was more using this as an example to illustrate how meager my BTS holdings actually are.

I think everyone values you and you will have no problem maintaining a good income while you have support of the community.

I hope that's the case, I've been active on this forum and trying to be sure my contributions are public.

I am against any kind of commitment to vote for you.  People have a right to vote how they think is best when they think it.

Understandable.  It sets a bad precedent if delegates aren't continuously held accountable.
Title: Re: How to make payroll without multiple delegates per developer
Post by: santaclause102 on January 02, 2015, 07:16:01 pm
Quote
So I guess I would say that being paid is more important, since I'll probably eventually leave if I'm not getting paid enough, even though I love the work.  Does that make sense?
Can you say how much you received in total as pay (BTS, BTC, USD) and how long you have been working full time so things can be put into perspective?
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 07:17:40 pm
I think you are misunderstanding my intentions.  My intentions are for developers to be well compensated and error on the side of over compensation.  The penny pinchers I was referring to are those who are trying to nickel and dime developers and demanding excessive accountability to the point of hindering productivity.

I have provided complete transparency on the bonus each developer received so that people would not overcompensate developers with a large bonus + paid position. 

I want to make my own intentions clear as well.  It's not my intention to soak the community for the year-end bonus from AGS funds and additional 100% delegate(s).  Rather, my problem is that the AGS bonus will only last a couple months at the current exchange rate, and I want to be reasonably sure that I'll still be able to eat when it runs out, even if BTS hasn't gone to the moon by then.

Despite the tax accounting of the bonus, I think the community will be unlikely to support any future delegate proposal which does not treat the bonus as an advance payment of my 2015 funding.  Thus, even though I am not contractually obligated to do so, I currently plan on sticking around for at least 2-3 months with a single delegate regardless of the outcome of this discussion.

Then I plan to start a campaign for 1-2 additional 100% delegate(s) sometime in February or early March.  At that time I will provide a detailed accounting to the community, showing that my bonus has run out and I do in fact need the additional delegate(s) to continue to receive a competitive salary, and also including a detailed list of my recent contributions.

Edit:  This plan is on hold until I can discuss things with bytemaster in person and decide what I should do.

Note that most other developers received a much larger bonus, and will not be in that situation at the same time.
Title: Re: How to make payroll without multiple delegates per developer
Post by: NewMine on January 02, 2015, 07:31:49 pm
I think you are misunderstanding my intentions.  My intentions are for developers to be well compensated and error on the side of over compensation.  The penny pinchers I was referring to are those who are trying to nickel and dime developers and demanding excessive accountability to the point of hindering productivity.

I have provided complete transparency on the bonus each developer received so that people would not overcompensate developers with a large bonus + paid position. 

I want to make my own intentions clear as well.  It's not my intention to soak the community for the year-end bonus from AGS funds and additional 100% delegate(s).  Rather, my problem is that the AGS bonus will only last a couple months at the current exchange rate, and I want to be reasonably sure that I'll still be able to eat when it runs out, even if BTS hasn't gone to the moon by then.

Despite the tax accounting of the bonus, I think the community will be unlikely to support any future delegate proposal which does not treat the bonus as an advance payment of my 2015 funding.  Thus, even though I am not contractually obligated to do so, I currently plan on sticking around for at least 2-3 months with a single delegate regardless of the outcome of this discussion.

Then I plan to start a campaign for 1-2 additional 100% delegate(s) sometime in February or early March.  At that time I will provide a detailed accounting to the community, showing that my bonus has run out and I do in fact need the additional delegate(s) to continue to receive a competitive salary, and also including a detailed list of my recent contributions.

Note that most other developers received a much larger bonus, and will not be in that situation at the same time.

Wait. You just got $17K bonus and you have a 100% delegate raking around $2k per month? Plus, I assume you got $100K/yr prorated for however many months you were on I3/AGS payroll and you are publicly complaining that you think you won't be able to eat in a fewmonths?

Is this your only job? Or Did you quit a job to do this project?
Title: Re: How to make payroll without multiple delegates per developer
Post by: Gentso1 on January 02, 2015, 07:55:26 pm
I think if you just lay out what you have gotten so far it will be simply and easy for people to see what you should be getting.

Most people understand that average pay for a developer is a 100-150k a year. So why not start with a simple this is what I have been given, this is what I have done and this is what I want and you will most likely get all the answers you want. This will give you some piece of mind for the future and let the community know what your services are costing.
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 08:44:39 pm
Can you say how much you received in total as pay (BTS, BTC, USD) and how long you have been working full time so things can be put into perspective?

How much I make is a very personal question.  I don't usually like to answer it.  But I think I must be transparent about this if I want shareholders to vote for additional delegates, so I will go ahead and say.

EDIT:  Redacted, apparently being transparent is causing PR problems.  I don't really understand the issue, but for now I'm going to remove the exact accounting until I can discuss with bytemaster and others exactly what the issue is.

This exact analysis took me quite a while to prepare, which I could have spent writing code.  Which is a prime example of

demanding excessive accountability to the point of hindering productivity.

especially given that the exact answer came out pretty much the same as my back-of-the-envelope estimate of

I plan to start a campaign for 1-2 additional 100% delegate(s) sometime in February or early March.
Title: Re: How to make payroll without multiple delegates per developer
Post by: fluxer555 on January 02, 2015, 08:48:48 pm
That sounds reasonable. You have my support theoretical +5%
Title: Re: How to make payroll without multiple delegates per developer
Post by: arhag on January 02, 2015, 09:03:46 pm
I am sorry, but this kind of legalistic penny pinching will kill BTS and hurt morale.   

Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

I am very much against the idea of "selling your time" or "buying time".   If these guys are only working for a paycheck then we would get crap work out of them.   If they are working for more than a paycheck then we will get far more value out of them.   

Lets not remove incentive for efficiency.  Lets not begrudge someone profits earned as a result of taking great risk.

I don't understand what you are saying here. Once the asset belongs to them, they can do whatever they want with it. That includes selling it for BTC. It doesn't matter if you pay them in BTS or BitUSD. The incentives are still the same. All that matters is how much value they are receiving in the present day. The one possible exception to this is if stakeholders decide to selectively void someone's remaining vested BTS funds, but that is a questionable action and a slippery slope.

So your argument that incentives are somehow more aligned because the devs get BTS which can go up in value if they do a good job is complete nonsense to me. If you pay them well, I see no reason why we would get "crap work out of them" just because they are working for a paycheck. Remember, if they don't believe in the future of BTS they already could sell all of the BTS they receive for USD as they receive it. In fact, we can guarantee that even true believers will have to sell a good portion of their received BTS to pay for living expenses (theoretical described this clearly with hard numbers).

I would prefer if we had a system to pay devs and other workers of the DAC in BitUSD (or other BitCurrencies) and just allow them to buy up as much BTS as they wish (and can afford) with their excess BitUSD. I appreciate theoretical's attempt at finding a solution to this problem, even though I don't like this particular solution compared to alternatives.
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 09:07:05 pm
Wait. You just got $17K bonus and you have a 100% delegate raking around $2k per month? Plus, I assume you got $100K/yr prorated for however many months you were on I3/AGS payroll and you are publicly complaining that you think you won't be able to eat in a fewmonths?

I don't know what you do for a living, but if you moved to a different state for a new job (including paying relocation expenses out of your own pocket), and then within less than three months of hiring you they gave you a big bonus equivalent to a couple months' income, but told you they'd be cutting your pay to 1/3 going forward, wouldn't you try to negotiate a deal somewhat equivalent to what you originally agreed to -- and if you couldn't, wouldn't you at least seriously consider walking away?

be able to eat

This is a metaphor.  As others have noted, the relevant metric is opportunity cost -- how much I could be earning elsewhere, but am not.

publicly complaining

I think it's clear that I3 has little interest or ability to continue to directly pay developers.  Therefore, if I want to raise concerns about how much I am paid, I must talk to shareholders and present my case for new 100% delegate(s).  Which means making my case publicly, since there is no effective way to contact the BTS holders privately.
Title: Re: How to make payroll without multiple delegates per developer
Post by: NewMine on January 02, 2015, 09:18:33 pm
Wait. You just got $17K bonus and you have a 100% delegate raking around $2k per month? Plus, I assume you got $100K/yr prorated for however many months you were on I3/AGS payroll and you are publicly complaining that you think you won't be able to eat in a fewmonths?

I don't know what you do for a living, but if you moved to a different state for a new job (including paying relocation expenses out of your own pocket), and then within less than three months of hiring you they gave you a big bonus equivalent to a couple months' income, but told you they'd be cutting your pay to 1/3 going forward, wouldn't you try to negotiate a deal somewhat equivalent to what you originally agreed to -- and if you couldn't, wouldn't you at least seriously consider walking away?

be able to eat

This is a metaphor.  As others have noted, the relevant metric is opportunity cost -- how much I could be earning elsewhere, but am not.

publicly complaining

I think it's clear that I3 has little interest or ability to continue to directly pay developers.  Therefore, if I want to raise concerns about how much I am paid, I must talk to shareholders and present my case for new 100% delegate(s).  Which means making my case publicly, since there is no effective way to contact the BTS holders privately.

Damn. You went "all in". That's sucks. It sounds like you got duped. Hopefully you didn't burn bridges with you previous employer. Multiple delegates held by one person taxing the blockchain will definitely kill this. If there were 1001 delegates maybe, but then the block reward would be less. No win. I'd suggest looking for a new job so you can bail before you exhaust you bonus. Don't hold on to a hope and prayer, this is no sure thing. It could be years before this thing pans out. 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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 09:33:35 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: arhag on January 02, 2015, 09:35:52 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: bytemaster on January 02, 2015, 09:42:57 pm
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.   
Title: Re: How to make payroll without multiple delegates per developer
Post by: arhag on January 02, 2015, 09:45:27 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 09:47:05 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: bytemaster on January 02, 2015, 09:47:17 pm
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.   
Title: Re: How to make payroll without multiple delegates per developer
Post by: bytemaster on January 02, 2015, 09:49:38 pm
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.   
Title: Re: How to make payroll without multiple delegates per developer
Post by: arhag on January 02, 2015, 09:53:22 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: roadscape on January 02, 2015, 09:57:09 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: Gentso1 on January 02, 2015, 10:01:41 pm
Thanks for taking the time to explain your pay.

I would support you running another delegate.
Title: Re: How to make payroll without multiple delegates per developer
Post by: lovejoy on January 02, 2015, 10:10:29 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: sumantso on January 02, 2015, 10:24:41 pm
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.

 :)
Title: Re: How to make payroll without multiple delegates per developer
Post by: theoretical on January 02, 2015, 11:18:42 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: sumantso on January 02, 2015, 11:36:44 pm
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.
Title: Re: How to make payroll without multiple delegates per developer
Post by: Rune on January 03, 2015, 12:28:17 am
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?
Title: Re: How to make payroll without multiple delegates per developer
Post by: zerosum on January 03, 2015, 02:47:28 am
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! 







Title: Re: How to make payroll without multiple delegates per developer
Post by: toast on January 03, 2015, 03:03:28 am
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.

Your opinion on this would have more weight if you participated in code maintainance.

I oppose anu strategy that requires protocol changes for several more months.

Multiple delegates are OK but we need to do housekeeping / optimization before anyone gets dupes

Sent from my SCH-I535 using Tapatalk

Title: Re: How to make payroll without multiple delegates per developer
Post by: Empirical1.1 on January 03, 2015, 03:11:08 am
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?

It's a strategically bad time for BitShares but a strategically good time for him. Straight after receiving the bonus but before 1.0
Title: Re: How to make payroll without multiple delegates per developer
Post by: mitao on January 03, 2015, 03:25:24 am

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!

Yep, the incentives are aligned. Lol
Title: Re: How to make payroll without multiple delegates per developer
Post by: fluxer555 on January 03, 2015, 03:31:17 am
- 3Mil BTS bonus for Stan, for posting obscure and/or condescending comments on the forum.

I love Stan, but I do agree this is grossly in excess.
Title: Re: How to make payroll without multiple delegates per developer
Post by: liondani on January 03, 2015, 03:36:17 am
I will said it again. Problems like this can be solved if we go with the max dilution possible 50 BTS per block from the beginning !!!
BUT it must be given to delegates with fairness  and somehow we must be confident that these funds will give really value to the project and will not get wasted....

Let's hard-code payrates of delegates depended on a)votes !!!

for example right now delegate 101 gets 7.7% of votes and delegate number 1 gets 15%. I didn't do the maths but let's assume that the average % is at 9%.... that would mean that all 9% delegates will take 50 BTS per block and the 15% delegate takes 75 BTS per block and the total BTS per block for all would average to 50 BTS per delegate....

or hard code payrates depended of b) delegate place...
delegate 101 takes 1 BTS per block, 100 takes 2 BTS/block ,  ......  delegate 1 takes 100 BTS per block for a total average for 50BTS / block again...

So we don't waste time to campaign for new delegate with new payrates and new names and the market will push the best delegates to the first spots
I think it is very simple  for anybody to understand that. And we will make good use of every penny that we could abstract from bitshares dilution. Like you said all the power of self funding from the beginning!!! Don't underestimate ethereum and other projects! Don't allow to get on a situation where the competitors will develop with full power/efficiency and we are still rying to get more delegates with 100% payrate elected... It is a waste of valuable time, and even if we have elected  a lot of 100% payrate delegates soon enough, how much time will we loose to re evaluate their contributions and then  proposing each other  new payrates and new campaigns to unvote overpriced delegates, and new campaigns to upvote them again with new delegate name and new payrate etc..? It will be a big mess !!!  We will loose control nad time! I think it is crucial to make changes like this, it will make the network much more efficient...
Title: Re: How to make payroll without multiple delegates per developer
Post by: onceuponatime on January 03, 2015, 03:44:15 am
Those developers who don't actually believe that the work they and their peers are accomplishing is going to make the market cap of bitshares (and thus their pay) at least double in the next few months should probably move on to a project they do believe in.
Title: Re: How to make payroll without multiple delegates per developer
Post by: deer on January 03, 2015, 04:17:13 am
15 Mil BTS and 100K annual pay for the marketing guy that did nothing.......

God,Finally I found the reason why the price of bts keeps going down and why we are running out of ags FUND :'(
Title: Re: How to make payroll without multiple delegates per developer
Post by: toast on January 03, 2015, 04:39:56 am
15 Mil BTS and 100K annual pay for the marketing guy that did nothing.......

God,Finally I found the reason why the price of bts keeps going down and why we are running out of ags FUND :'(
Brian is not getting anu of those bts.

Sent from my SCH-I535 using Tapatalk

Title: Re: How to make payroll without multiple delegates per developer
Post by: Stan on January 03, 2015, 04:48:51 am
Total salary paid was just over 50K which was not all wasted unless you assume that he contributed nothing, which is not true.  Alas, the bigger loss is the elapsed time and opportunity cost.
 
Title: Re: How to make payroll without multiple delegates per developer
Post by: luckybit on January 03, 2015, 05:07:43 am
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?
+5% +5%
Title: Re: How to make payroll without multiple delegates per developer
Post by: zerosum on January 03, 2015, 05:34:41 am
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?
+5% +5%

Great points Rune/Luckybit!
The best time to negotiate their salaries is after they have left!

They are 2 for a buck!
Let's have our ducks ready first. Then we start searching for them!


I think the total amount of stupidity has reached its critical mass....so, you do not need me, I guess.  :)

Bye, idiots of all kinds!
 :)
Title: Re: How to make payroll without multiple delegates per developer
Post by: sumantso on January 03, 2015, 05:43:25 am
- 3Mil BTS bonus for Stan, for posting obscure and/or condescending comments on the forum.

... add to that a 100% delegate.

Costliest memes I've ever seen.
Title: Re: How to make payroll without multiple delegates per developer
Post by: kao on January 03, 2015, 06:40:09 am
- 3Mil BTS bonus for Stan, for posting obscure and/or condescending comments on the forum.

... add to that a 100% delegate.

Costliest memes I've ever seen.
+5% +5% +5%
Title: Re: How to make payroll without multiple delegates per developer
Post by: luckybit on January 03, 2015, 08:20:51 am
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?
+5% +5%

Great points Rune/Luckybit!
The best time to negotiate their salaries is after they have left!

They are 2 for a buck!
Let's have our ducks ready first. Then we start searching for them!


I think the total amount of stupidity has reached its critical mass....so, you do not need me, I guess.  :)

Bye, idiots of all kinds!
 :)

Going to sell your BTS?
Title: Re: How to make payroll without multiple delegates per developer
Post by: liondani on January 03, 2015, 01:38:31 pm


Going to sell your BTS?

Please calm all down...
It is obvious we are witnessing times of depression... that times are not optimal to sell to say the least (most times )...  tonyk cares for the project like we do (maybe more) so we should read "behind" the  lines and take his messages  serious into consideration.  Not because he is (or not) absolutely right! But because many supporters feels like he did the last couple of weeks  ...   I hope we will find solutions on existing problems before we take off(?), since it will be more difficult for  the majority of us to  admit/recognize them when we have reached double or triple market caps compared to now ... 



Sent from my ALCATEL ONE TOUCH 997D