Paid Workers Proposal for Review

[Tuck Fheman]

Why didn't these guys do this on our blockchain? '

http://www.thebitcoinchannel.com/archives/43730

Because it was not alive and offering incentives to these guys like we need it to.

Obligatory 'pics or it didn't happen'.

[rajarush]

My suggestions based on my previous post here: https://bitsharestalk.org/index.php/topic,1692.msg18720.html#msg18720

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?

^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

After reading this fantastic idea I came up with my own proposal for how this could work.

TL;DR:
Separation of community/company maintenance (Delegates) and core development.
Delegates compete to act as maintainers of the blockchain and as the human element to DAC decision making.
Core development could be funded by contracts between the shareholders and developers.
Devs propose development and a pay schedule. Shareholders pay into proposal-specific funds as they see fit and development starts once a given pledge-threshold is met.
These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.


Here is a hypothetical scenario I hope will illustrate how this could work.

I unlock my BitShares wallet and see that I have 500 cds (core-dev-shares) and navigate to the 'Development Proposals' tab. 1 cds = 1 bts but can only be spent per the terms of a core development contract.
I see that Invictus Innovations has a proposal for bitAssets 2.0. The team claim it will take 2 months and are asking for 200k bts and $2k bitUSD upfront with a 5M bts completion-'bounty'. Of this 5M bts, 2.5M will be held in escrow for 1 year and 2.5M will be converted to bitUSD on a weekly basis from the start of development until depleted. The team promises to provide proof of progress to
the community and expects Delegates to scrutinise the details.
Underneath this proposal I see that two delegates I trust (delegate.kencode and fuzzy.beyondbitcoin) have evaluated the proposal and interviewed Invictus Innovations and conclude that they think it is a proposal worthy of investment. Fuzzy has provided an .mp3 file to his 'town hall' interview and kencode has convinced me that the economic reasoning holds up.
I am now a reassured and confident shareholder so pledge 60% of my 500 cds to this proposal.
I see Moonstone is nearly funded so I send another 20% there.
But I also notice that ByteMaster has another great proposal but doesn't have the time to implement it right now. It's a minor feature not worth the time yet. He has requested an exorbitant fee to prioritise this work over his spare time but I'm sure he expects someone else to pitch for a much lower cost.
I see underneath that 'script.kiddie' has already offered to whip up the code for just $500 bitUSD with a 5k bts royalty fee to be paid to bytemaster. I pledge some more of my 500 cds and see it is instantly converted to bitUSD at market price.

A month later I come back to my wallet to check my cds balance. Script.kiddie has the new feature running smoothly but I see that another project he proposed didn't get funded within the time-window and the 50 cds that I pledged has been refunded to me to allocate to other projects.


I think that trying to merge the two distinct 'departments' of core development and efficient company maintenance stifles innovation and diversity in both departments.
Delegates should get paid for being delegates and core development teams should pitch and get paid solely for contracted tasks completed.

In order to ensure max decentralization of our DAC the shareholders need to actively participate in all aspects of the DAC.
As we are all humans with short attention spans these decisions need to be spoon-fed to us. The easier it is to participate, the more shareholders we get to take part.
If anything is complicated or hard to evaluate, participation will drop off sharply.

Groups of humans are known for witch hunts so we should make sure that when these happen they do not spill over into unrelated areas of the DAC.
For example; if a mob gets stirred up to oust a delegate providing a slow price feed then we need to be certain that there won't be any collateral damage. So delegates cannot also be responsible for funding core development.

Taulant and Moonstone have stated that they aim to demonstrate their worth by taking on risk and offering the shareholders the opportunity to invest by buying their product (their code) and having them open-source it. Could core devs take a similar approach?

Data and necessary info needs to be compiled by the DAC for presentation to the shareholders so they can make informed decisions.

Delegates need to be easily evaluated with a quick look at a list of statistics. Delegate pay should pay for the efficient running of delegate tasks only.
Core development needs to be pitched to the shareholders in a modular fashion and opened up to the free market – I propose by way of a crowd sale system.
Dev teams need to show their goals and code needs to be written in a way that allows numerous parties to add to the codebase over time. A clear list of tasks to be completed allows separate dev teams to pitch separate projects. The shareholders can then fund development as quickly or as gradually as they wish. Projects won't overlap so less time is wasted, and potential dev teams know that they will get paid for the work they do.

