[Worker Proposal] Blockchain maintenance developer

[dannotestein]

@dannotestein then let's continue to discuss this at the end of April, have a good holiday.

@BunkerChain Labs yes I think this work proposal have chance to continue, if the price can be limited in a relatively reasonable level, we should support useful and efficient work, if it is not over paid.

sounds good

[bitcrab]

@dannotestein then let's continue to discuss this at the end of April, have a good holiday.

@BunkerChain Labs yes I think this work proposal have chance to continue, if the price can be limited in a relatively reasonable level, we should support useful and efficient work, if it is not over paid.

[dannotestein]

in China Community discussion seems the main point for this worker proposal is:

the price is too high.

as:

1.the job is normal maintenance/update job.
2.comparing to the date this proposal is created, the price of BTS has rised a lot.

so maybe a 20~30k  perday price is reasonable in current date?

I don't think I got enough knowledge and information to give such a suggestion, but I hope this can be a starting point for discussion.

@bitcrab 

What if the worker agrees to refund the portion of his worker each month to match the rate or close to the rate you are talking about, would that at all change the voting position in China?

I'm trying to determine if there is a solution to be created for the current worker proposal to continue. Is something like this sufficient?

It was always my plan to refund unused pay from the worker and I have to value it's expenses in USD for tax purposes anyways, since that's what most of the sub-contractors are getting paid in, so I'd be fine with operating with the above expressed spending limits on the current worker (or even less if BTS appreciates significantly enough). But I'm not interested in creating a whole new worker at this point, as there is a significant cost associated with that and there would be no guarantee it would get voted in anyways.

BlockTrades itself is still very busy at the moment (we're adding support for several new unique coins  and we're preparing for our public offering), and CNX is pretty tied up with STEEM it seems, so I don't expect we could do much at the moment anyways. In addition, I'll be gone on vacation to be with my parents for the latter half of the month, so I'd suggest we take up this discussion again near the end of April.

[BunkerChainLabs-DataSecurityNode]

in China Community discussion seems the main point for this worker proposal is:

the price is too high.

as:

1.the job is normal maintenance/update job.
2.comparing to the date this proposal is created, the price of BTS has rised a lot.

so maybe a 20~30k  perday price is reasonable in current date?

I don't think I got enough knowledge and information to give such a suggestion, but I hope this can be a starting point for discussion.

@bitcrab 

What if the worker agrees to refund the portion of his worker each month to match the rate or close to the rate you are talking about, would that at all change the voting position in China?

I'm trying to determine if there is a solution to be created for the current worker proposal to continue. Is something like this sufficient?

[bitcrab]

in China Community discussion seems the main point for this worker proposal is:

the price is too high.

as:

1.the job is normal maintenance/update job.
2.comparing to the date this proposal is created, the price of BTS has rised a lot.

so maybe a 20~30k  perday price is reasonable in current date?

I don't think I got enough knowledge and information to give such a suggestion, but I hope this can be a starting point for discussion.

[pc]

Thanks for the detailed report!

I think we're getting good value for the money here.

[xeroc]

Like ByteMaster, I think the most critical worker to keep on the payroll is SVK, since he's maintaining the front-facing interface and getting a GUI right takes a lot of time.

The worker has a remaining balance of 760K BTS, part of which will be paid to Abit for work he's performed (he has requested to be paid in BTS), and the remaining held in the vesting balance for possible "emergency" work that needs to be done before the worker can be voted in again.

[emailtooaj]

March just ended, so I figured it was a good time to put together this report. This worker just got voted out, so if you think this was useful work and you're not currently voting for this worker, you should consider doing so. No one should panic, IMO, about this, however. While I think the work being done here was important, I'm sure the chain is stable enough to survive "as-is". Like ByteMaster, I think the most critical worker to keep on the payroll is SVK, since he's maintaining the front-facing interface and getting a GUI right takes a lot of time.

