KIP Development Courts on xDai

Development Courts

I propose to create a number of new courts on the xDai version of Kleros for use with Feature (but it can be used for any kind of IT freelancing platform).

Tree of Courts Schema

Namely, I propose to create the following xDai courts with the listed parameters:

xDai Development Court

Parameters

Court name : xDai Development
Parent court : xDai General Court
hiddenVotes : false
Proposed juror fee : 30.0 xDai
Proposed minstake : 1400.0 PNK
Proposed alpha : 0.5
jurorsForCourtJump : 63
timesPerPeriod : [280800,437400,437400,291600]

Description

Court Purpose

In this court, jurors will solve disputes involving the respect of specifications given by the client.

Required Skills

This court requires a good level of programmation. Jurors who are not intermediate developers are advised to stake into this court only if they have some basics of low-level programming languages, ​​algorithmic and knowledge of good practices of development.

Example

Developper does not respect indentation, does not name variables explicitly or has not made a clear file structure. In such cases, jurors should refuse the proposal made by the developer.

xDai Solidity Court

Policies

  • If the disputed code is of significant size (> 500 code lines), parties in the dispute should point out specific parts of the content which are being disputed. Otherwise, jurors should refuse to arbitrate.

Parameters

Court name : xDai Solidity
Parent court : xDai Development
hiddenVotes : false
Proposed juror fee : 30 xDai
Proposed minstake : 1400.0 PNK
Proposed alpha : 0.16
jurorsForCourtJump : 63
timesPerPeriod : [280800,437400,437400,291600]

Description

Required Skills

This court requires a good level of solidity. Jurors who are not solidity intermediate developers are advised to stake into this court only if they also know how to make relatively simple contracts, know the main solidity hacks and can compute the complexity of simple functions.

xDai Javascript Court

Policies

  • If the disputed code is of significant size (> 700 code lines), parties in the dispute should point out specific parts of the content which are being disputed. Otherwise, jurors should refuse to arbitrate.

Parameters

Court name : xDai Javascript
Parent court : xDai Development
hiddenVotes : false
Proposed juror fee : 30 xDai
Proposed minstake : 1400.0 PNK
Proposed alpha : 0.16
jurorsForCourtJump : 63
timesPerPeriod : [280800,437400,437400,291600]

Description

Required Skills

This court requires a good level of javascript. Jurors who are not javascript intermediate developers are advised to stake into this court only if they know the main frameworks/libraries (ExpressJs, React, EthersJs…) and be comfortable with testing, APIs or languages to interact with databases.

[UPDATE]

Changes to alpha, minstakes and juror fees of child courts following feedbacks from @William and @clesaege.

7 Likes

Interesting. One small point on the proposal: minstakes need to be monotonically non-decreasing as you go down a branch of the court tree, as someone who stakes in a court is also staked in its parent court. So if the xDai Development court has a minstake of 1400 PNK, then the other two child courts need to have at least that large of a minstake. If you want to keep the amount of locked PNK per vote the same, you can adjust the alphas accordingly. For example you could have minstake 1400 PNK, alpha .5 for xDai Development, and then minstake 1400 PNK, alpha .16 for xDai Solidity and xDai Javascript.

3 Likes

Having courts to resolve development disputes seems good but the proposed juror fees seems really low. As a software engineer I can’t see myself allocating the time and effort of reading specifications then reviewing code for 22/25 xDai.

1 Like

For an European or an American these prices are not interesting but it’s not necessarily the case for developers from Egypt or Morocco where these services are much lower. See Offshore Developers.

Since on Kleros, there is more a lack of disputes than jurors, it is more interesting to give the low range of arbitration fees so that these fees are not a limiting point to use Kleros as arbitrator.

2 Likes

Hey Nicolas, congratulations on building Feature.sh, it looks really promising!

4 Likes

Thanks! Feature is currently in beta version and free for open-source projects :slight_smile:

3 Likes

I agree that 22 DAI seems pretty low to solve a software dispute. I think a reasonable amount would be 50 DAI. The dapp using it could start with only 1 juror if cost is a concern.

1 Like

3 arguments in favor of a relatively low fee :

  • if the bug (or any non respect with the specifications) is already well identified by the challenger, it can be confirmed relatively quickly;
  • if the majority of the cases are about simple cases: basic ICO smart contract, vesting, multisig… it can be relatively fast to understand and detect the error;
  • finally, the third argument is about the Kleros ecosystem. Low arbitrage fees will tend to favor disputes since the commitment is lower. And I make the hypothesis that some senior developers will indirectly see it as a way to support the Kleros ecosystem even if the arbitration fees are low (meta-incentive).

Afterwards, we can iterate to increase the fees if necessary.

Can we “split” the difference with 30DAI ?

1 Like

We can try with 30 DAI, but in this case I would remove the word “senior” from the skill description.

1 Like

Ok let’s try this set up!

1 Like

The proposal has been put to vote .

5 Likes

Definitely useful!!!

4 Likes

