Quote from: lovejoy on May 26, 2016, 01:34:31 pm

Quote from: BunkerChain Labs on May 25, 2016, 09:50:46 pm

Quote from: lovejoy on May 25, 2016, 07:46:09 pm

The average worker summary might be something like:

I was working one day, starting to make progress on worker proposal X, but then I got fired the next day so I shifted my priorities and started working on something else, trying to earn a living you know?

Then a week later I got voted back in, so I thought, ok, well I'll give it another try and start working on this project again.

After two weeks passed I was really starting to make progress, but I was once again voted out, so I went back to looking for real work where I'm not hired and fired seemingly at random.

Then one day I noticed my worker was voted back in, but by then I was so tired of the uncertainty that I had just moved on to something else less stressful and uncertain.

Is this not a problem which needs to be addressed?  What developer wants to work in such conditions?

Would it not make more sense to be hired for a fixed term determined by the project scope?

2bts

I've sort of had a similar thought in regards to worker proposals. There needs to be a consistency.

Voters have to be voting to a certain degree of commitment the same as the commitment being given by the worker.

That said, there has to be greater consistent reporting by the worker as well.

I would like to see some kind of function in workers that had a reporting period required. Basically just a cmd that had to be executed with only a URL supplied to give a report on work and progress. If this isn't executed then within 48 hours the worker expiration is executes early and his worker ends. At that point he has to open a new worker and convince the shareholders to restart.

Generally if you don't show up to work for 2 days without any explanation or attempt to communicate, you would be replaced. In this instance I think a weekly, biweekly reporting period would be ideal and keep shareholders in the loop to know that progress is being made... if there is the commitment from the blockchain, then this level of reporting to maintain isn't unreasonable to be expected from the worker.

This however would require some additional work that would require a hardfork. I don't think we should hold back on making improvements to the worker proposal space in Bitshares.. it clearly can use improvements. If our tool for improvements to BTS is working well, it will help along all other improvements more efficiently.

Just my 2bts.

Yeah, I think having mutually reinforcing expectations of both shareholder / protocol, and worker would be really good.
As I attempted to illustrate above it's currently a pretty wishy-washy scenario.  I really like the suggestion of baking a solution right into the protocol.

I would support some kind of weekly reporting criteria.  I like the command idea, but in order to keep this from being gamed for the duration of the work period, perhaps this is an area for some limited oversight, override capacity from the committee.

Haha yeah.. was just talking about this with @xeroc

What I suggested is only half the equation. On the other side we need voter dedication. If another committee dedicated to Workers was formed to handle oversight of workers, they could act as a sort of accountability measure. One thing I think is a absolute must for this to work though, is to have it where committee members are experienced employers. Otherwise the same folly of the tragedy of the commons just gets reduced to a smaller number that repeat similar mistakes. Basically in that committee roll they could override the worker if they really are not meeting up to the proposal outline. This will prevent weekly 'dumb' reports from gaming the blockchain.

With a Decentralized Project Oversight Commitee (DPOC) (copyright me) in place, then when voters vote, I think it would then be for the duration of the contract presented then.. and they cannot be voted out.. the contract either goes to the end being completed as promised, or it gets terminated earlier on by the DPOC or by the workers own lack of accountability. DPOC could act as a multi-sig perhaps on the funds being paid out as well.

I would really like to see vesting also make some kind of comeback in worker proposals. Sure people have to be paid, but give them some kind of long term upside as well for what they are doing to make it more attractive.

Some of the ideas discussed above relate to how I'm managing the funds from the Blockchain maintenance developer. I'm treating the funds accumulated in that account as "allocatable" to blockchain maintenance projects. So if someone proposes to fix a bug at a cost I consider reasonable, I can guarantee that there's sufficient funding to pay for the work. So while funds will build up at times when no one is specifically working on a project, those funds will only be paid when work is performed (and I'll post about the amount paid and what work was done by whom). If the amount builds up to an amount I consider excessive, I'll simply send some back to the reserve account.

At this moment, I've allocated $1000 USD equivalent of BTS (actual amount paid will depend on BTS price at time of payment) from the fund for BlockTrade's work on the memo key bug. I'm also planning to spend some from this account to partially pay for work being done on adding the ability to distribute dividends to UIA holders. Beyond that, we'll just be on the lookout for other problems that arise or a compelling feature that seems to have community support that can be added at relatively low cost.