I've never really weighed in on most worker proposals, but I personally have always favored the relatively low-cost "maintenance/update/docs/support" workers versus the higher-dollar higher-risk "new feature" proposals. The FBA idea is a great way that such high-risk new features can be paid for, so the chain has that option for major innovations, without risking the funds of those who don't like a particular idea and without creating the conflict that can divide our community. Unfortunately, it seems that even the maintenance worker charges are big enough to be a problem, and I think this ultimately stems from a difference in global salary ranges and thus is hard to overcome. I do want to say that I don't feel any animosity towards those voting against the workers: I understand their position and have even agreed with some of their arguments, although I think voting against all worker proposals is short-sighted.

Ok, personal views/insights aside, on to the report, beginning with pay distribution, since this is the issue that seems to be of the most concern. I've made two draws from the vesting balance over the past 7 weeks since the worker began. Since we're primarily paying contractors in USD, I value it in USD on that day.

03/05/16 1450K BTS (estimated $6172 USD on that day)
03/18/16 772.5K BTS (estimated $4275 USD on that day)
Total USD value: $10447

The worker has a remaining balance of 760K BTS, part of which will be paid to Abit for work he's performed (he has requested to be paid in BTS), and the remaining held in the vesting balance for possible "emergency" work that needs to be done before the worker can be voted in again.

I've divided the payment into 2 periods: the last 3 weeks of February, when the worker began, and March.

Contractor            Feb (3wks)          March
------------------------------------------------------------------------
Cryptonomex       3750 USD           5000 USD (nearly fulltime for Theoretical + some time from Valentine and Michael)
SynaptiCAD            700 USD           1000 USD (Dan and Eric)
Abit                                                     250K BTS (plus another 250K BTS payment which I will be holding contingent on inclusion of a tested version of the rate-limited free trx code)

Here's a list of work that's been done during these periods, on a "per-release" basis. Note that the version numbers can be used to determine the periods during which the work was included in the release (e.g. release 2.0.160223 was completed on 02/23/2016 for example).

Released in 2.0.160216

- Implement new market API #503
- Add a cryptography API #500
- Handle exception in open() by re-indexing #492
- Don't update bitasset_data_object force_settled_volume every block unless needed #540
- Cap auto-cancel fees at deferred_fee #549
- Fix integer overflow bug in unit test framework when waiting for zero blocks #559
- Fix for #557: check BTC/PTS addresses on balance import including compressed/uncompressed versions
- Remove active_witnesses from global_property_object #562
- Saves change address in the wallet when transfering from blind to an account #564
- Fix #586 - decoding memo for sender in CLI wallet
- Take mia as reference, not copy, in clear_expired_orders(), maybe fix #485
- Expose whitelisted_accounts, fix #489
- Implement rough Python regular expression based reflection checker #562
- Fix withdraw_permission_object.hpp reflection #562
- Replace ordered_non_unique indexes with composite keys / ordered_unique, using object_id as tiebreaker.
- Reflect ID of force_settlement_object, fix #575
- Fix #492 - database corruption when closing
- Move account_options::validate() implementation from account_object.cpp #498
- Disable skip_validate #505
- Remove libraries/wallet/cache.cpp #510
- Give different object types their own individual header files #466
- Add break to every case in get_relevant_accounts #513
- Remove unused ancient implementation of operation_get_required_authorities #537
- Remove evaluation_observer #550
- Make some casts more explicit.
- Remove type_serializer, re-implement minimal functionality needed by cli_wallet #553
- Optionally disable database unity build #509
- Generate hardfork.hpp from hardfork.d directory #511
- Improve account_balance indexing #529
- Improve vote counting implementation #533
- Defer something-for-nothing culling for taker orders until the order is unmatched #555
- Make is_authorized_asset a free-floating method #566
- Log a lot of information if clear_expired_orders() is iterating too much, maybe useful to diagnose #485

Released in 2.0.160223

- Fix outdated price ticker in new market API #592
- Fix problems building from source on Windows and Mac

Released in 2.0.160316

