BitShares Forum
Main => Stakeholder Proposals => Topic started by: dannotestein on February 02, 2016, 07:37:02 pm
-
I believe we need a worker proposal to fix many of the small problems discovered in the blockchain protocol and code base. These problems are generally too small to require individual proposals that must then be voted in by shareholders. There's too much overhead, the issues aren't easily explainable to voters, and there's too much delay in such a system to effectively address small tasks. Note that we already have similar proposals voted in for the GUI coding and web development (SVK, Cass, etc).
BlockTrades is soliciting feedback on this idea before making a formal proposal on the BitShares network.
We're thinking of proposing to do this at a rate of 60000 bts/day.
The work would be done by Eric, myself, plus other subcontractors as necessary (e.g. Cryptonomex or SynaptiCAD employees). We would make a report once per month on what has been done during that period.
-
60k bts per day is 2x the amount I am asking for to fund 20h/week of work (though I am doing way more but I need to deal with that)
That said, I think it is a fair price considering your have high-profile devs working on it and we can need every single working hand on the graphene backend!
I would support this if you could elaborate a little more how much time you are willing to put into graphene
These are two reference proposals:
https://github.com/xeroc/worker-proposals
https://github.com/cassiopaia/worker-proposals-bts
-
I would support this if you could elaborate a little more how much time you are willing to put into graphene
I'm hoping we can manage to keep the work to an average of 20 man hours/week, but I suspect it will sometimes go above that depending on what needs to be done.
-
Yeah, "high" but fair price.. it's important low-level work and Dan N & team are very well fit to do it. Could you list some examples of the big and small issues you'd focus on? Would this be purely maintenance work or will you be adding/improving features?
-
I have some questions, who can tell me?
1. we pay workers for USD, do you have different budget when the price changed?
do you still dilution 10K USD per month for every worker even the price down to 0.0001 USD/BTS? that's 100M BTS/month.
2. what's the plan after all 3.7 billion have dilluted?
3. workers ask for a fair payment, should all others ask too? of course not everybody's worker will success, then their choise is leave BTS, do nothing for BTS if they can't get the payment. so here we are, we do everything only for money. I have no interesting for such a community.
dilution until the market cap to 0, go on.
I support you developer's work, but I will against all dilution workesrs at such price, to protect my BTS not go to zero.
please set "baozi" as your proxy if you against dilution.
-
haha，bitshares is a charity founded by the poor shareholder who keep dulition themselves until all bankrupt just to feed some “ever un-application ”developer. :)
-
That is a reasonable price for Bitshares to remain competitive.
Too bad there weren't any Chinese devs willing to step up to bat ? What are the issues?
This is all a side effect of closing the source code off, getting away from any talk of a 'toolkit', etc. Hiring any developer now will require a learning curve, so the ~$70 an hour is likely a good deal ...
I see some guys seeming to get pissed off. I wouldn't let pride or jealousy force your decisions.
PS BitShares is always good for entertainment.
-
I have some questions, who can tell me?
1. we pay workers for USD, do you have different budget when the price changed?
do you still dilution 10K USD per month for every worker even the price down to 0.0001 USD/BTS? that's 100M BTS/month.
2. what's the plan after all 3.7 billion have dilluted?
3. workers ask for a fair payment, should all others ask too? of course not everybody's worker will success, then their choise is leave BTS, do nothing for BTS if they can't get the payment. so here we are, we do everything only for money. I have no interesting for such a community.
dilution until the market cap to 0, go on.
I support you developer's work, but I will against all dilution workesrs at such price, to protect my BTS not go to zero.
please set "baozi" as your proxy if you against dilution.
+5% +5% +5%
-
haha，bitshares is a charity founded by the poor shareholder who keep dulition themselves until all bankrupt just to feed some “ever un-application ”developer. :)
Let's assume you and I have set up a company: you have 50% of shares and I have 50% of shares so we participate in the company's profits on an equal footing.
- You work several hours a day to expand the company, build a better product and acquire more customers.
- I do nothing, just sit and watch you doing the work. Occasionally I might comment on something and offer my advice.
Do you really think it's a fair deal for you?
If so, I'd like to set up a company with you.
-
Do you really think it's a fair deal for you?
If so, I'd like to set up a company with you.
I am in as well .. I can even dedicate a distinct mail address for the partnership: noreply@bitshares.eu
-
I have some questions, who can tell me?
1. we pay workers for USD, do you have different budget when the price changed?
do you still dilution 10K USD per month for every worker even the price down to 0.0001 USD/BTS? that's 100M BTS/month.
2. what's the plan after all 3.7 billion have dilluted?
3. workers ask for a fair payment, should all others ask too? of course not everybody's worker will success, then their choise is leave BTS, do nothing for BTS if they can't get the payment. so here we are, we do everything only for money. I have no interesting for such a community.
dilution until the market cap to 0, go on.
I support you developer's work, but I will against all dilution workesrs at such price, to protect my BTS not go to zero.
please set "baozi" as your proxy if you against dilution.
Dilution is nothing bad if it serves a good purpose.
In our case the purpose is this: to transfer some value from shareholders who do nothing to shareholders who do something useful for the company.
This way the company grows and each share rises in value, which should (if the work is truly useful) easily offset its drop in value due to dilution.
What you propose, alt, is stagnation, waiting for some kind of miracle that would make the world realize how valuable BitShares is.
Or you count on people working for you for free. Which is equally delusional.
-
many people are doing their job to make BTS more valuable
transwiser, blocktrade, metaexchange, ccedk.... maybe dacx
they build business for BTS, they don't need dilution,
we should wait for these business development, we need more business, more users.
do you play game starcraft?
we spent too much energy to upgrade our technolgy , but we don't produce solders, we don't open new miners,
we'll upgrade technology until we spent our last cent.
-
many people are doing their job to make BTS more valuable
transwiser, blocktrade, metaexchange, ccedk.... maybe dacx
they build business for BTS, they don't need dilution,
we should wait for these business development, we need more business, more users.
do you play game starcraft?
we spent too much energy to upgrade our technolgy , but we don't produce solders, we don't open new miners,
we'll upgrade technology until we spent our last cent.
So .. how do you think I can make money out of giving everyone support and writing documentation as well as the python library and others?
If you want me to ask fo $5 per answered support issue I'll gladly take it instead of running a worker.
For me, a worker is essential to keep my work here going. If it wasn't for those funds, I would need to get a regular job, which is certainly not a problem, and I would get payed WAY MORE money than it get here. If coming back and I will have to spend 40h+ at that job. The consequence is that I cannot contribute anymore to this community but only do paid jobs for businesses to profit and not for BitShares to profit from.
-
xeroc, I appreciate your work, you give me the most help.
I'll be glad to approve to pay you from the committee's balance.
but not from dilution. I have said, dilution 1 USD, share holders lost 10 USD.
you are the important person as I know, because your work support the business.
at the same time, I am worriy about we don't have enough money to pay for you,
so I'm glad to request a parttime job, I wish you can earn more money from other rich company.
another way is I wish promise pay you with the future income, if you are not lack of money for basic life now.
-
That is a reasonable price for Bitshares to remain competitive.
Too bad there weren't any Chinese devs willing to step up to bat ? What are the issues?
This is all a side effect of closing the source code off, getting away from any talk of a 'toolkit', etc. Hiring any developer now will require a learning curve, so the ~$70 an hour is likely a good deal ...
I see some guys seeming to get pissed off. I wouldn't let pride or jealousy force your decisions.
PS BitShares is always good for entertainment.
I'm a Chinese developer. I've been doing some maintenance work for a while.. I do want to get paid as well..
-
another way is I wish promise pay you with the future income, if you are not lack of money for basic life now.
BTS paid from the reserve pool IS the future income indeed. All fees go to the reserve pool currently.
If we can gain 400K BTS per day from fees, there won't be "dilution".
On contrast, balance on committee-account is "operating capital", not income.
-
another way is I wish promise pay you with the future income, if you are not lack of money for basic life now.
BTS paid from the reserve pool IS the future income indeed. All fees go to the reserve pool currently.
I say pay from the future income means in the future,when the network earned a cent, we can pay a cent.
-
If we look at the total number of BTS in the pool, in circulation, in reserve accounts, etc. there is no dilution. All that can happen is shifting BTS from one bucket to another. It would be best to value your BTS taking all in existence into consideration. Once the reserve pool runs out then we're really in a pickle. So the goal has to be burn the funds we have to make the product profitable enough to rebuild the pool.
The talk of dilution only has meaning when the reserve pool isn't considered. Am I wrong in that no BTS is every created or destroyed only accessible or not?
Assuming this is all correct then what danotestein is asking for (~$200/day at current prices for three+ resources) is a good deal.
-
The talk of dilution only has meaning when the reserve pool isn't considered. Am I wrong in that no BTS is every created or destroyed only accessible or not?
Correct .. kind of:
- If you take the reserves into the "available supply", then there is no "dilution"
- If you do not take it into "available supply", then there is dilution
We could have another setup namely those that feel ok with it can ask for a USD/€ amount instead of BTS. The worker itself is owned by a multisig account (potentially committee, but possibly also someone else). Hence the "dilution" is payed into a multisig account that has promised to pay $/€ to the real "worker" (e.g. me or dannotestein). Now, the interesting part would be, if you ask for a vesting period of say 4 months, then the multisig account can maybe buy bitUSD/bitEUR cheaper in the those 4 months and have a "reserver" from what has been payed out by the network.. those funds could be burned or used to provide liquidity (which they are anyway if they want to buy bitUSD)
@alt .. how about that?
@dannotestein would you be ok with a deal like that since it bears the "risk" of getting less out of the worker than what you asked for if BTS goes even lower.
Ask for me, I can think of doing it that way ..
Assuming this is all correct then what danotestein is asking for (~$200/day at current prices for three+ resources) is a good deal.
Agreed.
-
xeroc, I appreciate your work, you give me the most help.
I'll be glad to approve to pay you from the committee's balance.
but not from dilution. I have said, dilution 1 USD, share holders lost 10 USD.
you are the important person as I know, because your work support the business.
at the same time, I am worriy about we don't have enough money to pay for you,
so I'm glad to request a parttime job, I wish you can earn more money from other rich company.
another way is I wish promise pay you with the future income, if you are not lack of money for basic life now.
Thanks for the kind words .. I do understand the issue we are having here .. please take a look at the above proposal. It is of interest to me since I need to renew my worker rather soonish
-
Here I quoted some discussions on Telegram channels which happened yesterday:
(someone) EMERGENCY FIX! ALL WITNESSES PLEASE UPGRADE TO LATEST bitshares BRANCH ASAP!
(witness1) building now
(witness2) Building
(witness3) Building
(witness4) I'll be building in a few minutes
(witness5) building
...
...
...
(someone)
GUYS
so sorry... BM just told me that this is a false alarm..
(someone)
the one liner change is .... i am not sure if the witnesses understand the code involved since they are not a dev. nevertheless, it is important to verify before broadcasting to the rest which may cause an unnecessary alarm.
(Dan Notestein)
in this case, Eric and I took a look at the line in question and realized it didn't do anything, then contacted BM (the author) to see if he agreed (it didn't do anything cause the same check was already included about 10 lines up). He agreed and the update was cancelled.
So there is review of the changes, but it should have had more review before such a hard fork announcement was made, IMO.
-
I'm fine with the worker pay being denominated in BTS rather than a usd/euro equivalent. If we see a significant appreciation in the value of BTS, we can increase the amount of work we do (and I think BTS is near its low side now). It's relatively easy for BlockTrades to convert pay to different forms as required by different contractors.
We'll put together a list of some of the problems we would address near term, but one of the ones that stood out for me was the high data spamming across the websocket that was stressing mobile web browsers.
-
I would support this proposal.
-
We'll put together a list of some of the problems we would address near term, but one of the ones that stood out for me was the high data spamming across the websocket that was stressing mobile web browsers.
Great.
-
Theo and I were discussing what kinds of issues we think should be tackled by this worker proposal based on the current github issues, and we came up with these general categories:
- minor bugfixes
- performance issues (websocket spaming is a high priority one, as this can seriously affect mobile web browsers)
- more unit tests (many are pending as issues in github now). Both of the last two network halts could have been potentially averted by more unit tests.
- Code cleanup (poor coding techniques, inconsistent coding methods, naming conventions, etc)
- BlockChain-level documentation
- cli_wallet maintenance (there's several issues related to the current API caching used by the cli wallet)
- minor features
-
I would support this proposal.
-
This is nice, DAC is working !
-
This looks like a Keynesian model that is implemented nicely and fairly. Like building highways for everybody's benefit. Money comes from the reserves, its not like those sneaky IOU cryptos or UIAs penetrate into the system, imo those are the dilution.
-
I've sent the official proposal to the blockchain. It can be found in the wallet under "Voting" in the Workers tab as "Blockchain maintenance developer". As a side note, as I just found this out: you need to press either Approve or Reject, and THEN you must press Publish Changes button at top of screen. I've suggested a change to this interface since it deeply confused me.
-
I've sent the official proposal to the blockchain. It can be found in the wallet under "Voting" in the Workers tab as "Blockchain maintenance developer". As a side note, as I just found this out: you need to press either Approve or Reject, and THEN you must press Publish Changes button at top of screen. I've suggested a change to this interface since it deeply confused me.
This https://github.com/cryptonomex/graphene-ui/issues/718? I've added some comments there.
Basically you're asking for $200 per day with weekends/holidays included. What's your hourly rate? Will you make daily/weekly work reports? The biggest obstacle here is how to validate/value your work.
Imo you're a bit too optimistic about the worker.. Take it seriously. Politics matters. If bytemaster voted for your worker with no reason, will make a big trouble with Chinese community. If bytermaster doesn't vote, your worker is hard to be approved. Better do something first and apply for the worker later. Just my 2 cents.
-
I've sent the official proposal to the blockchain. It can be found in the wallet under "Voting" in the Workers tab as "Blockchain maintenance developer". As a side note, as I just found this out: you need to press either Approve or Reject, and THEN you must press Publish Changes button at top of screen. I've suggested a change to this interface since it deeply confused me.
This https://github.com/cryptonomex/graphene-ui/issues/718? I've added some comments there.
Basically you're asking for $200 per day with weekends/holidays included. What's your hourly rate? Will you make daily/weekly work reports? The biggest obstacle here is how to validate/value your work.
As indicated previously, we would make monthly reports. Daily reports would just be insane, IMO. If someone wants to monitor more closely, they can always look to github commits, but I don't expect daily commits to github for many tasks (e.g. I expect the bandwidth consumption issue to take more than a day to solve). Also, a side point, since you mentioned weekends, for the past few years Eric and I both work partial days on weekends too (usually 2-7pm). It' a nice time to work, as there are fewer outside interruptions.
Imo you're a bit too optimistic about the worker.. Take it seriously. Politics matters. If bytemaster voted for your worker with no reason, will make a big trouble with Chinese community. If bytemaster doesn't vote, your worker is hard to be approved. Better do something first and apply for the worker later. Just my 2 cents.
I'm expecting BM to vote in favor of the proposal, but certainly not for "no reason". He's well aware of what we can do since we've worked with him since before BitShares even existed. And these rates are far below what we charged him (and the company he worked for prior to bitshares project) for past work, so he knows what a bargain it is.
Truthfully, I don't even to expect to clear any real direct profit from this worker, given the anticipated expenses in man hours and salary rates. The biggest benefit to BlockTrades will be gaining familiarity with new parts of the code base and having a better blockchain to build our businesses on.
-
I feel the current auti-dilution emotion in China community mainly come from:
1. BTS's price keeps in low level for long time.
2. no exciting news that convince shareholders/users that BTS have a good future.
even so, I don't agree to reject all the worker proposals, from my own opinion, I still would like to support the worker proposals with high priority demand, efficient work and fair price, on the other hand, I will keep neutral to or even reject the worker proposals with low priority demand, inefficient work or overrated price.
a little more constrictive financial policy is suitable to such a tough time?
-
I feel the current auti-dilution emotion in China community mainly come from:
1. BTS's price keeps in low level for long time.
2. no exciting news that convince shareholders/users that BTS have a good future.
even so, I don't agree to reject all the worker proposals, from my own opinion, I still would like to support the worker proposals with high priority demand, efficient work and fair price, on the other hand, I will keep neutral to or even reject the worker proposals with low priority demand, inefficient work or overrated price.
a little more constrictive financial policy is suitable to such a tough time?
In this case, I think the solution is simple. Vote for us, and see how we perform in 2-4 week time frame. If you don't like the results, remove your vote. One of the nice things about the worker system from the coin holder's point of view is it's very easy to "fire" a worker, without having to worry about any of the headaches that it causes for a normal business.
This "trial" approach might not work for large tasks, but it makes plenty of sense for a worker that is making small independent changes to the code base.
-
@dannotestein what do you think about this idea: https://bitsharestalk.org/index.php?topic=19625.0
If you become a developer employed by community, would you stream your work? It would be additional promotion and knowledge sharing :) For sure I would watch it!
-
I've sent the official proposal to the blockchain. It can be found in the wallet under "Voting" in the Workers tab as "Blockchain maintenance developer".
For CLI users: 1.14.30
-
@dannotestein what do you think about this idea: https://bitsharestalk.org/index.php?topic=19625.0
If you become a developer employed by community, would you stream your work? It would be additional promotion and knowledge sharing :) For sure I would watch it!
I'm heading to my parents today, but I'll take a look at the livestreaming in more depth when I get back tonight and see if it's something I can work with. One thing that I should make clear is that this worker isn't just really "me" (I'd be a mix of a manager who distributes and monitors work and a coder), so the livestreaming choice would be up to each individual (I'm certainly not comfortable to try to mandate anything like that).
-
Slave developers imprisoned by the blockchain, working as slaves under 24/7 video surveillance by remote share holders willing to fire them a moment's notice. Hrrrmmmm. I like.
-
Slave developers imprisoned by the blockchain, working as slaves under 24/7 video surveillance by remote share holders willing to fire them a moment's notice. Hrrrmmmm. I like.
It should not work like that :P Everyone working on bitshares are doing awesome job. It great to show other people that we are passionate about it. I streamed on livecoding 22:15 hrs of my work and I know, that is not the end. I have also learn a lot watching what other people are doing :)
-
-5% -5% -5%
-
how many works you do per day？？？？？
-
You're voted in now, but still no future plan or what have you done from the beginning date.
If you provide weekly or bi-weekly updates, you will get more support from the community.
-
You're voted in now, but still no future plan or what have you done from the beginning date.
If you provide weekly or bi-weekly updates, you will get more support from the community.
Our future plan is pretty much what I posted at the head of this thread, just to look thru open issues related to blockchain/server code and take then on based on signficance, repeatability, etc. I've been planning to do bi-weekly updates on what we've done, at least at the beginning. I'll file our first report this week, but I need to accumulate the work done from all involved, which isn't easy to do yet since we're snowed in here and it's better/faster to do it face-to-face.
Eric and I were only able to solve one issue so far (it took about 8 man hours), as we've been tied up with other tasks, and I've spent another hour or so looking at github issues, discussing potential solutions, and assigning them based on priority. Theo's done the most work so far, but I still need to get his status report. Once I've accumulated total hours spent by each party, I'll allocate funds accordingly. If it turns out that we don't devote enough hours on any given month, I'll just send the extra funds back to the reserve account for that month. This will give us flexibility to spend time on serious issues when we need to, and work on our own stuff when there's no pressing problems (or when we've got pressing work of our own).
-
What was the issue you guys solved?
-
What was the issue you guys solved?
https://github.com/cryptonomex/graphene/issues/251
We took on this one to get started in the code base as it was an easily repeatable one and it was a good match for our skill set.
-
Also note that dan & co do the windows release builds.
-
Also note that dan & co do the windows release builds.
Ah I guessed it was Nathan doing it.
But who is co?
-
What was the issue you guys solved?
https://github.com/cryptonomex/graphene/issues/251
We took on this one to get started in the code base as it was an easily repeatable one and it was a good match for our skill set.
Not too bad so far.
Hope you'll have more progress on the API server spamming issue, which I remember you've said earlier and is more important.
By the way, as @theoretical mentioned, please don't close a ticket if it's not merged into the code base of next release, otherwise it may get forgotten easily.
-
Also note that dan & co do the windows release builds.
Extremely interesting logic. I would have used that as an argument for them to not be payed actually. Why?
There seem to be just a single person around here who NEEDS the win build(1) (as opposed to the rest that just build those themselves). When on a 3 page thread, for more than a week this person was asking for help, they did not come up with a single comment(2)...
-
what is you github account ?
-
what is you github account ?
I happened to know.. it's a team. Members are dnotestein, emfrias, and maybe 2 more people.
-
Also note that dan & co do the windows release builds.
Extremely interesting logic. I would have used that as an argument for them to not be payed actually. Why?
There seem to be just a single person around here who NEEDS the win build(1) (as opposed to the rest that just build those themselves). When on a 3 page thread, for more than a week this person was asking for help, they did not come up with a single comment(2)...
AFAIK the most important player who needs "official" win builds is BTC38.
-
Also note that dan & co do the windows release builds.
Extremely interesting logic. I would have used that as an argument for them to not be payed actually. Why?
There seem to be just a single person around here who NEEDS the win build(1) (as opposed to the rest that just build those themselves). When on a 3 page thread, for more than a week this person was asking for help, they did not come up with a single comment(2)...
AFAIK the most important player who needs "official" win builds is BTC38.
Really? BTC38 runs on win?
PS
well at least this explains on several levels their slooow transition to BTS2.0
-
Also note that dan & co do the windows release builds.
Extremely interesting logic. I would have used that as an argument for them to not be payed actually. Why?
There seem to be just a single person around here who NEEDS the win build(1) (as opposed to the rest that just build those themselves). When on a 3 page thread, for more than a week this person was asking for help, they did not come up with a single comment(2)...
AFAIK the most important player who needs "official" win builds is BTC38.
Really? BTC38 runs on win?
PS
well at least this explains on several levels their slooow transition to BTS2.0
Yes, they run on win. And they don't build from source by themselves, nor trust binaries provided by others but the "official" one.
@dannotestein so when will you upload the Windows binaries of latest release (2.0.160216)? Thanks.
-
Also note that dan & co do the windows release builds.
Extremely interesting logic. I would have used that as an argument for them to not be payed actually. Why?
There seem to be just a single person around here who NEEDS the win build(1) (as opposed to the rest that just build those themselves). When on a 3 page thread, for more than a week this person was asking for help, they did not come up with a single comment(2)...
AFAIK the most important player who needs "official" win builds is BTC38.
Really? BTC38 runs on win?
PS
well at least this explains on several levels their slooow transition to BTS2.0
Yes, they run on win. And they don't build from source by themselves, nor trust binaries provided by others but the "official" one.
@dannotestein so when will you upload the Windows binaries of latest release (2.0.160216)? Thanks.
It's up now, we just had to finish testing it.
-
so when will you upload the Windows binaries of latest release (2.0.160216)? Thanks.
It's up now, we just had to finish testing it.
Thanks. +5%
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
Great. I will vote for you when voting bug is fixed.
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
Great. I will vote for you when voting bug is fixed.
Should be fixed soon, that was under discussion today.
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?
Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?
Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..
No, Theo's not a part of BlockTrades. As I posted originally, the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well. BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?
Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..
No, Theo's not a part of BlockTrades. As I posted originally, the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well. BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.
Sure, but working on graphene is already his job and I assume he's being paid by CNX to do so, so it seems weird to me that you're claiming responsibility for stuff he would have done anyway.
The backlog of issues in the graphene repo is frustratingly long and I was hoping you would add some additional manpower to it because like you say theoretical does need help there. With the kind of worker pay you're asking I think we have a right to expect you to put serious resources into this.
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?
Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..
No, Theo's not a part of BlockTrades. As I posted originally, the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well. BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.
Sure, but working on graphene is already his job and I assume he's being paid by CNX to do so, so it seems weird to me that you're claiming responsibility for stuff he would have done anyway.
The backlog of issues in the graphene repo is frustratingly long and I was hoping you would add some additional manpower to it because like you say theoretical does need help there. With the kind of worker pay you're asking I think we have a right to expect you to put serious resources into this.
CNX pays Theo, and CNX has to get money from somewhere to pay him. You can't reasonably expect CNX to commit a programmer and a 1/2 to full time work on BitShares without any compensation (the 1/2 being limited support from other CNX folks such as BM/Valentine/etc). During this pay period, the larger portion will go to CNX and we'll take a much smaller proportion for the work we did. If the total charges from CNX and BT is less than the total paid during a pay period, I'll send it back to the reserve fund. BT didn't do a lot this period because higher priority things came up, but CNX did do a lot of work, so I think the full fee is justified. Next pay period, I hope it works out differently, but I can't say for sure yet.
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?
Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..
No, Theo's not a part of BlockTrades. As I posted originally, the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well. BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.
Sure, but working on graphene is already his job and I assume he's being paid by CNX to do so, so it seems weird to me that you're claiming responsibility for stuff he would have done anyway.
The backlog of issues in the graphene repo is frustratingly long and I was hoping you would add some additional manpower to it because like you say theoretical does need help there. With the kind of worker pay you're asking I think we have a right to expect you to put serious resources into this.
CNX pays Theo, and CNX has to get money from somewhere to pay him. You can't reasonably expect CNX to commit a programmer and a 1/2 to full time work on BitShares without any compensation (the 1/2 being limited support from other CNX folks such as BM/Valentine/etc). During this pay period, the larger portion will go to CNX and we'll take a much smaller proportion for the work we did. If the total charges from CNX and BT is less than the total paid during a pay period, I'll send it back to the reserve fund. BT didn't do a lot this period because higher priority things came up, but CNX did do a lot of work, so I think the full fee is justified. Next pay period, I hope it works out differently, but I can't say for sure yet.
Actually I would totally expect CNX to commit a developer to working on their main product, but apparently you and BM don't see it that way. It's their showpiece and their main product, to not work on it unless they're paid to do so is like Microsoft stopping development on Windows unless someone specifically pays them for it. It's very much in their interest to improve on Graphene, fix outstanding bugs and generally make it the best possible product they can.
-
Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586
So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?
Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..
No, Theo's not a part of BlockTrades. As I posted originally, the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well. BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.
Sure, but working on graphene is already his job and I assume he's being paid by CNX to do so, so it seems weird to me that you're claiming responsibility for stuff he would have done anyway.
The backlog of issues in the graphene repo is frustratingly long and I was hoping you would add some additional manpower to it because like you say theoretical does need help there. With the kind of worker pay you're asking I think we have a right to expect you to put serious resources into this.
CNX pays Theo, and CNX has to get money from somewhere to pay him. You can't reasonably expect CNX to commit a programmer and a 1/2 to full time work on BitShares without any compensation (the 1/2 being limited support from other CNX folks such as BM/Valentine/etc). During this pay period, the larger portion will go to CNX and we'll take a much smaller proportion for the work we did. If the total charges from CNX and BT is less than the total paid during a pay period, I'll send it back to the reserve fund. BT didn't do a lot this period because higher priority things came up, but CNX did do a lot of work, so I think the full fee is justified. Next pay period, I hope it works out differently, but I can't say for sure yet.
I don't think it's a good way if you created a worker and then distribute most of payment to CNX, especially when the worker is voted in mainly with CNX's stakes.
By the way, I'm checking the list you posted above. By now, I found that at least IMO 516 is in the scope of STEALTH feature so it should not be paid by this worker.
//Update:
If you just list the issues which have been fixed, and distribute payments to the contributors, you should not do it selectively. Anyone who has worked for the issues should get a cut, the work should not be limited to coding but also contains documentation, analysis, testing and etc.
//Update2:
With the report, can you give us a plan of next items you'll work on, and the priorities of them?
Can you please work on high priority jobs first? I'd rather like to see what progress you've made on the API server spamming issue https://github.com/cryptonomex/graphene/issues/540 , which is one of the most important reasons why people voted for you. If you've found that you're unable to fix it, please tell us rather sooner than later, so others will probably spend more time/efforts on it.
-
Theo and I were discussing what kinds of issues we think should be tackled by this worker proposal based on the current github issues, and we came up with these general categories:
- minor bugfixes
- performance issues (websocket spaming is a high priority one, as this can seriously affect mobile web browsers)
- more unit tests (many are pending as issues in github now). Both of the last two network halts could have been potentially averted by more unit tests.
- Code cleanup (poor coding techniques, inconsistent coding methods, naming conventions, etc)
- BlockChain-level documentation
- cli_wallet maintenance (there's several issues related to the current API caching used by the cli wallet)
- minor features
IMO it's best if quoted text can be put into OP.
-
No, Theo's not a part of BlockTrades. As I posted originally, the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well.
So basically we are paying CNX to fix their stuff
BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.
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 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 negated 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.
-
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.
-
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?
-
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.
-
Only product that you are aware off.
-
To inject some actual numbers into this discussion, for the work reported above, this worker has been paid ~$3250 USD in BTS. Of that, BlockTrades plans to charge $700 for the work we've done (this includes more than just the time we spent on the windows build and issue 251, as we've had to spend time learning and discussing ways to improve the current workflow). Given the work that CNX did during this period, I think it's quite reasonable for them to charge $2550. SVK's feelings aside, I don't think we're likely to see CNX doing development work for free. The best I think we can hope for is that they give us a discounted rate, which I think this represents.
I certainly plan to increase the amount of time we can devote to this worker, but I know our next week is booked with updating our web site for our public offering, so I plan to make no charges during that time for BT. The one exception to that is if we wind up working on this issue: https://github.com/cryptonomex/graphene/issues/591.
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'll evaluate what is done by CNX and us over the next period, then distribute accordingly, including returning funds if less was done than the worker provides for.
However, it is important that programmers know what issues other programmers are working on to avoid work duplication. For programmers, the answer for this is addressed in a new document I wrote recently to describe our updated workflow plans:
https://github.com/cryptonomex/graphene/wiki/Graphene-GitHub-Guidelines
To answer abit's question, we did not have a chance to look at the "mobile spam" issue yet. From preliminary discussions with Theo and BM, we understand the nature of the problem, and the most likely solution will be one of examining the flow of data and coming up with some heuristics to reduce the flow. In other words, there's no simple "clean" solution. We're still planning to address this issue when we have a chance, but if you want to take a crack at it, assign it to yourself. If you can make a significant reduction, report it to us and we can work out some way to pay you for the work.
-
Only product that you are aware off.
I was about to say the same. :) ... We have already been told about things like Plasma.. but there are other things they could be working on or focused on now that they are no longer welcome here if the forum remarks are any barometer on that matter. Sad really.
-
To inject some actual numbers into this discussion, for the work reported above, this worker has been paid ~$3250 USD in BTS. Of that, BlockTrades plans to charge $700 for the work we've done [...]. Given the work that CNX did during this period, I think it's quite reasonable for them to charge $2550.
Thanks. I think this kind of information is important, and these numbers look absolutely reasonable to me. It would be nice to see such a breakdown at the end of each month.
I don't think we're likely to see CNX doing development work for free. The best I think we can hope for is that they give us a discounted rate, which I think this represents.
+1
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.
-
Dannotestein
"We are working on this feature that we listed in our plan"
Users
"The blockchain is crashing!"
Dannotestein
"I would like to help, but we promised the trolls that would only work on this feature until it's complete"
Users
"But if you don't change your priority for a moment the blockchain will stop working"
Dannotestein
"I would have to make a new plan a get the trolls approval first, should take a least week because the trolls love to bash"
Users
"We don't have a week!"
Dannotestein
"I tried to make the plan flexible for these scenarios but If I change priorities for something that is more important and urgent the trolls will vote us out for not sticking to the plan. So the blockchain must die so the trolls can be happy"
-
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.
-
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.
-
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.
-
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
-
Please help publish win binaries for release of 2.0.160223. Thanks :)
-
Please help publish win binaries for release of 2.0.160223. Thanks :)
It's up, thanks for the notification.
-
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
-
Please help publish win binaries for release of 2.0.160223. Thanks :)
It's up, thanks for the notification.
Thanks a lot!
-
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 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.
-
I think it's a good time to summarize when a new release is out (which means some maintenance work has been done).
-
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.
-
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
-
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!!
-
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%
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%
-
Thanks for the detailed report!
I think we're getting good value for the money here.
-
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.
-
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 +5%
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?
-
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 +5%
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.
-
@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 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
-
@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
+5%
-
Are there people in China that are able and willing to take on maintenance? Perhaps the best solution is to outsource this support to people who are more cost effective for the blockchain.
I think all that would be required is to identify someone trustworthy enough to grant access to github.
-
I think all that would be required is to identify someone trustworthy enough to grant access to github.
@abit certainly deserves access to github
-
I think all that would be required is to identify someone trustworthy enough to grant access to github.
@abit certainly deserves access to github
Abit has my vote as well, he's a machine!
-
I think all that would be required is to identify someone trustworthy enough to grant access to github.
@abit certainly deserves access to github
+5% agreed
-
I think all that would be required is to identify someone trustworthy enough to grant access to github.
@abit certainly deserves access to github
Abit has my vote as well, he's a machine!
+5%
-
I think all that would be required is to identify someone trustworthy enough to grant access to github.
@abit certainly deserves access to github
Abit has my vote as well, he's a machine!
+5%
Thank you guys, perhaps my skills fit the job, but I'm afraid that my rate won't be as low as @bitcrab and/or other Chinese community members expected, since I'm not living in China, nor a junior developer.
-
@dannotestein could you update us on this proposal? you are still working on this, right? and what's your plan on it in the coming future?
-
@dannotestein could you update us on this proposal? you are still working on this, right? and what's your plan on it in the coming future?
Hi @bitcrab,
I answered this in another thread (https://bitsharestalk.org/index.php/topic,22528.msg293114.html#msg293114), but I guess parts of that thread bear repeating here:
I'm treating the funds accumulated in this 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.
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.
-
thanks Dan.
-
Please be aware that there are still 7,072,500 BTS unclaimed in this worker. I guess it's unused? So perhaps make some good use with it, or return it to the reserve pool?
-
Please be aware that there are still 7,072,500 BTS unclaimed in this worker. I guess it's unused? So perhaps make some good use with it, or return it to the reserve pool?
I'm aware of the unclaimed funds: I don't tend to forget such sums of money, especially when they've appreciated like BTS has since they were allocated. My intent for the usage of the funds remains unchanged from my previous statements about it: I'll draw upon them for work I think especially important to the future of the chain.
So far, I haven't had time to do much BitShares development work personally for a while due to commitments to other contracts, but that is changing soon. As a first step, recently I've begun reviewing the "state" of the project to determine areas where I think some work could be beneficially focused and also doing a small amount of contract work to customers interested in BitShares (the contract work was totally paid for by the customers and didn't involve changes to BitShares itself, so there was no reason to charge the maintenance funds for it). I won't be able to devote a large amount of my own time until my current commitments are completed (somewhere in next 2 to 6 months I hope), but I plan to involve some of our engineers in development work prior to that time (I introduced the guys to the concepts of UIAs, for example, yesterday).
One thing I would like to see now and would be willing to fund for a reasonable price from the allocated funds: an onchain or offchain solution to the bug where the vote counts aren't available for committee members that aren't presently elected. To me this seems like a distinct weakness in the governance system.
-
One thing I would like to see now and would be willing to fund for a reasonable price from the allocated funds: an onchain or offchain solution to the bug where the vote counts aren't available for committee members that aren't presently elected. To me this seems like a distinct weakness in the governance system.
True. Another issue is should proxy in DPOS work for 1 level or multiple levels? Please feel free to give your comment.
https://github.com/bitshares/bsips/issues/79
-
I'm aware of the unclaimed funds: I don't tend to forget such sums of money, especially when they've appreciated like BTS has since they were allocated. My intent for the usage of the funds remains unchanged from my previous statements about it: I'll draw upon them for work I think especially important to the future of the chain.
... I plan to involve some of our engineers in development work prior to that time (I introduced the guys to the concepts of UIAs, for example, yesterday).
Thanks for the clarification and contributions.
One thing I would like to see now and would be willing to fund for a reasonable price from the allocated funds: an onchain or offchain solution to the bug where the vote counts aren't available for committee members that aren't presently elected. To me this seems like a distinct weakness in the governance system.
There is an github issue for this: https://github.com/bitshares/bitshares-core/issues/987, actually I've got an idea about how to fix it just a few days before, although not yet started to code, due to priority. It's also good if someone else can get it fixed. However, IMHO, efforts related to this issue can be covered by the core dev worker if there isn't a dedicated bounty for it.
Back to the topic, 7 million BTS seems a bit too huge in comparison to such small bounties. Now we already have a core dev worker to cover the maintenance job which was intention of this worker. Since we haven't yet decided how to use this fund, given the fact that most workers on chain now are being paid via escrows, I propose that we move the remaining funds of this worker to be controlled by an escrow service (for example BBF) or merge it with the core dev worker, if we still want to use it to fund core development / maintenance. We do want experienced project manager and developers to help and contribute, not only funds. On the other hand, if we're going to use it to fund other things, which would be out of this worker's scope, IMHO it's best to re-vote.
-
Another issue is should proxy in DPOS work for 1 level or multiple levels? Please feel free to give your comment.
https://github.com/bitshares/bsips/issues/79
I left my comments on the issue.
-
Back to the topic, 7 million BTS seems a bit too huge in comparison to such small bounties. Now we already have a core dev worker to cover the maintenance job which was intention of this worker. Since we haven't yet decided how to use this fund, given the fact that most workers on chain now are being paid via escrows, I propose that we move the remaining funds of this worker to be controlled by an escrow service (for example BBF) or merge it with the core dev worker, if we still want to use it to fund core development / maintenance. We do want experienced project manager and developers to help and contribute, not only funds. On the other hand, if we're going to use it to fund other things, which would be out of this worker's scope, IMHO it's best to re-vote.
It's not my intent to use it for small bounties. I only mentioned that particular issue as I considered it of enough significance that I would be willing to fund it as I don't yet have time to assign someone to work on it.
The funds were originally assigned for BlockTrades to perform work it considered of sufficient importance based on my judgement. As such, I consider the funds mainly should still be allocated for such usage, unless I think there's a case where I decide someone can do something of high importance cheaper/easier.
I will not abuse the trust the original voters placed in my judgement by mis-using the funds. But IMO the funds should not be placed in someone else's control unless I make that decision without external pressure. And I would generally feel uncomfortable doing even that, because if I made the wrong decision, the funds could be abused and I would no longer be able to prevent it, so it would have to be someone I trusted at a level that I trust only a few people in this world. I hope you can understand my position on this.
If you feel that more funds need to be allocated to development at the current time, I suggest you create additional worker proposals and seek approval for the same. The great thing about BitShares is we do have an awesome system for polling the will of the holders, even if it has some flaws.
-
It is ready for grading, but later additions that are less integral to the lore correctness of this proposal are planned.
I don't understand what you are saying here, could you please elaborate?
-
It is ready for grading, but later additions that are less integral to the lore correctness of this proposal are planned.
I don't understand what you are saying here, could you please elaborate?
It's a spam bot. I've been sending Fav PM's on Telegram but he has not removed it yet. :D
-
It is ready for grading, but later additions that are less integral to the lore correctness of this proposal are planned.
I don't understand what you are saying here, could you please elaborate?
It's a spam bot. I've been sending Fav PM's on Telegram but he has not removed it yet. :D
use the report link please
-
It is ready for grading, but later additions that are less integral to the lore correctness of this proposal are planned.
I don't understand what you are saying here, could you please elaborate?
It's a spam bot. I've been sending Fav PM's on Telegram but he has not removed it yet. :D
use the report link please
Hahaha, ok i'll raise blind :)
Done.
-
The funds were originally assigned for BlockTrades to perform work it considered of sufficient importance based on my judgement. As such, I consider the funds mainly should still be allocated for such usage, unless I think there's a case where I decide someone can do something of high importance cheaper/easier.
What i concern is the fouds if it still belong to BTS community?
If the BTS community have the power to take back it? as the mechanism of the worker pay will need to redesign.
-
The funds were originally assigned for BlockTrades to perform work it considered of sufficient importance based on my judgement. As such, I consider the funds mainly should still be allocated for such usage, unless I think there's a case where I decide someone can do something of high importance cheaper/easier.
What i concern is the fouds if it still belong to BTS community?
If the BTS community have the power to take back it? as the mechanism of the worker pay will need to redesign.
The funds remain under control of BlockTrades and are still being retained for emergency use only. I have not sold them and will not sell them except I think it is required for the purpose these funds were originally allocated for. So, for now they are effectively "dead coins" unless there is a Bitshares emergency that requires them to be spent. They are certainly having no impact on the price of BTS.
The BTS community has the power to take it back in the same way it can take back any funds: it can fork the chain. But it would be a stupid reason to fork the chain, IMO.
I have no idea what you mean by "the mechanism of the work pay will need to redesign". What do you want to be redesigned? Do you mean that you want to be able to take back vested funds from a worker without a fork? And if so, why? Because you are unhappy that I sold my company's BTS? This has nothing to do with the funds for the worker. I would never sell off these funds except for the purpose I originally committed them to. This can easily be seen when you consider that I've held these funds even when bts was worth 0.40 USD and also that I still haven't sold them, despite selling all my company's BTS.
-
The BTS community has the power to take it back in the same way it can take back any funds: it can fork the chain. But it would be a stupid reason to fork the chain, IMO.
I think i have said very clearly, and you give this answer?
We would make a report once per month on what has been done during that period.
So what is "that period"?
I have no idea what you mean by "the mechanism of the work pay will need to redesign". What do you want to be redesigned? Do you mean that you want to be able to take back vested funds from a worker without a fork? And if so, why? Because you are unhappy that I sold my company's BTS? This has nothing to do with the funds for the worker. I would never sell off these funds except for the purpose I originally committed them to. This can easily be seen when you consider that I've held these funds even when bts was worth 0.40 USD and also that I still haven't sold them, despite selling all my company's BTS.
I didn't understand how and why you got such conclusion? and become so angry and emotional? just as i show the data of blockchain？
Serious talk: i didn't care about you sold or not sold, i just show the data, i also show the data of others big sell.
"the mechanism of the work pay will need to redesign". is mean:
Someone did a worker and finished, then we will pay or pay it with the milestone, the whole funds will not controled by the worker, will controled by the committee/wittness with a multi-signature account, and will have the examiner to check the result of worker.
------------------
So let's focus the topic:
if this worker has been out of date(or not) and didn't have any actives for such a long time, the rest funds should burn to the reserve pool, the worker have the obligation to do that.
We had lost many funds like this way.
-
The BTS community has the power to take it back in the same way it can take back any funds: it can fork the chain. But it would be a stupid reason to fork the chain, IMO.
I think i have said very clearly, and you give this answer?
We would make a report once per month on what has been done during that period.
So what is "that period"?
I have no idea what you mean by "the mechanism of the work pay will need to redesign". What do you want to be redesigned? Do you mean that you want to be able to take back vested funds from a worker without a fork? And if so, why? Because you are unhappy that I sold my company's BTS? This has nothing to do with the funds for the worker. I would never sell off these funds except for the purpose I originally committed them to. This can easily be seen when you consider that I've held these funds even when bts was worth 0.40 USD and also that I still haven't sold them, despite selling all my company's BTS.
I didn't understand how and why you got such conclusion? and become so angry and emotional? just as i show the data of blockchain？
Serious talk: i didn't care about you sold or not sold, i just show the data, i also show the data of others big sell.
"the mechanism of the work pay will need to redesign". is mean:
Someone did a worker and finished, then we will pay or pay it with the milestone, the whole funds will not controled by the worker, will controled by the committee/wittness with a multi-signature account, and will have the examiner to check the result of worker.
------------------
So let's focus the topic:
if this worker has been out of date(or not) and didn't have any actives for such a long time, the rest funds should burn to the reserve pool, the worker have the obligation to do that.
We had lost many funds like this way.
I'm actually not angry, I'm only trying to understand what problem you think exists and what you want to do to fix it. I'm still not sure, but I think you think that because we haven't done anything in a long time, or spent the money, that there is some problem.
So let me explain to you what the money was for: it was money that was to be spent conditionally, only if there was a problem that needed fixing. For a long time, I saw no such problem, so I simply kept the money unspent. Later, a core dev team emerged and began to work on new things and also make some fixes. So, with them around, I didn't see any need to spend the money. Instead I decided to hold it in case they lost their funding and them some problem arose. This is still my intent.
You also say "we had lost many funds this way". I have no idea what you meant by this, you need to be more specific about such instances. I understand that English is not your first language, but you need to say more when you make such statements. Without more information, I can only guess what you talk about.
Anyways, in the case of the funds I hold, nothing has been lost: if I don't spend it, it's very similar to if it's in the reserve pool. The big difference is that if I think it needs to be spent, I can make the decision without consent of current big voters (I got the consent from old big voters). You think I have the obligation to burn the funds, but I disagree. I think I have the obligation I took on when I made the proposal: to spend the funds if necessary to save the chain if some serious problem arises and otherwise to leave the funds alone. This is a safety net for the chain, and I think it's a good one.
Maybe you don't like this. But then, I don't like many decisions of the current big voters much either. But we both must abide by the rules of the blockchain. You can certainly argue for changing them, but I find your argument, to the extent I am able to understand it, very unpersuasive. If you want to make changes to the blockchain rules, there are much more serious issues to address than this, in my opinion. I guarantee you this money you're so worried about has had no impact on the price of BitShares, unlike the voting problems that BitShares is having which has damaged the price so much.
-
The BTS community has the power to take it back in the same way it can take back any funds: it can fork the chain. But it would be a stupid reason to fork the chain, IMO.
I think i have said very clearly, and you give this answer?
We would make a report once per month on what has been done during that period.
So what is "that period"?
I have no idea what you mean by "the mechanism of the work pay will need to redesign". What do you want to be redesigned? Do you mean that you want to be able to take back vested funds from a worker without a fork? And if so, why? Because you are unhappy that I sold my company's BTS? This has nothing to do with the funds for the worker. I would never sell off these funds except for the purpose I originally committed them to. This can easily be seen when you consider that I've held these funds even when bts was worth 0.40 USD and also that I still haven't sold them, despite selling all my company's BTS.
I didn't understand how and why you got such conclusion? and become so angry and emotional? just as i show the data of blockchain？
Serious talk: i didn't care about you sold or not sold, i just show the data, i also show the data of others big sell.
"the mechanism of the work pay will need to redesign". is mean:
Someone did a worker and finished, then we will pay or pay it with the milestone, the whole funds will not controled by the worker, will controled by the committee/wittness with a multi-signature account, and will have the examiner to check the result of worker.
------------------
So let's focus the topic:
if this worker has been out of date(or not) and didn't have any actives for such a long time, the rest funds should burn to the reserve pool, the worker have the obligation to do that.
We had lost many funds like this way.
I'm actually not angry, I'm only trying to understand what problem you think exists and what you want to do to fix it. I'm still not sure, but I think you think that because we haven't done anything in a long time, or spent the money, that there is some problem.
So let me explain to you what the money was for: it was money that was to be spent conditionally, only if there was a problem that needed fixing. For a long time, I saw no such problem, so I simply kept the money unspent. Later, a core dev team emerged and began to work on new things and also make some fixes. So, with them around, I didn't see any need to spend the money. Instead I decided to hold it in case they lost their funding and them some problem arose. This is still my intent.
You also say "we had lost many funds this way". I have no idea what you meant by this, you need to be more specific about such instances. I understand that English is not your first language, but you need to say more when you make such statements. Without more information, I can only guess what you talk about.
Anyways, in the case of the funds I hold, nothing has been lost: if I don't spend it, it's very similar to if it's in the reserve pool. The big difference is that if I think it needs to be spent, I can make the decision without consent of current big voters (I got the consent from old big voters). You think I have the obligation to burn the funds, but I disagree. I think I have the obligation I took on when I made the proposal: to spend the funds if necessary to save the chain if some serious problem arises and otherwise to leave the funds alone. This is a safety net for the chain, and I think it's a good one.
Maybe you don't like this. But then, I don't like many decisions of the current big voters much either. But we both must abide by the rules of the blockchain. You can certainly argue for changing them, but I find your argument, to the extent I am able to understand it, very unpersuasive. If you want to make changes to the blockchain rules, there are much more serious issues to address than this, in my opinion. I guarantee you this money you're so worried about has had no impact on the price of BitShares, unlike the voting problems that BitShares is having which has damaged the price so much.
As you wish, do what you want to do.
-
Didn't you posted before that you are going to send back to reserve pool when the amount gets to big ?
I guess 7 million bts could be considered as to big
-
Didn't you posted before that you are going to send back to reserve pool when the amount gets to big ?
I guess 7 million bts could be considered as to big
As if he wasn't going to do that, he thought he had a right to the money.
-
Didn't you posted before that you are going to send back to reserve pool when the amount gets to big ?
I guess 7 million bts could be considered as to big
As if he wasn't going to do that, he thought he had a right to the money.
To Thul3:
No, I didn't ever make such a statement. You seem to be confused. The amount is not currently accumulating, it hit the total amount of 7 million BTS long ago (years ago). In the last discussion where it was talked abou a while ago, I made it clear: I'm only holding the accumulated funds for possible use to help the chain if necessary.
To finn-bts: If I thought I had a right to spend the BTS for my own use, I would have sold it when I sold my own funds. Please use some common sense.
-
Didn't you posted before that you are going to send back to reserve pool when the amount gets to big ?
I guess 7 million bts could be considered as to big
As if he wasn't going to do that, he thought he had a right to the money.
To Thul3:
No, I didn't ever make such a statement. You seem to be confused. The amount is not currently accumulating, it hit the total amount of 7 million BTS long ago (years ago). In the last discussion where it was talked abou a while ago, I made it clear: I'm only holding the accumulated funds for possible use to help the chain if necessary.
To finn-bts: If I thought I had a right to spend the BTS for my own use, I would have sold it when I sold my own funds. Please use some common sense.
It was always my plan to refund unused pay from the worker
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.
So a few months back the 7 million bts were worth arround $500k
Before that it was even worth more than a million USD .
I'm only holding the accumulated funds for possible use to help the chain if necessary.
So there should be no problem to push the BTS to the new core team?
http://archive.ph/T7TEw
-
Didn't you posted before that you are going to send back to reserve pool when the amount gets to big ?
I guess 7 million bts could be considered as to big
As if he wasn't going to do that, he thought he had a right to the money.
To Thul3:
No, I didn't ever make such a statement. You seem to be confused. The amount is not currently accumulating, it hit the total amount of 7 million BTS long ago (years ago). In the last discussion where it was talked abou a while ago, I made it clear: I'm only holding the accumulated funds for possible use to help the chain if necessary.
To finn-bts: If I thought I had a right to spend the BTS for my own use, I would have sold it when I sold my own funds. Please use some common sense.
It was always my plan to refund unused pay from the worker
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.
So a few months back the 7 million bts were worth arround $500k
Before that it was even worth more than a million USD .
The price of BTS has been incredibly volatile, as I would guess you should know. If I had been certain the price would have stayed so high, it would have made sense to send it back to the reserve pool. But as time has shown, the current value is about $110K, which I don't consider a lot if serious problems arose, but enough.