-
Notifications
You must be signed in to change notification settings - Fork 0
CONTRIBUTING_GUIDE.md
Version: 1.0 Project: CeloHT
This guide explains how contributors can participate in CeloHT repositories.
Contributions may include:
- Code
- Documentation
- Design
- Education
- Testing
- Research
- Security improvements
- Community resources
CeloHT contributions should prioritize:
- Quality
- Security
- Transparency
- Maintainability
- Accessibility
- Community value
Contributors should:
- Read the repository README.
- Review relevant documentation.
- Search existing issues.
- Check open pull requests.
- Understand the architecture.
- Avoid duplicating existing work.
Idea
│
▼
Issue / Discussion
│
▼
Agreement on Scope
│
▼
Branch
│
▼
Implementation
│
▼
Testing
│
▼
Pull Request
│
▼
Review
│
▼
CI
│
▼
Merge
Good issues should contain:
- Clear title
- Problem description
- Expected behavior
- Actual behavior
- Reproduction steps where applicable
- Relevant screenshots or logs
- Environment information
Feature requests should explain:
- The problem
- The proposed solution
- Expected users
- Expected benefit
- Potential risks
Recommended:
feature/description
fix/description
docs/description
refactor/description
test/description
security/description
Pull requests should:
- Have a focused scope.
- Include tests where appropriate.
- Update documentation where necessary.
- Avoid unrelated changes.
- Pass required CI checks.
Reviewers should evaluate:
- Correctness
- Security
- Maintainability
- Performance
- Accessibility
- Tests
- Documentation
Review should focus on the code and its impact, not the person who wrote it.
Security vulnerabilities should not be disclosed publicly before the project has had an opportunity to investigate them.
Follow the repository SECURITY.md process.
Smart-contract changes require additional scrutiny.
Review should consider:
- Access control
- State transitions
- External calls
- Reentrancy
- Arithmetic
- Upgradeability
- Event emissions
- Gas implications
- Failure behavior
Documentation should be:
- Accurate
- Current
- Clear
- Structured
- Reproducible
Technical documentation should avoid unsupported claims.
Contributors should add tests when changes affect:
- Business logic
- APIs
- Smart contracts
- Financial calculations
- Authentication
- Authorization
- Database operations
Use descriptive commits.
Examples:
feat: add community dashboard
fix: handle failed wallet transaction
docs: update blockchain architecture
test: cover agent registration
A pull request should normally be merged only after:
- Required reviewers approve it.
- CI passes.
- Security concerns are resolved.
- Required documentation is updated.
Contributors are responsible for:
- Testing their work
- Disclosing relevant limitations
- Following security rules
- Responding to review feedback
- Avoiding accidental secrets
- Keeping changes focused
Maintainers should:
- Review contributions fairly.
- Protect project security.
- Maintain documentation.
- Keep CI healthy.
- Communicate decisions.
- Remove obsolete code where appropriate.
CeloHT welcomes constructive participation.
Contributors should communicate professionally and respectfully.
Harassment, malicious behavior, intentional disruption, and security abuse are not acceptable.
[ ] Issue/discussion reviewed
[ ] Scope understood
[ ] Branch created
[ ] Code/documentation completed
[ ] Tests added or updated
[ ] Security considered
[ ] Documentation updated
[ ] CI passes
[ ] Pull request description complete
Document: Contribution Guide Version: 1.0 Project: CeloHT
© 2026 CeloHT - Open Source. Global Impact. Licensed under Apache.