Paid Workers Proposal for Review

[Stan]

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.

 

[BTSdac]

Objectively speaking
I like this idea ,  but we must lost some user/investor  if this proposal would been carried out finally .
we also have 7 core developers now?  I doubt  it, because recently there are less and less code update

[fuzzy]

There have been many discussions over the past 6 months about having paid workers separate from Delegates as well as changing the maximum income per worker without increasing the dilution limit.   I would like to explore how this might look and see what ideas you all can come up with.

Step 1:   Assume there are at most 432,000 BTS per day available to be paid to workers.  (50 BTS every 10 seconds)
Step 2:   Assume there is a list of projects that specify how much they need paid each day.
Step 3:   Pay out projects in order of total approval once per day until all 432,000 BTS has been consumed.
Step 4:   Have several projects that payout to no one (burning) and thus prevent dilution.

Next define each project in terms of the following parameters:

1) Start Date
2) Fundings to Receive Per Day
3) End Date for Funding
4) Vesting Period for Funds Received

Next give each account the ability to vote *FOR* or *AGAINST* each funding proposal.
Sort all projects by NET votes including the burn projects.
Each projects funding would flow to an account with multi-sig authority (for serious projects that demand accountability).

Under this model I would propose the following project:
We have 7 core developers that need at least $25,000 per month (combined) just to pay for Food, Shelter, and Clothing and earning 1/4 what they could make on the free market.  These 7 core developers form a company that produces a wallet and profits from referral income.   This company would have a funded project with a roadmap for BTS and would receive 250,000 BTS per day that their project is in the top list of  projects for 4 years.   The funds would not vest for 5 years which means the core company would not sell their 250,000 BTS/day for 5 years.    5 years is long enough that the project is either a success and the dilution is insignificant or a complete failure and the shares are worthless anyway.   Either way existing BTS holders benefit from work today that is ultimately paid for in 5 years.  Each year the devs can re-negotiate their project funding and shareholders can vote in new terms as the vote down the old terms. 

At any time this developer company could be fired by giving more votes to a burn proposal or an alternative set of developers.  When they are fired they stop receiving new income but must still wait for 5 years before they can touch any of the BTS they have already earned.   

This would have the core devs consuming about half of the available dilution (3% per year) and allowing the community room to fund other projects with the remaining half of the funds.   

Currently the Core DEVs have about 15 paid delegate slots and their pay vests immediately.   Under this new approach their combined pay would be 3x higher but it wouldn't vest for 5 years.   Perhaps most importantly, this would still keep the number of block producers decentralized and keep the sell pressure caused by dilution at bay.  Additionally it makes it easier for shareholders to vote for one "company" than for individual developers which may come and go without accountability.   

By having VOTES AGAINST a project it becomes easier for stakeholders to vote down projects they explicitly don't want funded in the event of a change in circumstances.

Thoughts?

Stop thinking about anything else before you deliver a wallet which any HUMANBEING is able to operate. Will you?
钱包都没法正常使用的前提下就别去谈其他的鸡巴玩意。

This truthfully is the big take away.  I hate to say it but it comes up over and over again.  There is a recurring theme here.  Luckily BM says that this is one of the big things on the horizon.  Even if he is wrong, moonstone is going to be....well.  Sexy:

[muse-umum]

There have been many discussions over the past 6 months about having paid workers separate from Delegates as well as changing the maximum income per worker without increasing the dilution limit.   I would like to explore how this might look and see what ideas you all can come up with.

Step 1:   Assume there are at most 432,000 BTS per day available to be paid to workers.  (50 BTS every 10 seconds)
Step 2:   Assume there is a list of projects that specify how much they need paid each day.
Step 3:   Pay out projects in order of total approval once per day until all 432,000 BTS has been consumed.
Step 4:   Have several projects that payout to no one (burning) and thus prevent dilution.

Next define each project in terms of the following parameters:

1) Start Date
2) Fundings to Receive Per Day
3) End Date for Funding
4) Vesting Period for Funds Received

Next give each account the ability to vote *FOR* or *AGAINST* each funding proposal.
Sort all projects by NET votes including the burn projects.
Each projects funding would flow to an account with multi-sig authority (for serious projects that demand accountability).

Under this model I would propose the following project:
We have 7 core developers that need at least $25,000 per month (combined) just to pay for Food, Shelter, and Clothing and earning 1/4 what they could make on the free market.  These 7 core developers form a company that produces a wallet and profits from referral income.   This company would have a funded project with a roadmap for BTS and would receive 250,000 BTS per day that their project is in the top list of  projects for 4 years.   The funds would not vest for 5 years which means the core company would not sell their 250,000 BTS/day for 5 years.    5 years is long enough that the project is either a success and the dilution is insignificant or a complete failure and the shares are worthless anyway.   Either way existing BTS holders benefit from work today that is ultimately paid for in 5 years.  Each year the devs can re-negotiate their project funding and shareholders can vote in new terms as the vote down the old terms. 

At any time this developer company could be fired by giving more votes to a burn proposal or an alternative set of developers.  When they are fired they stop receiving new income but must still wait for 5 years before they can touch any of the BTS they have already earned.   

This would have the core devs consuming about half of the available dilution (3% per year) and allowing the community room to fund other projects with the remaining half of the funds.   

Currently the Core DEVs have about 15 paid delegate slots and their pay vests immediately.   Under this new approach their combined pay would be 3x higher but it wouldn't vest for 5 years.   Perhaps most importantly, this would still keep the number of block producers decentralized and keep the sell pressure caused by dilution at bay.  Additionally it makes it easier for shareholders to vote for one "company" than for individual developers which may come and go without accountability.   