Cool, thanks for responding guys. It's nice to see there's still some active dev effort going into Bitshares. As one of the users of the technology, i am certainly appreciative!

Are there any other devs you guys know of actively working Bitshares projects?

From blocktrades side, eric and I devote a lot of time to bitshares related work and I'm in the process of adding 3 or 4 more Devs to our group.

Sent from my DROID RAZR HD using Tapatalk

hi dan,

with "cargo" i meant the sold BTS in secret for month.

It is true that many people can take over, but do you really believe that when Vitalik would leave ETH it will not hurth the market and the potential of ETH? People would look into his new "baby" and would ETH leave behind, because they would suspect it will be much better then ETH.

In my eyes the core founder leaving BTS activly behind is just killing for 1 year at least.

It's true that BM sold off some significant portion of his BTS holdings prior to formally announcing his departure to Steemit, but I guess it's been obvious for some time that he was dumping shares (with BitShares being so transparent, moves by whales are usually noticed within hours and BM's accounts were closely watched).

I'm sure BM leaving BTS development to work on Steemit hurt its value in two ways: 1) he hasn't been contributing to BitShares as much for a long while and 2) now that it's formally announced that he's actively working on another project, people can't kid themselves that he's working on BitShares still despite the lack of commits from him.

Despite that, I haven't seen a huge drop in BTS price, mainly because I think many people had already factored this in to some extent and also because some people saw disadvantages to BM's strong control of BitShares development. Now that there's no one that can really dominate the future of BitShares or make huge changes in the rules with limited consent from the community, it's a much more predictable platform to build on.

I don't think it's likely to see people leaving BTS for STEEM, mainly because they are two very different projects. I'm involved in steem, but for entirely different reasons than I'm involved in BitShares, so there's no reason to leave one for the other. I'm more involved with BitShares than ever, as I think we're making solid steps towards what BitShares needs to be and I'll use steemit where I can to promote that. I can also say that nearly all the BTSers involved in steemit are still also very involved in BTS (I know of one exception, but he had left BTS before steemit was ever announced).

Xeroc in cryptofresh.com/ballots i can see that commitee members that you, kencode n more 3 say yes to cronos proposal......

So could you explain?

They are voting their private stakes (or in xeroc's case, his proxied stake) for Chronos' proposal. What xeroc means is that voting for a committee member doesn't give any more weight to their votes (that's achieved by proxying to an account).

Quote from: xeroc on May 20, 2016, 06:20:08 am

Quote from: cube on May 20, 2016, 02:04:18 am

What can we do to bring some sense into LTM?

Restrict more ops to require LTM ... like `create_asset`, `create_withdraw_permission` and stuff

Tweaking the fees is certainly a good way forward. However any fee that we increase would have consequences.  Those who wishes to create asset may no longer find it worth while to do so or that they may find a competitor chain cheaper and make more $ense.  IMHO, we do not want to go a similar path as  the 20-US-cent-transfer-fee.

We need to find a price point where we can bring in good revenue and attractive to LTM-buyers, and yet comfortable to our target market. ie the consumers are willing to pay.

We should certainly be careful about raising fees, but if prices for creating assets are too small, I think it's actually a weakness for our chain because of the extra  mess it creates in the assets view and is more likely to lead to asset name squatting. I think requiring a minimum investment of an LTM is a cheap requirement to create assets, and I doubt that anyone not willing to spend that amount (or basing their decision on what chain to use based on such a small amount) is likely to bring interesting assets to our market.

Also, I think we're hijacking Chrono's thread, so going to repost my last post:

@xeroc interesting idea. I think since the worker proposal can be voted out at any time, and the payment will vest for 30 days, shareholders are already well protected.

I've produced a video to introduce this worker proposal! Check it out: https://youtu.be/RYFmBVTJodY

I agree, Chronos, and the videos you've produced so far speak for the quality of your work. I wish I had seen a video like the one above the first time I voted: I was ready to file a bug report before I figured out the need to press the publish changes button.

For anyone who's not voted before and would like to vote for this proposal, I recommend watching the above video clip.

Funky! The images are not respecting their sizes for some reason, can you reproduce this? Browser/OS?

Sent fra min MotoG3 via Tapatalk

It been that way on one of my systems for a while:
Chromium version 48.0.2564.82 Ubuntu 15.04 (64-bit)

How's this project going? 

IPO is still in the works, but we keep getting distracted by other projects/tasks with tight deadlines. We're looking to hire 3 or 4 more programmers soon to help handle the workload.