How much freedom and flexibility do workers in BTS2 need?

[xeroc]

I agree that we should hold the workers to the highest standards.  There should be no opportunity for workers to modify terms or description after getting approval, as any change should require being voted on again.  I like the publishing the hash of the proposal idea.

The issue I am seeing is this: A contract should be immutable .. sure .. but BTS proposal are not worker contracts .. they are PROJECTS proposals ..

Imaging you wanted to implement an awesome new feature into BTS (with hardfork proposal etc..) .. then you get elected and during the time you work on this thing you figure out a way to even improve on that ... but your "old" proposal doesn't allow you to implement the cooler feature .. you would be required to finish your "old" work and set a new proposal to upgrade to "old" work .. that makes no sense to me ..

I'd rather allow them to modify/improve/adept their "project description" and have the shareholders notified ..

[puppies]

I agree that we should hold the workers to the highest standards.  There should be no opportunity for workers to modify terms or description after getting approval, as any change should require being voted on again.  I like the publishing the hash of the proposal idea.

[fav]

I like your idea and I think we have to set a high bar for  worker proposals.

I expect at least a PGP signed proposal here on the forum, which must be quoted by 2-3 trusted members.

certainly, your hash idea is a better way.

[xeroc]

During my researches for the whitepapers I found this code:

https://github.com/cryptonomex/graphene/blob/master/libraries/chain/include/graphene/chain/protocol/worker.hpp#L64

It basically requires workers to publish
* work_begin_date;
* work_end_date;
* daily_pay;
* name;
* url;
for their proposal.
Do we really like them to put a URL into the blockchain? That would allow them to be flexible on the one hand but also give them the freedom to manipulate their proposal at any time.

An alternative would be to allow them to publish a digest (hash of text).
That would
* require them to publish the text that resolves to the digest
* force them to think extra about consequences before publishing a proposal
* prevent them from manipulating the text
* but removes any flexibility (i.e. if they encounter problems and need to change the description)
In the real world, we sign CONTRACTS and they do not change .. every ..

There is another alternative to educate the shareholders to agree on repository-hosted proposals (e.g. github) .. that way shareholders could implement notifications via hooks easily and don't need to parse some webpage with possibly dynamic menu bars etc ...

What are your thoughts?