- All annual members received a free upgrade to lifetime membership.  Discussion [here](https://bitsharestalk.org/index.php/topic,21846.0.html)
- Negative votes for workers were disabled.  Discussion [here](https://github.com/cryptonomex/graphene/issues/607)
- Improved account history with `get_relative_account_history` API call #477
- Fixes to new `get_ticker` market API call #592
- Implement debug_node #606
- Disable negative worker votes #607
- Minor code cleanup of voting code #611
- Deprecate annual memberships #613
- Fix incorrect condition for updating feeds which leads to object spam and excessive GUI bandwidth usage #615
- Optional websocket compression #619

Released in 2.0.160328

- Fix an incorrect asset ID returned by `cli_wallet` for non-BTS vesting balances #625
- Fix a bug causing multisig to (incorrectly) fail in some cases #631
- Restore p2p shutdown logic fix which was unintentionally excluded from the previous release #598 #637

Awesome report
Very professional and transparent!!

[dannotestein]

March just ended, so I figured it was a good time to put together this report. This worker just got voted out, so if you think this was useful work and you're not currently voting for this worker, you should consider doing so. No one should panic, IMO, about this, however. While I think the work being done here was important, I'm sure the chain is stable enough to survive "as-is". Like ByteMaster, I think the most critical worker to keep on the payroll is SVK, since he's maintaining the front-facing interface and getting a GUI right takes a lot of time.

I've never really weighed in on most worker proposals, but I personally have always favored the relatively low-cost "maintenance/update/docs/support" workers versus the higher-dollar higher-risk "new feature" proposals. The FBA idea is a great way that such high-risk new features can be paid for, so the chain has that option for major innovations, without risking the funds of those who don't like a particular idea and without creating the conflict that can divide our community. Unfortunately, it seems that even the maintenance worker charges are big enough to be a problem, and I think this ultimately stems from a difference in global salary ranges and thus is hard to overcome. I do want to say that I don't feel any animosity towards those voting against the workers: I understand their position and have even agreed with some of their arguments, although I think voting against all worker proposals is short-sighted.

Ok, personal views/insights aside, on to the report, beginning with pay distribution, since this is the issue that seems to be of the most concern. I've made two draws from the vesting balance over the past 7 weeks since the worker began. Since we're primarily paying contractors in USD, I value it in USD on that day.

03/05/16 1450K BTS (estimated $6172 USD on that day)
03/18/16 772.5K BTS (estimated $4275 USD on that day)
Total USD value: $10447

The worker has a remaining balance of 760K BTS, part of which will be paid to Abit for work he's performed (he has requested to be paid in BTS), and the remaining held in the vesting balance for possible "emergency" work that needs to be done before the worker can be voted in again.

I've divided the payment into 2 periods: the last 3 weeks of February, when the worker began, and March.

Contractor            Feb (3wks)          March
------------------------------------------------------------------------
Cryptonomex       3750 USD           5000 USD (nearly fulltime for Theoretical + some time from Valentine and Michael)
SynaptiCAD            700 USD           1000 USD (Dan and Eric)
Abit                                                     250K BTS (plus another 250K BTS payment which I will be holding contingent on inclusion of a tested version of the rate-limited free trx code)

Here's a list of work that's been done during these periods, on a "per-release" basis. Note that the version numbers can be used to determine the periods during which the work was included in the release (e.g. release 2.0.160223 was completed on 02/23/2016 for example).

Released in 2.0.160216

- Implement new market API #503
- Add a cryptography API #500
- Handle exception in open() by re-indexing #492
- Don't update bitasset_data_object force_settled_volume every block unless needed #540
- Cap auto-cancel fees at deferred_fee #549
- Fix integer overflow bug in unit test framework when waiting for zero blocks #559
- Fix for #557: check BTC/PTS addresses on balance import including compressed/uncompressed versions
- Remove active_witnesses from global_property_object #562
- Saves change address in the wallet when transfering from blind to an account #564
- Fix #586 - decoding memo for sender in CLI wallet
- Take mia as reference, not copy, in clear_expired_orders(), maybe fix #485
- Expose whitelisted_accounts, fix #489
- Implement rough Python regular expression based reflection checker #562
- Fix withdraw_permission_object.hpp reflection #562
- Replace ordered_non_unique indexes with composite keys / ordered_unique, using object_id as tiebreaker.
- Reflect ID of force_settlement_object, fix #575
- Fix #492 - database corruption when closing
- Move account_options::validate() implementation from account_object.cpp #498
- Disable skip_validate #505
- Remove libraries/wallet/cache.cpp #510
- Give different object types their own individual header files #466
- Add break to every case in get_relevant_accounts #513
- Remove unused ancient implementation of operation_get_required_authorities #537
- Remove evaluation_observer #550
- Make some casts more explicit.
- Remove type_serializer, re-implement minimal functionality needed by cli_wallet #553
- Optionally disable database unity build #509
- Generate hardfork.hpp from hardfork.d directory #511
- Improve account_balance indexing #529
- Improve vote counting implementation #533
- Defer something-for-nothing culling for taker orders until the order is unmatched #555
- Make is_authorized_asset a free-floating method #566
- Log a lot of information if clear_expired_orders() is iterating too much, maybe useful to diagnose #485

Released in 2.0.160223

- Fix outdated price ticker in new market API #592
- Fix problems building from source on Windows and Mac

Released in 2.0.160316

- All annual members received a free upgrade to lifetime membership.  Discussion [here](https://bitsharestalk.org/index.php/topic,21846.0.html)
- Negative votes for workers were disabled.  Discussion [here](https://github.com/cryptonomex/graphene/issues/607)
- Improved account history with `get_relative_account_history` API call #477
- Fixes to new `get_ticker` market API call #592
- Implement debug_node #606
- Disable negative worker votes #607
- Minor code cleanup of voting code #611
- Deprecate annual memberships #613
- Fix incorrect condition for updating feeds which leads to object spam and excessive GUI bandwidth usage #615
- Optional websocket compression #619

Released in 2.0.160328

- Fix an incorrect asset ID returned by `cli_wallet` for non-BTS vesting balances #625
- Fix a bug causing multisig to (incorrectly) fail in some cases #631
- Restore p2p shutdown logic fix which was unintentionally excluded from the previous release #598 #637

[dannotestein]

I think it's a good time to summarize when a new release is out (which means some maintenance work has been done).

I'm making payouts at end of the month (next week), so planning to summarize work at that time.

[abit]

I think it's a good time to summarize when a new release is out (which means some maintenance work has been done).

[dannotestein]

I think I should ask for 2 weeks' payment due to the rate limited free transaction feature https://github.com/cryptonomex/graphene/issues/603

I'll review the work today and get back to you.

[abit]

I think I should ask for 2 weeks' payment due to the rate limited free transaction feature https://github.com/cryptonomex/graphene/issues/603

[abit]

Please help publish win binaries for release of 2.0.160223. Thanks 

It's up, thanks for the notification.

Thanks a lot!

[santaclause102]

It's been suggested that we should report what issues we plan to work on, but this really isn't a simple thing to do reliably. Priorities of issues rapidly change as well as available people to work on them. It's much easier and more reasonable, IMO, to report what was done and what was charged.

I agree. Setting up and publishing an official schedule and keeping it up to date is unnecessary overhead that I wouldn't want to pay for. Regular reports of work done and how the payment was allocated to different tasks/workers is sufficient.

I think a weekly overview would make sense because it would:
... provide accountability
... be positive for the public and shareholder perception of the worker system and this specific worker

Has there been such documentation in the past? ...I think that would make sense for any worker.

Well, our github workflow makes it possible to see what's planned and some idea of who is doing what, although these things never tell the whole story, since few document systems relying on manual entry manage to track reality perfectly. That will be especially true whenever some release needs to get rushed out for a high priority issue. But, FWIW, on the blockchain side of things, this is probably the best documentation of current and near term planned work:

https://github.com/cryptonomex/graphene/milestones/NextRelease

Thanks