BitShares Forum
Main => Stakeholder Proposals => Topic started by: Chronos on May 24, 2016, 05:53:10 pm
-
Btsnow is receiving BTS now. And a bunch of other workers. As a community, we need to be a bit more purposeful in this area. Random fluctuations should not be the driving factor. Time to bring your votes out!
(http://i.imgur.com/9noM2ze.png)
-
Xeroc is my proxy. He supports btsnow worker. the competition is still between us and the chinese. But we finally are number 1 proxy!!
-
actually I feel the worker owners need to give some report/explanation on the current status of the workers. community are not aware whether the owners still pay time and effort on these workers, especially after some developers switch to STEEM.
in China community the "vote the workers out" voice rise again. if you need to convince them that the worker is necessary you need to explain to them.
-
actually I feel the worker owners need to give some report/explanation on the current status of the workers. community are not aware whether the owners still pay time and effort on these workers, especially after some developers switch to STEEM.
+1
-
actually I feel the worker owners need to give some report/explanation on the current status of the workers. community are not aware whether the owners still pay time and effort on these workers, especially after some developers switch to STEEM.
+1
I'm away at conference today but I'll post about our work and plans tomorrow.
Sent from my DROID RAZR HD using Tapatalk
-
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
-
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. :)
-
I'm kind of annoyed, that xeroc's proxy is funding his own worker's ( two of them!). Documentation - okay. But who asked for his python scripts? W'ere paying him in excess of 600k BTS per month for that!?
And I don't like his support for the advertising worker either, Mr. Chronos. Nothing against him, I don't want to fund advertising at this point. development, yes.
-
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. :)
Man i really like your sugestion, making something smart to follow workers job makez a lot of sense
Just my 2bitcny
-
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.
-
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.
-
Surprised to see my worker (Blockchain Explorer and API Development) back in, even though there's only a few days left.. these weeks are busy but I'll gladly put this pay towards more updates in June!
-
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.
-
Surprised to see my worker (Blockchain Explorer and API Development) back in, even though there's only a few days left.. these weeks are busy but I'll gladly put this pay towards more updates in June!
Awesome! Do you have a thread for feature suggestions? The Charts page is starting to load slowly, and might benefit from some caching. Another interesting area you could consider is Richlists / coin distribution graphs. Other chart ideas could come from our Blockchain friends: https://blockchain.info/charts. Also, committee/witness/worker/proxy support-over-time graphs.
Just some ideas. :)
-
It's sad to see some workers get paid but don't work.
-
It's sad to see some workers get paid but don't work.
Which workers are you referring to? If you're referring to the blockchain maintenance worker, I've already posted that we will not draw from the fund except when we do some work, and if the fund builds up too much, we'll just send it back to reserve fund. To date, we plan to draw $1K from the fund for fixes to memo encryption, but I haven't bothered to do that yet. We're also at work on a dividend feature currently, and we'll draw some for that as well.
In other news, I have hired a new web programmer who will start in 2 weeks, and I plan to assign him some tasks related to improvement of the web wallet. If there's no major objections, I would pay him part of his salary from the blockchain maintenance worker and I'll subsidize the rest.
-
It's sad to see some workers get paid but don't work.
Which workers are you referring to? If you're referring to the blockchain maintenance worker, I've already posted that we will not draw from the fund except when we do some work, and if the fund builds up too much, we'll just send it back to reserve fund. To date, we plan to draw $1K from the fund for fixes to memo encryption, but I haven't bothered to do that yet. We're also at work on a dividend feature currently, and we'll draw some for that as well.
In other news, I have hired a new web programmer who will start in 2 weeks, and I plan to assign him some tasks related to improvement of the web wallet. If there's no major objections, I would pay him part of his salary from the blockchain maintenance worker and I'll subsidize the rest.
That sounds very reasonable. Thanks Dan. Do you plan to post all funds that you actually use /draw in you worker thread? I think that would be a good idea in this case (and in all cases of reasonable self governance becoming appropriate in such unexpected cases).
-
It's sad to see some workers get paid but don't work.
Which workers are you referring to? If you're referring to the blockchain maintenance worker, I've already posted that we will not draw from the fund except when we do some work, and if the fund builds up too much, we'll just send it back to reserve fund. To date, we plan to draw $1K from the fund for fixes to memo encryption, but I haven't bothered to do that yet. We're also at work on a dividend feature currently, and we'll draw some for that as well.
In other news, I have hired a new web programmer who will start in 2 weeks, and I plan to assign him some tasks related to improvement of the web wallet. If there's no major objections, I would pay him part of his salary from the blockchain maintenance worker and I'll subsidize the rest.
That sounds very reasonable. Thanks Dan. Do you plan to post all funds that you actually use /draw in you worker thread? I think that would be a good idea in this case (and in all cases of reasonable self governance becoming appropriate in such unexpected cases).
yes, I will post when I make a draw and describe what the draw is for.