Author Topic: [Worker Proposal] BitShares Core Team Worker Proposal from Graphene Lab  (Read 14293 times)

0 Members and 1 Guest are viewing this topic.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano

It's OpenLedger.


No, it's not OL.
Not going to mention names here, but it wasn't anyone from the Graphene Lab team.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.

Quote

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.
« Last Edit: December 21, 2019, 01:56:04 am by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline graphenelab

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

Offline bitcrab

  • Committee member
  • Hero Member
  • *
  • Posts: 1928
    • View Profile
  • BitShares: bitcrab
  • GitHub: bitcrab
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...

Email:bitcrab@qq.com

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
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.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline graphenelab

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/

Offline graphenelab

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.

Offline bitcrab

  • Committee member
  • Hero Member
  • *
  • Posts: 1928
    • View Profile
  • BitShares: bitcrab
  • GitHub: bitcrab
possible to share the developers' github accounts?
Email:bitcrab@qq.com

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.
BitShares committee member: abit
BitShares witness: in.abit

Offline sschiessl

  • Administrator
  • Hero Member
  • *****
  • Posts: 662
    • View Profile
  • BitShares: sschiessl
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!

Offline graphenelab

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.

Offline sschiessl

  • Administrator
  • Hero Member
  • *****
  • Posts: 662
    • View Profile
  • BitShares: sschiessl
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?

Offline graphenelab

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.

Offline graphenelab

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.

Offline graphenelab

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 :)