Shareholders who are delegates could also pitch for core development tasks if they are so inclined but shareholders need to be able to quickly see who is doing the job for which they are specifically being paid for.

For delegates this should mean that shareholders can view a list of hard stats that accurately tell them who is performing well and who isn't.
These stats include:
1) Uptime
2) Block propagation
3) Average time per price feed (possibly broken down per asset – this could be displayed next to a measure of volatility of the specified asset for a fair assessment.)
4) Other clear cut and useful stats.
5) A percentage of how many successfully funded core-dev proposals the delegate reviewed and advised on.
Delegates should also be responsible for being oracles on contracts between the shareholders/DAC and core development teams. They are the human element of the DAC so should evaluate the viability of core development proposals and also check-in on project progress.  Delegates would have no authority to stop shareholders funding unrealistic proposals but should use their reputation to serve the shareholders in an advisory capacity.


Instead of funding core dev with dilution, those block rewards could be sent proportionally to each account by their holdings. The funds could be held in some kind of multisig account that allows them to only be spent by contributing to core dev project proposal crowd sales.

Proposals for core development could be published in a separate section of the core wallet in a way that acts to 'crowd sale' the proposed project.
It costs a nominal fee to publish these ideas to avoid bloat and make it easier for shareholders to assess less options. These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.

Core Dev Proposals contain:
1) A summary of the problems aiming to be solved, what the finished product will look like/do and why/how it will work
2) a timeline
3) A fee structure. Perhaps an upfront fee and a recurring payment schedule or an on-completion bounty.
4) Proposals can also be published with the expectation that someone other than the author will bid to actually compete the task.  Devs who wish the implement someone else's idea can include a royalty payment in their proposal. 'Fund us and we'll pay 10kbts to the author as a royalty.'
This 'royalty' is voluntary but encourages 'ideas people' to promote their ideas to establish themselves in the community to increase the likelihood they'll get a royalty and as a consequence more people hear about the best proposals.
The author of a proposal may also be a large stakeholder with lots of funds to pledge to a developer team to implement their idea, so devs may want to attract this 'VC money' and so offer a symbolic/generous royalty.

The party can then pitch themselves to the shareholders on why they should get this contract. For example:

'We propose to implement BM's proposal for bitAssets 2.0. Upfront we require: 10k bts, £2k bitUSD, 5M bts to be held in escrow until completion except each month 0.5 bitGold is paid out from the fund.'

These proposals accomplish:
1) Separation of DAC maintenance and DAC development
2) Open-sourcing of ideas for core development. If a proposal contains a good idea but asks for too much funding, other parties are able to promise the same project for an alternative payment schedule.
3) A direct relationship between the shareholders and core development incorporated into the DAC itself.

Sent from my iPhone using Tapatalk

[hodor]

I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

http://www.youtube.com/watch?v=wC871hNBig4&t=1m6s

[rajarush]

How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?

^^^^

The gist of the idea is to create a job auction exchange. Jobs are auctioned on the blockchain. A UIA could represent a job and when the job is done all who have the asset can redeem for BitUSD.

Of course it would have to be simplified due to the limitations of the blockchain but ultimately the market should determine things. Let anyone bid for positions. Let the community for up or down the positions from which could be bid for and let the community set the amount it is willing to pay in some algorithmic fashion so that the jobs are auctioned to the lowest bidder.

http://www.jobauctions.com/

IMO an automated DAC is unsuitable for matching workers and jobs, because for an employer the price is only one of many criteria for selecting an employee. An employer may want to hand over a job to a more skilled/experienced worker even if he has to pay a higher price.

You proposal is missing a crucial component: who gets to decide when/if a job has been completed? You're going to need arbitrators in case of a dispute.

Also, managing such a platform creates a massive overhead for the employers and may be unsuitable for small tasks.

http://www.jobauctions.com/

Wouldn't a reputation system help with all the problems you are talking about PC?

i intend ot agree PC!

Who will decide, for example, on graphic related tasks, if an design is finished in view of requirements, graphic style, sustainability?
On technical side requirements are much more clearer to communicate ... but for esthetic etc. purposes ... who will decide if a job task is solved?
(used the designer example ... you know why^^)

Just want to quote, it looks long


Sent from my iPhone using Tapatalk

[Stan]

“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.”


― Douglas Adams, The Restaurant at the End of the Universe

Actually more appropriate is the monster ,(forgot its name) described/created by the same author. Anyway the monster believes that if you cannot see it the monster itself cannot see you.
So the best defense against it, is to close you own eyes

