just talked to the devs , there was a UI bug in the GUI interface that you can't approve delegates after 101 , you can only do that in the command line client at the current version , that's relate to the described OP question . (if you click the little palm for delegates after 102 , it won't change the status )

Thanks for the feed back . Please leave your DACPLAY account name here joele , I will ask the devs to send you some PLS for discovering the bug by accident . 

Quote from: joele on June 05, 2015, 08:22:59 am

Quote from: btswildpig on June 05, 2015, 07:40:29 am

Quote from: joele on June 05, 2015, 05:11:14 am

Please dev, please lie low some of your init# delegates so we users can be part of the top delegates.
Thanks

It's their idea . New delegates will be voted in once there are applicants .

Sorry I don't buy their idea, rather I smell greed.

You need to run your server for a month to even barely cover the registration cost for a delegate before today .
That's why not many applicants . How can there be greed when you need to run for a month to barely cover the registration cost ?

For the record , I've been asked to advertise how to become a delegate for PLAY days ago , that's their intention ----get rid of many init delegates as possible instead of keeping them .
If anyone is running a solid delegate but not in 101 yet , lay down some brief introduction of your server , it will be voted in pretty soon .

Also , you can't be just a "user" to run a delegate . You need a VPS server with un-interrupted connection 24X7 with cost at least 15 USD / months and Linux skills  . You shouldn't run it on your home computer .
Not every "delegate account" is suit to be a "delegate" .  That's two different thing .

It looks like there are hundreds of "delegate account " , but in fact only few of them after 101th can be up and running without interruption once the init delegates are gone .

We'll see what happens, but I fully believe the current low exchange price of BTS is something we won't see ever again.

I've described the paid worker solution that I would like to see in this post. I think we should just let the management of project/worker payment be delegated to the elected delegates. The shareholders should make their desires/opinions official known to the delegates via a non-binding proposal system on the blockchain. The delegates are trusted to carry through with the shareholder wishes (in a responsible way), and if they fail to do so they will be voted out. I think giving this responsibility to the delegates rather than the shareholders (essentially adding that level of indirection) should hopefully make the workers feel like they are less likely to get the rug pulled from underneath them due to some chaotic irrational/emotional response from the masses. The delegates essentially act as a check on the shareholders. However, they ultimately answer to the shareholders because they can be easily voted out and replaced by new delegates that will consider shareholder opinion more.

There are also safeguards preventing delegates from just spending as much on a worker as they want (beyond just the hard dilution limit) such as the dilution budget collectively available to them (that they don't necessarily need to all spend) by virtue of being elected with some budget request (which could only be adjusted up by getting a new version of their delegate elected by shareholders) and the fact that a super majority of the delegates need to agree to any change to the worker pay list. One other thing I would add to my linked proposal is that the recipient account in the worker pay list could either be a vesting type or a non-vesting type. The vesting type would have an additional parameter in the tuple defining the vesting period that the recipient needs to wait until they can access the accumulated funds held under their name.

Edit: By the way, if it wasn't clear, the approach described above allows the super majority of the delegates to implement any policy for funding projects (including the one in your post BM). The idea is that the policy isn't encoded as code in the blockchain, and therefore is more dynamic. The non-binding proposal system can allow shareholders to vote for and against any project with a start and end date, for example, and the delegates are responsible for carrying out that policy. It is sort of like the difference between the Turing complete scripts on Ethereum vs smart contracts implemented using a super majority multisig of executors and actually executing the deterministic code off-chain (like Open Transactions' Voting Pools, or Codius smart contracts, or maybe future BitShares smart contracts(?)).