BitShares Forum
Main => Stakeholder Proposals => Topic started by: graphenelab on December 11, 2019, 10:39:04 am
-
BitShares Core Team Worker Proposal
Graphene Lab is glad to introduce you the new Core Team Worker Proposal.
Problem
Current core team of developers has a monopoly. We believe that lack of healthy competition always leads to the lack of growth and decreasing quality of work. Also, the high price of the current worker proposal doesn’t meet the expectations of the majority of the community.
Solution
We invite the BitShares’ community to vote for a new team of developers. We guarantee very low rates and 100% immersion in work. In addition, we are ready to actively cooperate with the various representatives of the community in order to make really needed and popular improvements.
Our team
Denis Bredikhin
Has a degree in marketing, more than 6 years in strategic consulting and about 4 in project management.
Igor Romanov
CTO / Core developer. Blockchain development, development of highly loaded systems, development of mobile applications, audit. Over 15 years of experience.
Languages: C / C++, C #, ASM, JAVA, OBJECTIVE C.
Olga Pachenkova
Blockchain development, development of highly loaded systems, the main direction is data protection. Over 15 years of experience.
Languages: C / C++, ASM, JAVA.
Ruslan Salikhov
Blockchain development, development of trading bots, development of telegram bots. Over 7 years of experience.
Languages: C++ / Qt, Python, NodeJS.
Dmitriy Kasatkin
Experienced tester. Functional testing, system testing, performance testing, regression testing, usability testing, etc, Over 4 years of experience.
The team also includes another QA-engineer and one community manager.
Budget
The table below indicates the expenses of the team for one year:
(https://i.postimg.cc/52QmgYML/12.png)
We invite you to read the full proposal here: https://worker.graphenelab.io/
We will be glad to answer any questions you may have!
Best Regards,
Graphene Lab
-
Welcome, but we need a Chinese version, thanks.
-
Welcome, but we need a Chinese version, thanks.
Hi! Yep, we will translate it, thanks for advice!
-
Wow pleasantly surprised to see some new proposals come forward.
Can you tell us where your team is located? What nationality, and country of residence are they in? Is this team all remote, or do they have an office somewhere?
Cryptick1
-
Wow pleasantly surprised to see some new proposals come forward.
Can you tell us where your team is located? What nationality, and country of residence are they in? Is this team all remote, or do they have an office somewhere?
Cryptick1
Our core team is located in St. Petersburg, Russia. Ruslan and Cyril (CM) are located in other countries. We work in the office, and are ready to invite someone to visit by prior arrangement :)
-
Thank you for your participation. Since Google services are not available in China, could you upload your documents by other means?
-
Thank you for your participation. Since Google services are not available in China, could you upload your documents by other means?
Hi! Ad link to WeTransfer in first message, as I know it work in China :)
-
+5%
-
Thank you for your participation. Since Google services are not available in China, could you upload your documents by other means?
Hi! Ad link to WeTransfer in first message, as I know it work in China :)
thank you!
-
We are ready to cooperate with other developers.
Nice to see that statement +5%
-
+5% Full support!
-
+5% Full support!
With Dima and Xeroc supporting it, I will support this as well.
-
Current core team of developers has a monopoly.
I don't think is/was the case, anyone could have joined in core development for rewards through the Community Claims program, did your team attempt such community claims?
-
Will follow KenCode, Rudex and Fabian ! More proposals means more collaboration +5%
-
+5% Full support!
-
glad to see this.
in my view current core team do a good job, the main concern from the community is the high salary, and we also need to review the process.
if we want to build a more open and competitive core development infrastructure, we need to consider some points:
1.should the worker base on time or stage/project?
I feel it's better to organize the work base on stage, say, at this moment, community decide what features need to be included in the next hard fork, "core team" estimate the work load and schedule the work and create a worker for approval accordingly. the worker only cover the work for the selected features in this cycle, after that community will decide the next round of new features for "core team" to finish. possibly different stage different teams are selected to do the development.
2.
one fact is that the BSIP author is not always member of "core team", theoretically anyone can draft BSIP and is chosen by voting, if finally the BSIP is voted and implemented, the BSIP author should also be paid from the core worker.
3. if one team is voted for core development, how can we guarantee the smooth transition of the management of the project repo? any supervision is needed?
-
1. Does the team talk with Abit and invite him into the team? I guess Chinese are more willing to support core team with Abit as core developer.
2. In case there is 2 or more core teams worker proposals voted in, how the team coordinate with other core team for development?
-
Current core team of developers has a monopoly.
I don't think is/was the case, anyone could have joined in core development for rewards through the Community Claims program, did your team attempt such community claims?
The phrase about the monopoly could sound negative, but it's just an attempt to reflect the current situation. At the moment, the team is one, the main composition in the team is determined from the start and has been changing slightly for a long time. We decided that it makes sense to present our proposal to the community, so that people know that there are a lot of developers who can deal with such a project and there is always a choice :) I remember how in the summer there were different sayings in chats, like no one else could develop our platform. This is not true :)
By the way, we plan to offer a number of developers from the current team to work with us, so we are open to suggestions :)
-
1. Does the team talk with Abit and invite him into the team? I guess Chinese are more willing to support core team with Abit as core developer.
2. In case there is 2 or more core teams worker proposals voted in, how the team coordinate with other core team for development?
1) we want to invite some developers of the current team and would be very happy especially Abit. He is certainly one of the most respected and experienced developers on our platform.
2) in this case, we will share the tasks by combining the roadmap and we will develop together. I do not see any problems with cooperation, the community should decide here.
-
glad to see this.
in my view current core team do a good job, the main concern from the community is the high salary, and we also need to review the process.
if we want to build a more open and competitive core development infrastructure, we need to consider some points:
1.should the worker base on time or stage/project?
I feel it's better to organize the work base on stage, say, at this moment, community decide what features need to be included in the next hard fork, "core team" estimate the work load and schedule the work and create a worker for approval accordingly. the worker only cover the work for the selected features in this cycle, after that community will decide the next round of new features for "core team" to finish. possibly different stage different teams are selected to do the development.
2.
one fact is that the BSIP author is not always member of "core team", theoretically anyone can draft BSIP and is chosen by voting, if finally the BSIP is voted and implemented, the BSIP author should also be paid from the core worker.
3. if one team is voted for core development, how can we guarantee the smooth transition of the management of the project repo? any supervision is needed?
Hi!
1) It is possible to base workers on stage/project, but there are some difficulties related to the community - quite often it is not very active. Besides, it is necessary to have a stable team for quick fixes and just for smooth development overall. That's exactly why we believe that budget for the core team should be much lower and that's why we proposed our solution.
2) I agree. Also we shouldn't forget that tasks for the team are long-term and any unexpected BSIPs can negatively affect speed and quality of the work. Therefore I don't see any reasons why it shouldn't be possible to pay for the work of another team, which implements some features simultaneously with the main team.
3) We want to offer a number of current developers to work together with us to guarantee smooth and comfortable transition for everyone. It will be easier for the community to trust new people this way.
-
Is the PDF posted above considered the full proposal with the intention to put it up for voting like that, or is that merely the team introduction?
-
Is the PDF posted above considered the full proposal with the intention to put it up for voting like that, or is that merely the team introduction?
We will release full offer after discussion with the community. It will include roadmap describing tasks we would like to implement and open positions for those members of the current team who want to work with us. Rates of the team that was already described in the current offer won't change.
-
Is the PDF posted above considered the full proposal with the intention to put it up for voting like that, or is that merely the team introduction?
We will release full offer after discussion with the community. It will include roadmap describing tasks we would like to implement and open positions for those members of the current team who want to work with us. Rates of the team that was already described in the current offer won't change.
Thanks a lot!
-
Some tough questions for you:
1. are you willing to setup a 6-month or even 12-month vesting period for your worker pay?
2. are you willing to accept BTS as payment if each BTS is statically calculated as 0.1 or 0.2 USD, or another rate much higher than current spot price?
3. will you still finish your work if your worker got voted down temporarily, or even being down for a long time? Judging from the rossul-ui worker, it's true that you did more work when the worker was voted down, but another truth is you still didn't finish it.
4. are you willing to only get paid after delivery of your work? The delivery process can be defined, e.g. milestones.
5. are you willing to accept a condition that if BTS price or average price didn't reach a value (e.g. 1CNY) during a year, you receive less (e.g. 50% of) BTS as pay?
By the way, the issue we're facing now is more "what to do" rather than "who to do", in other words, scope definition.
-
possible to share the developers' github accounts?
-
Some tough questions for you:
1. are you willing to setup a 6-month or even 12-month vesting period for your worker pay?
2. are you willing to accept BTS as payment if each BTS is statically calculated as 0.1 or 0.2 USD, or another rate much higher than current spot price?
3. will you still finish your work if your worker got voted down temporarily, or even being down for a long time? Judging from the rossul-ui worker, it's true that you did more work when the worker was voted down, but another truth is you still didn't finish it.
4. are you willing to only get paid after delivery of your work? The delivery process can be defined, e.g. milestones.
5. are you willing to accept a condition that if BTS price or average price didn't reach a value (e.g. 1CNY) during a year, you receive less (e.g. 50% of) BTS as pay?
By the way, the issue we're facing now is more "what to do" rather than "who to do", in other words, scope definition.
Hi! Thanks for your questions :)
1) Worker settings are discussed right now. Moreover, we dicuss the possibility of using an escrow, which might be launched with the support of the blckchnd team and number of other large proxies and respected members of the community.
2) In case we'll launch the worker using an escow, we'll receive the payments in bitassets or BTS. But in any case we'll get our payment strictly according to our rates. We don't need extra money - it is up to community to decide what to do with it.
3) We've done almost all the work, completing much more than it was paid for. The additional worker showed that the community is not interested in continuing the work yet - that's why it was suspended.
But it is different story with the core worker. If it will become inactive, we will continue our work. In case it'll stay inactive for several months, we propose the following: every update will be in a BSIP form, and the community will decide whether they are willing to pay for each of them. In any case, if there'll be critical problems we'll solve them under any circumstances.
4) The payments will be proceeded according to the reports to the community and escrow (if there'll be one) every two weeks and/or month. Reports will be public as the work itself.
5) I'm not sure that is a correct offer. Of course we are ready to discuss such ideas with the community, but our worker was created to help the platform to save funds in the first place. In particular, that is possible because we don't have travel and tools budget, not mentioning that our proposal is several times cheaper overall.
-
possible to share the developers' github accounts?
On other projects, and now we work most often in closed repositories. In general, you can watch our git or bitbucket, but most of the repositories are not public.
https://github.com/GrapheneLab
https://github.com/ruslansalikhov
https://bitbucket.org/graphenelab/
-
most of the repositories are not public.
Related, Recent Commits and Reputation
Commits:
If I am going to hire a new Dev, I don't give a shit about their resume or university certificate.
I want to see their recent commits, that are also related to the job that I am thinking of hiring them for.
Without that proof, it's like throwing money on a campfire and hoping it doesn't burn.
Reputation:
Xeroc and Dima give this WP a thumbsup and imo that says a LOT because I have watched both of those guys for 5+ years actually produce value.
-
up to now it seems the community is not sufficiently convinced that Graphene Lab is qualified enough for the core work.
"The GrapheneLabs proposal is welcomed. Thus far, it lacks support from the Community. Cheaper developers “may” deliver better value to the DAC. However, I’ve not seen any contributions from the listed team members which indicate their ability to deliver solutions at an economical rate."
"It's a daunting job and poor code contributions leads to increased/unpleasant review time. for example, We found working with ********** difficult to impossible as their code quality was not accepted by the reviewers. The resulting costs were too high for their efforts."
I feel Graphene Lab need to provide more persuasive information to convince the community...
-
up to now it seems the community is not sufficiently convinced that Graphene Lab is qualified enough for the core work.
"The GrapheneLabs proposal is welcomed. Thus far, it lacks support from the Community. Cheaper developers “may” deliver better value to the DAC. However, I’ve not seen any contributions from the listed team members which indicate their ability to deliver solutions at an economical rate."
"It's a daunting job and poor code contributions leads to increased/unpleasant review time. for example, We found working with ********** difficult to impossible as their code quality was not accepted by the reviewers. The resulting costs were too high for their efforts."
I feel Graphene Lab need to provide more persuasive information to convince the community...
I would like to know to whom the second quote applies and whose phrase is this?
If this is about our team, then who said it and on what project, and if not about us, then why is it here?
As for the quality of work, our developers have extensive experience working both with the BitShares core and with other large developments.
Of course, in any code there may be errors, blockchain stops in 2018 and 2017 proves that even developers who constantly work with BitShares do not guarantee excellent quality of work.
That is why in the first stages of work we will devote a lot of time to code audit in order to minimize the probability of errors and even better study the core of the system
-
up to now it seems the community is not sufficiently convinced that Graphene Lab is qualified enough for the core work.
"The GrapheneLabs proposal is welcomed. Thus far, it lacks support from the Community. Cheaper developers “may” deliver better value to the DAC. However, I’ve not seen any contributions from the listed team members which indicate their ability to deliver solutions at an economical rate."
"It's a daunting job and poor code contributions leads to increased/unpleasant review time. for example, We found working with ********** difficult to impossible as their code quality was not accepted by the reviewers. The resulting costs were too high for their efforts."
I feel Graphene Lab need to provide more persuasive information to convince the community...
I would like to know to whom the second quote applies and whose phrase is this?
It's OpenLedger. You'll know who said it if he likes you to know.
Actually IMO OL's code quality is fine, but their reported hours were too many, so cost per work item was too high.
If this is about our team, then who said it and on what project, and if not about us, then why is it here?
As for the quality of work, our developers have extensive experience working both with the BitShares core and with other large developments.
Of course, in any code there may be errors, blockchain stops in 2018 and 2017 proves that even developers who constantly work with BitShares do not guarantee excellent quality of work.
That is why in the first stages of work we will devote a lot of time to code audit in order to minimize the probability of errors and even better study the core of the system
I apologize in advance if I'm too offensive here.
To be frank, I don't think the community would very like to pay someone for studying the current system/code.
Paying for code audit is probably acceptable, but it should be by request, or a dedicated offer (imo). If you expect to earn money by finding critical bugs, you should go after the hackthedex worker, it pays pretty well.
The main job of core dev (worker) should be to submit code. To prove you can do the job, imo the simplest approach for you is to start submitting code right now / asap. Endless talking doesn't help much.
-
It's OpenLedger.
No, it's not OL.
Not going to mention names here, but it wasn't anyone from the Graphene Lab team.
-
It's OpenLedger.
No, it's not OL.
Not going to mention names here, but it wasn't anyone from the Graphene Lab team.
I know where the quoted sentences came from and who said it. The mentioned name was OL. That's why I added my comments above as I don't think OL's code is too low-quality, just to be fair.
-
We know too little about Graphene Lab. Although the budget you reported looks appropriate, the community does not have the confidence to entrust you with core development work until you fully understand your identity, capabilities, and contributions.
-
No, it's not OL.
Not going to mention names here, but it wasn't anyone from the Graphene Lab team.
I know where the quoted sentences came from and who said it. The mentioned name was OL. That's why I added my comments above as I don't think OL's code is too low-quality, just to be fair.
Oh, ok, sorry. I agree with your comments about OL, that's why I was thinking of someone else.
-
up to now it seems the community is not sufficiently convinced that Graphene Lab is qualified enough for the core work.
"The GrapheneLabs proposal is welcomed. Thus far, it lacks support from the Community. Cheaper developers “may” deliver better value to the DAC. However, I’ve not seen any contributions from the listed team members which indicate their ability to deliver solutions at an economical rate."
"It's a daunting job and poor code contributions leads to increased/unpleasant review time. for example, We found working with ********** difficult to impossible as their code quality was not accepted by the reviewers. The resulting costs were too high for their efforts."
I feel Graphene Lab need to provide more persuasive information to convince the community...
I would like to know to whom the second quote applies and whose phrase is this?
If this is about our team, then who said it and on what project, and if not about us, then why is it here?
As for the quality of work, our developers have extensive experience working both with the BitShares core and with other large developments.
Of course, in any code there may be errors, blockchain stops in 2018 and 2017 proves that even developers who constantly work with BitShares do not guarantee excellent quality of work.
That is why in the first stages of work we will devote a lot of time to code audit in order to minimize the probability of errors and even better study the core of the system
the words are not about anyone from Graphene Lab, I quoted it here to just emphasize "poor code contributions leads to increased/unpleasant review time", I am sorry if it is misleading.
-
Greetings everyone. Thank you for your questions and support.
We do understand the worry of the part of the community. The BitShares platform deserves experienced developers with the clear understanding of what has to be done (and how that has to be done) to make things better. Therefore, we would like to clarify several points.
First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/ (https://worker.graphenelab.io/)
Besides, I would like to address the offer to work on the BitShares outside of the worker proposal to earn reputation. I could have agreed with that if the matter was about hiring freelancers that develop out of curiosity in their free time (that often negatively affects the quality of the work). But the BitShares platform needs the team that has an extensive experience of the commercial development that values its reputation because it directly affects the success of its business. I would never risk the name of the company if I wasn't sure in our capability to improve the product and if I doubted the quality of our work. I invite anyone who doubts our competence and experience to take a look at our previous projects. Graphene Lab has worked for more than three years using the BitShares' code in our projects, including the change of consensus mechanism and adding new functionality (e.g. new referral system, rating system, credit contracts, etc).
Also I would like to mention that we are open for proposals from other developers (especially from the previous core team). Moreover, we are ready to propose them rates that are higher than ours. We'll leave free spots in our worker proposal and in case there will be unspent funds we will direct them for other needs of the platform by voting.
In any case, we will publish our core worker proposal on-chain tomorrow. After that it will be left for the community to decide, whether the platform needs the team of experienced developers or the current situation with uncertainty and enormous expenses satisfies everyone.
Thank you for the attention!
-
I invite anyone who doubts our competence and experience to take a look at our previous projects. Graphene Lab has worked for more than three years using the BitShares' code in our projects, including the change of consensus mechanism and adding new functionality (e.g. new referral system, rating system, credit contracts, etc).
Nice! What fork is that? Is it public?
-
First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/ (https://worker.graphenelab.io/)
I assume you refer to this list?
- AUDIT OF THE PLATFORM
- CHANGING THE FEE COLLECTION SYSTEM
- CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
- FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
- GOVERNANCE
- DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
- MARGIN CALL FEE (BSIP74)
- LENDING OPTIONS
- NON-LTM REFERRAL & MEMBERSHIP
Could you please elaborate shortly on each of the items what the actions points / vision are?
Was also wondering in what way will review and payments of your deliveries be handled?
-
I invite anyone who doubts our competence and experience to take a look at our previous projects. Graphene Lab has worked for more than three years using the BitShares' code in our projects, including the change of consensus mechanism and adding new functionality (e.g. new referral system, rating system, credit contracts, etc).
Nice! What fork is that? Is it public?
Fork with another consensus not public, as far as I know, they abandoned the idea of the project, but the idea was interesting. Dynamic emission depending on network activity, and the distribution is among the participants of the network that are beneficial (determined by a complex mathematical formula and took into account many factors). Accordingly, if the network did not grow, then the emission did not occur, and if it was actively developing, then active users received their bonuses
Fork with a referral and rating system - Karma. In it, we tied all the logic to loan contracts. Thus, the user, even without LTM, could invite people and receive income from them, but if the people they invited didn’t pay back loans, then the rating of the invitee fell :) https://github.com/GrapheneLab/karma-core
Unfortunately, most of our work is commercial in nature, which often leads to closed repositories, but you can look at our git and find enough sources to study
-
First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/ (https://worker.graphenelab.io/)
I assume you refer to this list?
- AUDIT OF THE PLATFORM
- CHANGING THE FEE COLLECTION SYSTEM
- CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
- FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
- GOVERNANCE
- DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
- MARGIN CALL FEE (BSIP74)
- LENDING OPTIONS
- NON-LTM REFERRAL & MEMBERSHIP
Could you please elaborate shortly on each of the items what the actions points / vision are?
Was also wondering in what way will review and payments of your deliveries be handled?
That's right, the list is correct :) I will answer questions in a couple of hours
Also, small mistake crept in. This is the previous version, in the current one, we decided to abandon the work on the Governance, since this topic is too complex and controversial to be dealt with only by developers.
-
First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/ (https://worker.graphenelab.io/)
I assume you refer to this list?
- AUDIT OF THE PLATFORM
- CHANGING THE FEE COLLECTION SYSTEM
- CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
- FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
- GOVERNANCE
- DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
- MARGIN CALL FEE (BSIP74)
- LENDING OPTIONS
- NON-LTM REFERRAL & MEMBERSHIP
Could you please elaborate shortly on each of the items what the actions points / vision are?
Was also wondering in what way will review and payments of your deliveries be handled?
Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.
Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).
Documentation for businesses with examples
BitShares highly depends on businesses that invite users to the platform. We believe that clear and convenient documentation instead of the need to deeply investigate numerous nuances is crucial to attract them. BitShares has huge opportunities, but sometimes the scale of it is the exact same reason that repels potential businesses.
Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.
Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?
Margin Call fee (BSIP74)
Custom taker/maker fees (BSIP81, BSIP85)
Lending options (BSIP70)
These points are thoroughly described in the corresponding BSIPs. It is possible that something will change while developing, but overall these concepts look very tempting, their implementation will be useful for the platform. By the way, we already had an experience implementing solution that resembles lending options (BSIP 70) while developing a credit contract in the other project (Karma).
At first we expect direct payments without an escrow. Later, when the BLCKCHND team will finish their escrow project (which will interact with a number of proxies and respected members of the community), we'll transfer keys from the worker's account to this escrow. This way all acceptance of work and inspections will be conducted through them.
Also, considering the open nature of the development, everyone will be able to inspect and test results of our work. Not to mention our internal testers thoroughly reviewing the code.
-
Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.
Just FYI, this could go hand in hand with HackTheDex, and it would likely pay a much higher rate when you find actual bugs.
Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).
The main issue here is keeping the fee pool of a private asset funded. Any order can already be canceled if it contains enough to pay cancellation fee, because the user gets the balance from the order first, and then the fee is deducted. This only works e.g. with GATEWAY.BTC if the fee pool of the asset is funded. The only reason that you can't cancel orders in the BitShares UI without having the cancellation fee before is complicated frontend code, but no core issue.
Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.
I assume you mean publishing release 4 to mainnet with BSIP-40 here (which provides that among many other use cases)? Or did you have something else in mind?
Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?
Can you elaborate what you mean with "the classic referral system"?
At first we expect direct payments without an escrow.
Will you denote your worker in some BitAsset, FIAT or BTS?
-
First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/ (https://worker.graphenelab.io/)
I assume you refer to this list?
- AUDIT OF THE PLATFORM
- CHANGING THE FEE COLLECTION SYSTEM
- CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
- FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
- GOVERNANCE
- DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
- MARGIN CALL FEE (BSIP74)
- LENDING OPTIONS
- NON-LTM REFERRAL & MEMBERSHIP
Could you please elaborate shortly on each of the items what the actions points / vision are?
Was also wondering in what way will review and payments of your deliveries be handled?
Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.
Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).
Documentation for businesses with examples
BitShares highly depends on businesses that invite users to the platform. We believe that clear and convenient documentation instead of the need to deeply investigate numerous nuances is crucial to attract them. BitShares has huge opportunities, but sometimes the scale of it is the exact same reason that repels potential businesses.
Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.
Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?
Margin Call fee (BSIP74)
Custom taker/maker fees (BSIP81, BSIP85)
Lending options (BSIP70)
These points are thoroughly described in the corresponding BSIPs. It is possible that something will change while developing, but overall these concepts look very tempting, their implementation will be useful for the platform. By the way, we already had an experience implementing solution that resembles lending options (BSIP 70) while developing a credit contract in the other project (Karma).
At first we expect direct payments without an escrow. Later, when the BLCKCHND team will finish their escrow project (which will interact with a number of proxies and respected members of the community), we'll transfer keys from the worker's account to this escrow. This way all acceptance of work and inspections will be conducted through them.
Also, considering the open nature of the development, everyone will be able to inspect and test results of our work. Not to mention our internal testers thoroughly reviewing the code.
This message and Stefan's reply above clearly show that your team doesn't know the platform well enough. Thus, IMHO, your team need someone who has more experience to guide/supervise the development which leads to higher management costs.
-
Maybe it could be an idea to split the worker. Do one now for documentation, code audit and finish releasing version 4. That could be a good introduction of the team, how it operates, what the community can expect and get to know and see everything... Of course this is merely my personal opinion.
Let me know what you guys think, if it's worth spinning more ideas.
-
This message and Stefan's reply above clearly show that your team doesn't know the platform well enough. Thus, IMHO, your team need someone who has more experience to guide/supervise the development which leads to higher management costs.
We believe we know the platform well enough. However, we'll be glad if someone more experienced joins us. For example, we would be happy to invite you. This way you'll be able to influence decisions and directions of the development :)
-
Maybe it could be an idea to split the worker. Do one now for documentation, code audit and finish releasing version 4. That could be a good introduction of the team, how it operates, what the community can expect and get to know and see everything... Of course this is merely my personal opinion.
Let me know what you guys think, if it's worth spinning more ideas.
It's an interesting idea, at least about finishing releasing version 4. We'll consider it and share our thoughts here :)
We welcome other suggestions! Please share if you have them :)