1
Stakeholder Proposals / Re: Refund worker lost support, and now we have a ton of workers
« on: May 26, 2016, 01:34:31 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.