Voted against not because of the general idea of the proposal but because feedback was ignored ($30 minimum + no mention of senior).

1 Like

Yes indeed there was an error when submitting to Snapshot.

The proposal has been withdrawn.

Here is a google document with the version that will be submitted vote, feel free to check it by leaving comments if needed: KIP Snaphshot Developement Courts .

2 Likes

The updated proposal has been put to vote .

2 Likes

Here is a proposal for the Court Policy and the primary document for Feature:

Xdai JS Development Court Policy
Feature - Primary Document

Court Policy

Court Purpose

This court serves to arbitrate development disputes. This can include:

  • Verifying that code proposal complies with the specifications
  • Verifying that code proposal complies with the good development practices
  • Verifying that developer followed the development workflow

Example

  • A dispute about whether a code is buggy or not when running.

Feature - Primary Document

This document details the acceptance criteria of claims submitted to challenge the source code provided by a developer to complete a task.

This policy serves one main purpose:

Ensuring claims who prove that the developer did not follow good development practices or the specifications described by the client.

The jurors are expected to refer to the specificities of each individual cover policy which can be detailed in a README.md, CONTRIBUTING.md, POLICY.md or a specific document included in the specifications. This document is valid only if it was edited before the job was created. In the case of widely used versioning software such as Github, Gitlab or Bitbucket, the date of issue is sufficient evidence to timestamp the document.

In case of any discrepancy between a specific cover policy and this general claims acceptance policy, the specific policy should be considered as the source of truth.

Challenge Claim Acceptance Criteria

The grounds on which a challenge claim is valid are:

  • non-compliance with specifications
  • non-compliance with good development practices
  • non-compliance with development workflow

Compliance with specifications

First of all, the specifications must be detailed enough for us to know whether the developer has completed the task or not. If they are not, the jurors are invited to refuse to vote.

The developer shall provide, if not previously described, the means to functionally test the code.

The first developer to claim the reward and meet the specifications is entitled to receive the award. All subsequent code proposals, even those that improve the code proposal, are entitled to be challenged since it is the first proposal who met the specifications that must be accepted.

Compliance with good development practices

In general, the developer must comply with the implicit rules described by the source code as long as it is consistent and respects recognised conventions and standards.

Failure to comply with one or more of these rules is not enough to make a challenge claim. At the very least, more than 5% of the code should not respect these good practices.

Code style

Ideally, a linter will explicitly describe the rules of the style code as an Eslint or JSCS file for example.

If a formatter has been set up, such as Prettier for example, it will be the responsibility of the developer to run it to format the code within the defined rules.

Indentation

Indentation is usually 2 spaces for javascript but sometimes it can be 4 spaces or a tab. The important thing is that it is consistent and respects the indentation of the blocks.

Statement Rules

For readability, avoid lines longer than 80 characters.

The use of a semicolon to close a statement is optional, depending on the project. The important thing is that this rule is consistent throughout the code.

Spaces

Always put spaces around operators ( = + - * / ), and after commas.

Use one space before the opening bracket.

Naming conventions

Variable names

Identifier names (variables and functions) must use the camelCase naming convention exception made to global constants in UPPERCASE.

Preference should be given to explicit variable names that describe their purpose, avoiding acronyms, generic names and abbreviations that sometimes cause confusion.

File names

Files names must use the naming convention kebab-case or camelCase exception made to component files sometimes in PascalCase or special files like README.md.

Comments

Code comments are not required unless there is complex code that needs to be explained so that it does not take too long to understand.

Architecture

Project structure

Several designs are possible like folders-by-feature, atomic or specific to a framework, the important thing is to have a coherent and consistent structure.

Service architecture

The choice of tools and their orchestration must be made according to the need, for example it would be a mistake to opt for a relational database in a Big Data project with a significant need for data storage.

The architecture must be simple and avoid being overloaded by non-essential services to meet the specificities.

Optimisation and performance

Seeking to optimize performance does not mean that this optimization is detrimental to the readability and maintenance of the code unless it is specified in the specifications that seeking performance is essential.

The ideal is to try to make simple code and avoid any form of over-engineering.

Tests

Writing tests for new features is not necessary unless explicitly requested in the specifications.

They should at least cover passing cases if they are required.

Third software

Avoid unnecessarily adding packages for pieces of code that can simply be written or retrieved so as not to affect the performance, the maintenance and the security of the application.

Compliance with development workflow

Here is the basic workflow for contributing:

  1. Fork the project
  2. Create a branch and work on it
  3. Publish the branch on its fork
  4. Create the pull-request

It will also be necessary if possible to have a clear Git history with short and well named commits (see conventional commits).

You can also comment directly on the google document: https://docs.google.com/document/d/14qWb4sQpvA-NPJEnqHIJu8LmrJeMt7uynt9JqQz2qGg/edit#

5 Likes

This proposal is definitely useful for the ecosystem!

1 Like

Would it be possible to execute the transaction?

2 Likes

Maa goddess mother of everything, loves everyone