Author Topic: [Worker Proposal] Blockchain maintenance developer  (Read 7945 times)

0 Members and 1 Guest are viewing this topic.

Offline Stan

  • Hero Member
  • *****
  • Posts: 2873
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BitShares: Stan
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #75 on: February 23, 2016, 05:59:36 pm »

This means that your team should actively help Theo on fixing and closing issues, not just pay him extra. I assume that Theo, being a CNX's dev, is already paid for his work.

I would like to see you/your team really making commits and fixing issues. This is what the shareholders expect from this worker IMO.

This assumption was already negatived in previous statements. We are a DAC and our only working manpower is what comes through the Workers.. the expectation of free labourers from CNX is not a reasonable assumption.

Negatived? You mean rejected?

Doesn't matter if you guys keep saying CNX shouldn't be expected to work on Graphene "for free", I certainly feel they should as it's in their interest (and I'm even a founding member and stock holder), and I'm pretty sure most people around here also think they should.

Sorry I meant negated... just woke up after only a few hrs sleep :)  Corrected.

In regards to free work.. where exactly should the funds come from then for them to work 'for free' if this is the case. I like to understand how their business model for man-hours should be paid then. What are the more ideal solutions that can work better?

I explained why I think they should work on Graphene above. You have to remember this isn't BTS only, it's Graphene, CNX's flagship and currently only product.

The answer is "yes" and "no".

Yes, CNX will, of course, work on Graphene -- when it is the best use of our shareholders' resources.
Just like other businesses may build certain BitShares infrastructure that they need to succeed.
That leaves lots of other things the the Business Known As BitShares can and should be responsible for.

Teenagers are well known for their desire for independence without responsibility.

BitShares is an emancipated adult and must take the responsibility that comes with the independence its shareholders crave.





Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline bytemaster

Re: [Worker Proposal] Blockchain maintenance developer
« Reply #76 on: February 23, 2016, 10:04:05 pm »
CNX is working on blockchain technology and prioritizing its limited resources on activities we think will generate the most revenue in the shortest period of time.

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2487
    • View Profile
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #77 on: February 23, 2016, 10:47:31 pm »
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. 

Offline dannotestein

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 735
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #78 on: February 23, 2016, 11:23:21 pm »
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
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 3302
    • View Profile
    • Steemit Blog
  • BitShares: abit
  • GitHub: abitmore
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #79 on: February 24, 2016, 11:16:18 pm »
Please help publish win binaries for release of 2.0.160223. Thanks  :)
BTS account: abit
BTS committee member: abit
BTS witness: in.abit

Offline dannotestein

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 735
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #80 on: February 25, 2016, 07:14:12 pm »
Please help publish win binaries for release of 2.0.160223. Thanks  :)
It's up, thanks for the notification.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2487
    • View Profile
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #81 on: February 25, 2016, 07:47:05 pm »
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

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 3302
    • View Profile
    • Steemit Blog
  • BitShares: abit
  • GitHub: abitmore
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #82 on: February 26, 2016, 08:44:27 am »
Please help publish win binaries for release of 2.0.160223. Thanks  :)
It's up, thanks for the notification.
Thanks a lot!
BTS account: abit
BTS committee member: abit
BTS witness: in.abit

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 3302
    • View Profile
    • Steemit Blog
  • BitShares: abit
  • GitHub: abitmore
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #83 on: March 03, 2016, 04:40:31 pm »
I think I should ask for 2 weeks' payment due to the rate limited free transaction feature https://github.com/cryptonomex/graphene/issues/603
BTS account: abit
BTS committee member: abit
BTS witness: in.abit

Offline dannotestein

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 735
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #84 on: March 03, 2016, 06:36:27 pm »
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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 3302
    • View Profile
    • Steemit Blog
  • BitShares: abit
  • GitHub: abitmore
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #85 on: March 24, 2016, 10:53:08 pm »
I think it's a good time to summarize when a new release is out (which means some maintenance work has been done).
BTS account: abit
BTS committee member: abit
BTS witness: in.abit

Offline dannotestein

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 735
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #86 on: March 24, 2016, 11:32:38 pm »
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.
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline dannotestein

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 735
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #87 on: April 02, 2016, 08:07:51 pm »
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




http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline emailtooaj

Re: [Worker Proposal] Blockchain maintenance developer
« Reply #88 on: April 02, 2016, 09:41:27 pm »
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 +5%
Very professional and transparent!!
Sound Editor of Beyondbitcoin Hangouts. Listen to latest here - https://beyondbitcoin.org support the Hangouts! BTS Tri-Fold Brochure https://bitsharestalk.org/index.php/topic,15169.0.html
Tip BROWNIE.PTS to EMAILTOOAJ

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12636
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Re: [Worker Proposal] Blockchain maintenance developer
« Reply #89 on: April 03, 2016, 09:53:52 am »
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.

+5%

Quote
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.

+5% +5%
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH