Summary:
This proposal aims to amend the descriptions of the following courts:
-
xDai Development Court
-
xDai Solidity Court
-
xDai Javascript Court
Motivation:
The existing descriptions contain typos, grammar mistakes and lack clarity in the English language.
Rationale:
The modifications are intended to:
- Rectify grammar mistakes
- Offer a more comprehensive explanation of the courts’ purposes by broadening their scope. Whereas the previous versions stated the courts’ purpose as ruling on disputes regarding compliance with specifications provided by a client, the revised descriptions now extend to cover any software development-related dispute. Also, they are not limited to disputes arising from failure to comply with specifications provided by a client but also including those from other third parties. For example, disputes may arise between partners who have agreed to allocate personal resources and time to a new project, where one party fails to meet expectations.
- The amendments also aim to outline some really basic rules for these courts under the “policy” title, while providing examples of what may constitute good practices in software development. However, it is emphasized that explicitly agreed-upon specifications should govern these cases, and jurors should use their reasonable criteria, based on their experience and understanding of best practices, to resolve disputes. These amendments do not aim to establish detailed rules at this stage, but such may be considered if future court activity justifies providing a more detailed and separate policy.
Specification:
If this proposal is approved, the description of the xDai Development Courts will be as follows:
xDai Development Court | Min Stake = 7,400 stPNK
Each vote has a stake of 3,700 stPNK.Court purpose
This court serves to arbitrate disputes arising from software development processes, including disputes between developers and third parties regarding whether the disputed software product aligns with the agreed specified requirements.Policy
- Jurors must base their rulings on the software specifications mutually agreed upon by the involved parties prior to the initiation of the dispute.
Example: A written and signed agreement between a developer and her client, or messages exchanged by the parties agreeing on the desired specifications for the final code.
- Unless agreed otherwise between the parties, the jurors must apply the following criteria:
a. Issues which do not put assets at risk nor directly affect the essential system functionalities are acceptable, especially with regards to functional, security, usability and performance issues. Issues which indirectly lead to the same impact must be supported by evidence demonstrating a valid execution path.
Example 1: A suboptimal gas usage for a smart contract implementation is acceptable unless excessively wasteful in a way that hinders usability.
Example 2: An issue directly leading to a temporary disruption of a core functionality is not acceptable.
b. Minor deviations from best practices are acceptable, including but not limited to architectural decisions, tooling choices, or coding hygiene, unless such deviations breach section 2.a.
Example 1: A codebase which mostly does not follow a consistent indentation or variable naming convention is not acceptable.
Example 2: Best practices (such as KISS, YAGNI, DRY, SOLID, SoC, Low Coupling/High Cohesion) do not apply equally to every type of software project, so a smart contract codebase that does not follow DRY to better adhere to KISS is acceptable.
c. Issues solely related to accessibility, modularity, interoperability, or other unspecified requirements must be disregarded.
- In instances where there are no explicitly agreed specifications that apply to the contested deliverable or if the parties provide contradictory evidence on the agreed specifications and there is no certainty on the authenticity of the presented evidence, jurors must rule considering:
a. The nature of the agreement between the developer and the third party;
b. The specificities of the software being developed; and
c. Best practices in software development that are applicable to the specific type of software being developed.Required Skills
This court requires a good level of programming proficiency. Jurors are advised to participate in this court only if they possess an intermediate understanding of programming languages, algorithms, and good practices in software development.
Reward
For each coherent vote you will receive 30.00 xDAI.
xDai Solidity Court | Min Stake = 7,400 stPNK
Each vote has a stake of 3,700 stPNK.
Court purpose
This court serves to arbitrate disputes arising from software development processes using the programming language Solidity, including disputes between developers and third parties regarding whether the disputed software product aligns with the agreed specified requirements.
Policy
The parties involved in the dispute must highlight the sections or portions of the code that are being contested. Otherwise, jurors must refuse to arbitrate the dispute.
Required Skills
This court requires a proficient level of expertise in Solidity. Jurors are advised to participate in this court only if they possess the ability to develop relatively simple smart contracts, understand common Solidity security vulnerabilities, and evaluate the time and space complexity of simple functions.
Reward
For each coherent vote you will receive 30.00 xDAI.
xDai Javascript Court | Min Stake = 7,400 stPNK
Each vote has a stake of 3,700 stPNK.
Court purpose
This court serves to arbitrate disputes arising from software development processes using the programming language Javascript, including disputes between developers and third parties regarding whether the disputed software product aligns with the agreed specified requirements.
Policy
The parties involved in the dispute must highlight the sections or portions of the code that are being contested. Otherwise, jurors must refuse to arbitrate the dispute.
Required Skills
This court requires a proficient level of expertise in JavaScript. Jurors are advised to participate in this court only if they have an intermediate level of knowledge of the main frameworks and libraries (such as ExpressJS, React, Ethers.js, etc.), and are comfortable with testing, working with APIs, and interacting with databases using various languages.
Reward
For each coherent vote you will receive 30.00 xDAI.