|
| 1 | +# Contributing to Oracle Contracts |
| 2 | + |
| 3 | +This guide explains how to contribute to the Oracle Contracts project, covering everything from setting up your development environment to submitting pull requests. |
| 4 | + |
| 5 | +## Development Setup |
| 6 | + |
| 7 | +### Prerequisites |
| 8 | +- Node.js >= 16 |
| 9 | +- Git |
| 10 | +- npm or yarn |
| 11 | +- Hardhat development environment |
| 12 | + |
| 13 | +### Initial Setup |
| 14 | + |
| 15 | +1. Fork the repository on GitHub: |
| 16 | + - Visit [razor-network/contracts](https://github.com/razor-network/contracts) |
| 17 | + - Click the 'Fork' button |
| 18 | + - Clone your fork locally: |
| 19 | + ```bash |
| 20 | + git clone [email protected]:YourLogin/contracts.git |
| 21 | + cd contracts |
| 22 | + ``` |
| 23 | + |
| 24 | +2. Install dependencies: |
| 25 | + ```bash |
| 26 | + npm install |
| 27 | + # or |
| 28 | + yarn install |
| 29 | + ``` |
| 30 | + |
| 31 | +3. Add upstream remote: |
| 32 | + ```bash |
| 33 | + git remote add upstream [email protected]:razor-network/contracts.git |
| 34 | + ``` |
| 35 | + |
| 36 | +## Development Workflow |
| 37 | + |
| 38 | +### 1. Branch Management |
| 39 | + |
| 40 | +Always create a feature branch for your work: |
| 41 | +```bash |
| 42 | +# Sync with upstream |
| 43 | +git checkout master |
| 44 | +git pull upstream master |
| 45 | + |
| 46 | +# Create feature branch |
| 47 | +git checkout -b feature/your-feature-name |
| 48 | +``` |
| 49 | + |
| 50 | +### 2. Development Process |
| 51 | + |
| 52 | +1. Make your changes in the feature branch |
| 53 | +2. Follow the code style guidelines |
| 54 | +3. Add tests for new functionality |
| 55 | +4. Ensure all tests pass |
| 56 | +5. Update documentation as needed |
| 57 | + |
| 58 | +### 3. Testing Requirements |
| 59 | + |
| 60 | +Run the full test suite before submitting: |
| 61 | +```bash |
| 62 | +# Run all tests |
| 63 | +npm test |
| 64 | + |
| 65 | +# Run specific test scenarios |
| 66 | +npm run scenarios |
| 67 | + |
| 68 | +# Check test coverage |
| 69 | +npm run coverage |
| 70 | +``` |
| 71 | + |
| 72 | +Coverage requirements: |
| 73 | +- Statements: 90% |
| 74 | +- Branches: 60% |
| 75 | +- Functions: 85% |
| 76 | +- Lines: 86% |
| 77 | + |
| 78 | +### 4. Code Quality |
| 79 | + |
| 80 | +Maintain code quality by running: |
| 81 | +```bash |
| 82 | +# Run all linters |
| 83 | +npm run lint |
| 84 | + |
| 85 | +# Fix linting issues |
| 86 | +npm run lint:fix |
| 87 | + |
| 88 | +# Run specific linters |
| 89 | +npm run lint:sol # Solidity files |
| 90 | +npm run lint:js # JavaScript files |
| 91 | +``` |
| 92 | + |
| 93 | +## Code Style Guidelines |
| 94 | + |
| 95 | +### Solidity Style Guide |
| 96 | + |
| 97 | +1. **Contract Structure** |
| 98 | + ```solidity |
| 99 | + // SPDX-License-Identifier: UNLICENSED |
| 100 | + pragma solidity ^0.8.0; |
| 101 | +
|
| 102 | + contract MyContract { |
| 103 | + // State variables |
| 104 | + // Events |
| 105 | + // Modifiers |
| 106 | + // Constructor |
| 107 | + // External functions |
| 108 | + // Public functions |
| 109 | + // Internal functions |
| 110 | + // Private functions |
| 111 | + } |
| 112 | + ``` |
| 113 | + |
| 114 | +2. **Naming Conventions** |
| 115 | + - Contracts: PascalCase |
| 116 | + - Functions: camelCase |
| 117 | + - Variables: camelCase |
| 118 | + - Events: PascalCase |
| 119 | + - Modifiers: camelCase |
| 120 | + |
| 121 | +3. **Documentation** |
| 122 | + - Use NatSpec format for all public interfaces |
| 123 | + - Document parameters and return values |
| 124 | + - Explain complex logic |
| 125 | + ```solidity |
| 126 | + /// @notice Brief description |
| 127 | + /// @dev Detailed description |
| 128 | + /// @param name Description of parameter |
| 129 | + /// @return Description of return value |
| 130 | + ``` |
| 131 | + |
| 132 | +### JavaScript Style Guide |
| 133 | + |
| 134 | +1. **File Structure** |
| 135 | + - Use ES modules (import/export) |
| 136 | + - One class/component per file |
| 137 | + - Clear file naming |
| 138 | + |
| 139 | +2. **Code Formatting** |
| 140 | + - Use prettier for consistent formatting |
| 141 | + - 2 space indentation |
| 142 | + - Semicolons required |
| 143 | + - Single quotes for strings |
| 144 | + |
| 145 | +## Pull Request Process |
| 146 | + |
| 147 | +1. **Before Submitting** |
| 148 | + - Sync with upstream master |
| 149 | + - Run all tests |
| 150 | + - Check code coverage |
| 151 | + - Run linters |
| 152 | + - Update documentation |
| 153 | + |
| 154 | +2. **Creating the PR** |
| 155 | + ```bash |
| 156 | + git add . |
| 157 | + git commit -m "feat: description of your changes" |
| 158 | + git push origin feature/your-feature-name |
| 159 | + ``` |
| 160 | + |
| 161 | +3. **PR Guidelines** |
| 162 | + - Use conventional commit messages |
| 163 | + - Include tests for new features |
| 164 | + - Update relevant documentation |
| 165 | + - Link related issues |
| 166 | + - Provide clear description of changes |
| 167 | + |
| 168 | +4. **PR Template** |
| 169 | + ```markdown |
| 170 | + ## Description |
| 171 | + Brief description of changes |
| 172 | + |
| 173 | + ## Type of change |
| 174 | + - [ ] Bug fix |
| 175 | + - [ ] New feature |
| 176 | + - [ ] Breaking change |
| 177 | + - [ ] Documentation update |
| 178 | + |
| 179 | + ## Checklist |
| 180 | + - [ ] Tests added/updated |
| 181 | + - [ ] Documentation updated |
| 182 | + - [ ] Code follows style guidelines |
| 183 | + - [ ] All tests passing |
| 184 | + ``` |
| 185 | + |
| 186 | +## Smart Contract Development |
| 187 | + |
| 188 | +### 1. Contract Modifications |
| 189 | + |
| 190 | +When modifying contracts: |
| 191 | +1. Update interfaces if needed |
| 192 | +2. Add new tests |
| 193 | +3. Update deployment scripts |
| 194 | +4. Document changes in NatSpec |
| 195 | + |
| 196 | +### 2. Testing Guidelines |
| 197 | + |
| 198 | +1. **Test Structure** |
| 199 | + ```javascript |
| 200 | + describe("Contract", () => { |
| 201 | + before(() => { |
| 202 | + // Setup |
| 203 | + }); |
| 204 | + |
| 205 | + it("should do something", async () => { |
| 206 | + // Test |
| 207 | + }); |
| 208 | + }); |
| 209 | + ``` |
| 210 | + |
| 211 | +2. **Test Coverage** |
| 212 | + - Happy path scenarios |
| 213 | + - Edge cases |
| 214 | + - Error conditions |
| 215 | + - Access control |
| 216 | + - State transitions |
| 217 | + |
| 218 | +### 3. Gas Optimization |
| 219 | + |
| 220 | +1. Run gas analysis: |
| 221 | + ```bash |
| 222 | + npm run gas |
| 223 | + ``` |
| 224 | + |
| 225 | +2. Compare gas usage: |
| 226 | + ```bash |
| 227 | + npm run gasCompare |
| 228 | + ``` |
| 229 | + |
| 230 | +## Documentation |
| 231 | + |
| 232 | +### 1. Code Documentation |
| 233 | +- Use NatSpec comments for all public interfaces |
| 234 | +- Document complex algorithms |
| 235 | +- Explain security considerations |
| 236 | +- Update API documentation |
| 237 | + |
| 238 | +### 2. Technical Documentation |
| 239 | +- Update relevant .md files |
| 240 | +- Keep diagrams current |
| 241 | +- Document breaking changes |
| 242 | +- Update examples |
| 243 | + |
| 244 | +## Getting Help |
| 245 | + |
| 246 | +1. **Resources** |
| 247 | + - [Project Documentation](docs/README.md) |
| 248 | + - [Core Concepts](docs/core-concepts.md) |
| 249 | + - [API Reference](docs/api-reference.md) |
| 250 | + |
| 251 | +2. **Community** |
| 252 | + - GitHub Issues |
| 253 | + - Development chat |
| 254 | + - Technical discussions |
| 255 | + |
| 256 | +## Related Documentation |
| 257 | +- [Architecture Overview](architecture.md) |
| 258 | +- [Setup Guide](setup-and-installation.md) |
| 259 | +- [API Reference](api-reference.md) |
| 260 | +- [Core Concepts](core-concepts.md) |
0 commit comments