By having VOTES AGAINST a project it becomes easier for stakeholders to vote down projects they explicitly don't want funded in the event of a change in circumstances.

Thoughts?

Stop thinking about anything else before you deliver a wallet which any HUMANBEING is able to operate. Will you?
钱包都没法正常使用的前提下就别去谈其他的鸡巴玩意。

[fuzzy]

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.

Um let's ignore my name was put in there for a moment.  I love this proposal. I also think that RGCRYPTO is working on a bitshares chamber of commerce that would fit perfectly into this.

My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!

Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month. 

Good. I'm glad to see us moving forward here. Because this has been by far the most concerning aspect of bitshares in my mind for the past year.  Imho if we had a very easy to use UI and stable wallet we would not need an affiliate program because our most passionate community members would have sold bitshares very effectively to those around the without the need for payment. This would have meant we could have focused instead on fixing the issues with ensuring interest was included in accounts...which would have been epic for 3rd world users--the people who are foaming at the mouth for liquid interest bearing accounts.

[crzme]

Your ignorance once again hurt the market.

[Permie]

Ander: I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

I agree. I think our core product bitUSD needs to work flawlessly on a stable client with adequate bts ---> bank account services before any other major changes are made.

Then once we have a working product that we can leave to spread and attract customers I think it is important to out-source core development to multiple parties.
A few months spent designing and implementing a new core-development Delegate-like system to effectively outsource core development tasks could spark exponential development.

If we set up the environment correctly 'pivoting' will no longer be a problem and shareholders can have assurances that work paid for will be completed. Under the current system shareholders do not have enough information to evaluate the progress of core-development - there are simply too many delegates to investigate on a regular basis and the details of their projects are somewhat inaccessible.

Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month. 

Great to hear. Clear and concise information is what shareholders need

[Ander]

Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month.

This is excellent, and if the plan is "we will release stable '1.0' first, and this is something we will work on afterwards", then that sounds better.  I just want to make sure we have good priorities, and release critical fixes and stability before we go changing things too much.

[bytemaster]

My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!

Relax.  We are working on a stable "1.0" that you will be thrilled about.  The full set of features / documentation / etc will be well defined and released in about a month. 

[Ander]

My counterproposal:

* Instead of spending time on this, spend time on getting bitAssets 2.0 finalized and coded, and getting stable client released fairly soon. 

* As a result of 1.0 release and improved bitassets which ahve better convertability and don't punish shorts, BTS price hopefully rebounds.  Developer pay goes back towards what we would like it to be.  If BTS price doesnt rebound, developers create more paid delegates, and the community can vote them in to keep devs fed.

* Later on, now that the critical and immediate needs of Bitshares are completed, if we feel that separating workers from block producers is important, put time into working on this.  But even then, it is competing against other features that would be nice, such as the bond market, prediction market, voting on proposals, smart contracts, etc.


If the plan in the original post in this thread is better than my plan, or is critical right now for some reason, please explain why.  I am very open to hearing this, and am not going to claim that I am definitely right or anything like that.  After all, the core team is MUCH better informed about what is going on in bitshares than I am, and they know everything going on behind the scenes, and I don't. 

What makes it so that we NEED to prioritize work on this change right now?  Is this the biggest thing for us to work on right now?  Is it worth pivoting in this way, given the perception that we already pivot too much, and that we are also already pivoting on bitAssets (which is necessary). 


I would like to see a Bitshares that doesnt just pivot, pivot, pivot, over and over.  But sticks with working things and gives them time to work.  We learned that bitassets had a problem and we needed to fix that, which is important, and justifies the pivot there.  What requires the pivot here, at this point in the development?  If the devs need more compensaiton, which is justified imo given that the price declined so much, isnt the easy answer of 'devs create more delegates and we vote them in' a much better solution?  One which requires no development time because it doesnt change bitshares in any way?


I would really like to see a stable 1.0 release which fixes problems people are having with the client as soon as possible.  Other things should not be being prioritized over this unless they are essential.

Thanks!

[Permie]

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.

[fuzzy]

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^^)

Couldn't delegates decide on this?

I think nobody wants to have certain delegates (like me) make decisions concerning graphic style. ;-)

That is why a delegate like yourself would likely heavily consider the opinions of the community at large, and then also consider the thoughts of a delegate like cass. Right?

[Ander]

There is no problem except perception.  This particular new tool addresses the mere worry that a couple percent of dilution is somehow responsible for the current depression.

I dont think that a couple percent of dilution is responsible for the current depression.  I think more people worry about the fact that things change constantly, and that the stable client is still not released.

I worry about changing things yet again, without a very clear benefit.  What makes the new plan massively superior to the current paid delegates, that means we should direct development efforts towards this change right now, when there are also other critical features and fixes that need to be worked on?

You are not getting married.  If this idea gets proposed and approved and remains unrevoked, you can  enjoy the work of the devs for four years and then Sell if you think the company that brought you all this is going to dump it all in year five.   

I don't think the devs are all go to dump in year 5, and I dont want to sell (unless the price is waaaaay higher).  But I want to avoid a scenario where traders have the idea "we all better race to dump prior to these vesting shares being unlocked".  But I guess that is a problem for another time.

[Stan]

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".

We have an integrated solution to 17 different issues.  Relax.

There is no problem except perception.  This particular new tool addresses the mere worry that a couple percent of dilution is somehow responsible for the current depression.

You are not getting married.  If this idea gets proposed and approved and remains unrevoked, you can  enjoy the work of the devs for four years and then Sell if you think the company that brought you all this is going to dump it all in year five.   

[luckybit]

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^^)

Collaborative filtering could decide. Vote up or down until a threshold is reached and pay is doled out.