[Edit]
The Ravenous Bugblatter Beast of Traal is a wild animal from the planet of Traal, known for its never-ending hunger and if you can't see it, it assumes it can't see you.

if the Guide is to be believed. For, according to the Guide, draping a towel over your head will confuse the beast long enough for one to make a quick getaway. This is because (as mentioned above) the philosophy of The Ravenous Bugblatter Beast is that, if you can't see it, it can't see you.

[Tuck Fheman]

Thanks for answering (I think/hope) my question from the other thread.

[zerosum]

“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.”


― Douglas Adams, The Restaurant at the End of the Universe

Actually more appropriate is the monster ,(forgot its name) described/created by the same author. Anyway the monster believes that if you cannot see it the monster itself cannot see you.
So the best defense against it, is to close you own eyes

[Edit]
The Ravenous Bugblatter Beast of Traal is a wild animal from the planet of Traal, known for its never-ending hunger and if you can't see it, it assumes it can't see you.

if the Guide is to be believed. For, according to the Guide, draping a towel over your head will confuse the beast long enough for one to make a quick getaway. This is because (as mentioned above) the philosophy of The Ravenous Bugblatter Beast is that, if you can't see it, it can't see you.

[Stan]

“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.”


― Douglas Adams, The Restaurant at the End of the Universe

[zerosum]

"Devs need to pay the rent and buy food today" and "We'll vest their pay for five years" does not reconcile. Who fronts the cash for their salary in the mean time? If they have been given their salary up front to pay bills who gets the vested BTS?

So if I understand correctly it boils down to some combination of:

1) An affiliate revenue program will be enough to support seven devs now and the five year vest BTS are like stock options and not salary.

2) Someone fronts all the money for salaries and is paid back via affiliate revenue with the big bonus of BTS after five years once their project has helped make it all a big success.

3) The shareholders are voting on the stock options given to the project owners after five years and not how much the project will earn day to day.

Am I close?

Alternatively:

-Stan got BM's memo.
-Gave it a little bit of PR polishing...not much just replaced the 5 day vesting with 5 year vesting.

Voilà!

[bytemaster]

I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

[Pheonike]

I can understand using BTS as a stock option, but 5 years is too long.  2 years is long enough to know if this will be a success. If we are not ready in 2 years then someone else will have already mopped the floor with us by then anyway. With everything being open-sourced  it is easy for a competitor to build on your stuff faster than you can pivot sometimes. We have been lucky so far, but that luck is going to run out sooner than later.

[xeroc]

Am I close?

All of the concerns people keep expressing are being addressed in a far, far more comprehensive way than an outside observer could possibly imagine.

 

[Riverhead]

"Devs need to pay the rent and buy food today" and "We'll vest their pay for five years" does not reconcile. Who fronts the cash for their salary in the mean time? If they have been given their salary up front to pay bills who gets the vested BTS?

So if I understand correctly it boils down to some combination of:

1) An affiliate revenue program will be enough to support seven devs now and the five year vest BTS are like stock options and not salary.

2) Someone fronts all the money for salaries and is paid back via affiliate revenue with the big bonus of BTS after five years once their project has helped make it all a big success.

3) The shareholders are voting on the stock options given to the project owners after five years and not how much the project will earn day to day.

Am I close?

[Empirical1.2]

I would like to ask: What is the big problem with the current system which requires this change?
Why does this change need to be prioritized now, when we are desperate for things like a stable client?

I think we should avoid creating a huge overhand of vesting BTS which people know will be unlocked at some point in the future.  This could make people think "Well, if I invest in BTS now, I'm going to get dumped on in the future as soon as those shares become unlocked".

The paid worker proposal seems to be specifically tied to the 'project' BM is proposing. So it is most likely a workaround for VC funding.

Personally I don't think I'll be a fan unless the VC is also a gateway or that's in the mix too.

[nomoreheroes7]

Plenty of code being developed off line to maximize the huge lead BitShares is building on its competition.

All of the concerns people keep expressing are being addressed in a far, far more comprehensive way than an outside observer could possibly imagine.

Would you really want us to abandon our carefully designed comprehensive solution to run off after every angry demand someone posts in bold print? 

This is a chess game and sometimes a player needs to make a few "pointless" moves in advance that the average kibitzer doesn't fully appreciate at the time.

 

Sure have been a lot of hints lately at something huge in the pipeline...hope the wait (and cheap BTS) are worth it.