Reward Guidelines

Introduction

Welcome to the Conflux Contribution Reward Guidelines. Our mission is to build a robust, accessible, and community-driven platform, and your contributions are integral to achieving this vision. Whether you are an experienced developer, a technical writer, a first-time contributor, or simply an enthusiast, your insights, ideas, and improvements can make a significant impact. Understanding that every effort put toward enhancing the Conflux environment deserves recognition, we've implemented a reward system based on FansCoin (FC).

This article details how your contributions, categorized under 'Issues' and 'Pull Requests', are rewarded. You will learn how identifying problems or presenting enhancements in various aspects—ranging from formatting and readability to error identification—is rewarded. With your support, Conflux continues to evolve and improve by the day.

Guidelines

Issues Reward Guidelines

Creating issues is an excellent way for us to understand the needs of the community and identify areas for improvement. Issues created will be tagged as either ACCEPTED or REJECTED, indicating our assessment of whether the content is suitable for further action.

• Formatting
  • Identifying spelling or grammar errors: 16 FC
  • Spotting broken links: 16 FC
  • Highlighting issues with code blocks, localization or other format-related problems: 32 FC
  • Flagging format issues with images, diagrams: 24 FC, or 48 FC if a solution is proposed (not necessarily a pull request).
• Error Identification
  • Spotting outdated product information: 32 FC.
  • Discovering errors or incorrect information about technical or conceptual details: 80 FC. This encapsulates
    • Issues with descriptions, such as explanatory concepts, API document parameters, characteristics of features, and so forth.
    • Issues with code that can be reproduced on a general or specific platform, including failing sample code, unexpected code output, or failing commands.
• Suggesting Improvements
  • Recommending enhancements to certain topics to simplify understanding or provide more detail: From 32 FC to 64 FC depending on the issue significance and whether a solution is proposed (not necessarily a pull request). This encapsulates
    • Highlighting unclear explanation
    • Recommending creation or improvement of diagrams, charts, or visual aids
    • Highlighting insufficient contextual information (explanations or examples) leading to comprehension issues
    • Indicating a lack of detailed description of a feature, such as implementation or edge cases.
  • Proposing the development of new articles on particular topics or product: From 32 FC to 64 FC depending on the issue significance.
  • Suggesting improve the document structure: 32 FC for valuable, but not necessarily ACCEPTED solutions, or 64 FC if accepted. NOTE: We will carefully consider these issues.
  • Highlighting current governance shortcomings: Determined case by case.
• Document Website Code Issues
  • Front-end style issues including layout, font size, line spacing, etc: 48 FC, or 96 FC with a suggested solution (not necessarily a pull request)
  • Recommending specific components for certain functions: 96 FC.
  • Other issues: Determined case by case.

Pull Requests Reward Guidelines

Reward values for pull requests are primarily determined by the complexity and significance of the content. Please refer to rewards evaluation for more details on value determination.

• If the originator of the pull request solves an issue they raised, an additional reward of 25% is granted.
• Formatting:
  • Fixing spelling or grammar errors: 16 FC.
  • Updating broken links: 16 FC.
  • Resolving issues with code blocks or other formatting: 32 FC.
  • Rectifying formatting issues with images, diagrams: 64 FC.
• Error Resolution
  • Updating outdated product information: 64 FC, up to 128 FC or more, determined by content and significance.
  • Offering correct explanations, such as explanatory concepts, API document parameters, characteristics of features, and so forth: From 64 FC, up to 128 FC or more, determined by content and significance.
  • Correcting code-related errors, which can be reproduced on a general or specific platform, including failing sample code, unexpected code output, or failing commands: From 64 FC, up to 320 FC or more, depending on content and significance.
• Improvements
  • Improvements relating to issues with LONG TERM label, for example, adding glossaries, article labels, article keywords, etc: From 32 FC, determined by content and significance.
  • Enhancements to certain topics to simplify understanding, e.g. providing clearer explanation or added examples: From 32 FC, up to 128 FC or even more, determined by content and significance.
  • Creating or improving visual aids like diagrams, charts: From 128 FC, up to 256 FC or more, determined by content and significance.
  • Adding lacked details of a feature or a topic, such as implementation or edge cases: From 80 FC, up to 320 FC or even more, determined by content and significance.
  • Crafting new articles on certain topic, depending on complexity and community need: From 128 FC, up to 640 FC, determined by content and significance, potentially more for tremendous articles.
    • if the article is about general concept or development practice, the reward will typically range from 128 FC to 320 FC.
    • if the topic is Conflux-specific or the article is a development guide, the reward will range from 320 FC to 640 FC (or even higher).
  • Crafting user guides for the basic usage of Conflux products: 320 FC, up to 480 FC or more, determined by content and significance.
• Document Website Improvements
  • With a minimum of 96 FC, determined case-by-case based on task complexity.

Rewards Evaluation and Examples

With pull request rewards often being determined on a case-by-case basis, we believe it's important to provide contributors with a clear understanding of how these rewards are assessed.

• The significance of the content that has been created. In particular, we regard the following types of content as being of greater importance:
  • Content specific to Conflux
  • Content that developers are more likely to visit
  • Development tutorials accompanied by ready-to-use code examples
• The complexity of the pull request along with the effort invested also affect the reward:
  • Content that required more time to create (evaluated based on content quality)
  • Higher technical skills or understanding required
  • Clear explanation, e.g., inclusion of code snippets or visual aids

Several examples are provided below for your reference:

Pull Request	Guideline Base Reward	Anticipated Reward	Content	Justification
PR#494	128	320*125%	New article on reentrancy attack	- Significant content (common security issue) + Includes code sample + Resolves issue raised by creator + Provides clear explanation on the topic
PR#493	128	196*125%	New article on circuit logic gas cost	* Includes code + Resolves issue raised by creator + Provides clear explanation on the topic - Content of less importance
PR#473	32	80	Suggests usage of Confura API key	- Provides important clarification + Adds to frequently used content
PR #467	96	150*125%	Improves website display for mobile devices	* Requires front-end technique + Resolves issue raised by creator
PR #425	320	640	Offers an out-of-the-box sample project for eSpace development	- Is Conflux-specific content + Includes code demonstration + Provides a detailed explanation and video tutorial + Offers a ready-to-use project out of the box

note

The 'Anticipated Reward' is an estimated figure of the FC that contributors might receive, according to our most recent reward guidelines. However, please keep in mind that the actual reward amount may vary. This variation could be due to the contributor being an internal member of our team, or due to changes made to our contribution guidelines.

Reward Distribution Process

We track rewards using an internal Notion table and the results will be regularly posted in our Github discussions.

Rewards are distributed on a regular basis, at least once every three months. We aim to refine our workflow to reduce this interval over time.

Regular Evaluation of Reward Guidelines

It's important to note that our reward guidelines are reviewed, and potentially revised, after each round of reward distribution. This ensures that our guidelines remain up-to-date and effective in encouraging and rewarding useful contributions.

We greatly appreciate your contributions and thank you for aiding us in enhancing our documentation site! If you have any queries or require support, please don't hesitate to open an issue in our Github repository.