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

Quote from: graphenelab on December 25, 2019, 08:26:04 pm

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/

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.

Quote from: graphenelab on December 25, 2019, 08:26:04 pm

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

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

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.

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.

Quote

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

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