# Contribution Guidelines

## Development Contribution Process

### Fork the project repository

If you want to participate in the development of the BTFCoin project as a code developer, the first step is to visit the official repository page of the project on GitHub (or other designated code hosting platforms) and click the "Fork" button, which will create a complete copy of the project under your personal account. This copy is independent of the main project repository, allowing you to freely carry out development work without affecting the main code base, and is also the basis for submitting personal contribution results back to the main project. For example, if you plan to optimize the smart contract module of BTFCoin, the Fork operation can quickly build a dedicated development "test field" for you.

### Create a branch specification

Based on the forked repository, when creating a development branch, you must strictly follow the specifications to clearly trace and manage code changes. Branch naming should be guided by functional modules or issues to be fixed, using the "function name - brief description" or "fix / problem keyword" format. For example, if you are committed to improving the performance of the trading engine, the branch can be named "trade-engine-performance-optimization"; if you are fixing the transaction fee calculation vulnerability, it can be "fix/fee-calculation-bug". This ensures that team members can clearly understand the purpose of the branch at a glance, which is conducive to collaboration and code review.

### Local development environment construction

* Installation of dependent libraries: Refer to the "README" file or the dedicated "dependency-list.md" document provided in the project root directory to install the required dependent libraries in order. Web3.js is used for smart contract interaction, specific machine learning frameworks (such as TensorFlow or PyTorch adapted for blockchain data processing) and distributed computing related libraries (such as libraries for node communication and resource scheduling). They must be installed precisely according to the version requirements to ensure code compatibility.
* Database configuration: Configure an appropriate database based on the architecture. If it is the underlying data storage of the blockchain, use a key-value database such as LevelDB, and set the storage path, cache parameters, etc. according to the configuration guide; for transaction data and user information storage, combine with relational databases such as MySQL or PostgreSQL, and configure the connection string, user permissions, table structure initialization script execution and other steps in detail to lay a solid foundation for data persistence and efficient query.

### Example of coding and compliance

* Coding style uniformity requirements: BTFCoin follows the industry mainstream and project-customized coding style, uniformly uses 4 spaces for code indentation, braces are placed on new lines, functions and variables are named in camel case (such as "calculateTransactionFee" and "userBalance"), and the meaning clearly reflects the function or data connotation. The header of the code file must indicate the copyright information, file creation date, author and brief function overview to facilitate tracing the code ownership and initial intention.
* Function annotation template: Open the "src/transaction/feeCalculator.js" file in the local editor. Write optimized code according to the standard indentation and naming. For example, the original calculation function:

```javascript
function calculateFee(amount) {
    return amount * 0.01; // Simply calculate the handling fee at 1%
}
```

The function is optimized to consider segmented billing of transaction amounts and discounts based on user levels. The code is as follows:

```javascript
/**
* Function: Calculate transaction fee based on transaction amount and user level.
* Parameters:
* amount (number): transaction amount.
* userLevel (string): user level, value is "basic", "premium", "vip".
* Return value:
* number: calculated transaction fee amount.
* Exception handling:
* If the type of the passed parameter does not match, throw a TypeError exception.
*/
function calculateFee(amount, userLevel) {
    if (typeof amount!== 'number' || typeof userLevel!== 'string') {
        throw new TypeError('Wrong parameter type');
    }
    let baseFee;
    if (amount <= 1000) {
        baseFee = amount * 0.005;
    } else if (amount <= 5000) {
        baseFee = amount * 0.008;
    } else {
        baseFee = amount * 0.01;
    }
    let discountRate;
    if (userLevel === 'basic') {
        discountRate = 1;
    } else if (userLevel === 'premium') {
        discountRate = 0.9;
    } else if (userLevel === 'vip') {
        discountRate = 0.8;
    }
    return baseFee * discountRate;
}
```

After writing, execute local unit tests (project test framework and test case set, through the "npm run test" command) to ensure normal functionality and fix test errors.

### Pull Request example

After local development and testing is completed, submit the code to the branch, execute "git add." to add all changed files, and submit it with "git commit -m "Optimize transaction fee calculation, support segmented billing and user level discounts"" and attach clear instructions.

Then push the branch to GitHub，“git push origin fix/transaction-fee-optimization”。

Go to the GitHub page, switch to the branch, click the "Compare & pull request" button, and describe in detail the purpose of this optimization (improving the rationality of fee calculation and adapting to different user needs), implementation method (a brief description of code logic), and test status (local test passed) on the PR page. After submission, wait for the project reviewer to review and feedback, revise according to the feedback, and submit again until the code is merged into the main project.

### Non-code contribution channels

Markdown format followed: The project documents are uniformly in standard Markdown format, with "#" used to distinguish the number of titles at each level (such as "# first-level title" "## second-level title"), "-" or "1." used to identify the order of lists, and "wrapped and indicated with the language type" used for code blocks.

### Content section update guide

According to the project document structure, for example, the "Technical Documentation" section should focus on the latest technical implementation details and algorithm changes; the "User Guide" section should add new operation steps and troubleshooting methods as product functions are iterated; the "Project Progress" section should record milestone results and cooperation dynamics in a timely manner. When updating, indicate the version number, update date and author to facilitate team members to identify information timeliness and responsibility traceability.

### Multi-language adaptation process:&#x20;

In response to different language translation needs, we first start with the core terminology library of the project, extract terms such as "BTF Coin", "Blockchain", "Smart Contract", etc., unify and standardize the translation version (such as the corresponding Chinese expression), and establish a terminology comparison table. Based on this, the translation document is broken down by chapters and claimed by volunteers whose mother tongue is the target language and who are familiar with the blockchain field. After the first draft is completed, it is reviewed by bilingual proofreaders for grammar and terminology consistency, and then integrated back into the project multi-language document library, and the multi-language switching display on the web and mobile terminals is realized with the help of tools.
