Thank you for your interest in contributing to TeachLink! This document provides comprehensive guidelines for contributing to our decentralized knowledge-sharing platform on Stellar.
- Code of Conduct
- Getting Started
- How to Contribute
- Issue Guidelines
- Pull Request Process
- Development Standards
- Review Process
- Recognition & Rewards
By participating in this project, you agree to abide by our Code of Conduct. We are committed to providing a welcoming and inclusive environment for all contributors.
Before contributing, ensure you have:
- Rust toolchain installed with
wasm32-unknown-unknowntarget - Stellar CLI or Soroban CLI installed
- A GitHub account
- Basic understanding of Soroban smart contracts
# Clone the repository
git clone https://github.com/rinafcode/teachLink_contract.git
cd teachLink_contract
# Run environment setup
./scripts/setup-env.sh
# Build the project
cargo build --release --target wasm32-unknown-unknown
# Run tests
cargo testWe welcome various types of contributions:
| Type | Description | Label |
|---|---|---|
| 🐛 Bug Fixes | Fix issues in existing code | bug |
| ✨ Features | Add new functionality | enhancement |
| 📚 Documentation | Improve docs, comments, or examples | documentation |
| 🧪 Tests | Add or improve test coverage | testing |
| 🔧 Tooling | Improve scripts, CI/CD, or DX | tooling |
| 🔒 Security | Security improvements or fixes | security |
| ♿ Accessibility | Improve accessibility | accessibility |
| 🌍 Translation | Translate docs or UI strings | i18n |
| 🤝 Community | Mentoring, answering questions, event hosting | community |
| 🎨 Design | UX, diagrams, visual assets | design |
Non-code contributions are equally valued. Helping newcomers in Discord, writing tutorials, organizing events, and improving documentation all count toward contributor tiers and token rewards.
1. Find or Create an Issue
↓
2. Fork & Create Branch
↓
3. Make Changes
↓
4. Write/Update Tests
↓
5. Run Lints & Tests
↓
6. Submit Pull Request
↓
7. Address Review Feedback
↓
8. Merge! 🎉
- Search existing issues to avoid duplicates
- Check the FAQ and troubleshooting guide
- Gather relevant information (logs, screenshots, reproduction steps)
Use the bug report template and include:
- Clear, descriptive title
- Steps to reproduce
- Expected vs actual behavior
- Environment details (OS, Rust version, CLI version)
- Relevant logs or error messages
Use the feature request template and include:
- Problem statement
- Proposed solution
- Alternative solutions considered
- Additional context
For internal project tasks:
- Clear description of the work
- Acceptance criteria
- Dependencies on other issues
| Label | Description |
|---|---|
priority: critical |
Must be addressed immediately |
priority: high |
Should be addressed in current sprint |
priority: medium |
Should be addressed soon |
priority: low |
Nice to have, no urgency |
good first issue |
Good for newcomers |
help wanted |
Extra attention needed |
blocked |
Waiting on external dependency |
wontfix |
Won't be worked on |
- Create an issue first for significant changes
- Fork the repository and create a feature branch
- Follow naming conventions:
feature/,fix/,docs/,refactor/ - Keep PRs focused - one logical change per PR
- Code follows project style guidelines
- All tests pass (
cargo test) - Lints pass (
cargo fmt && cargo clippy --all-targets --all-features) - Documentation updated if needed
- Commit messages follow conventions
- PR description explains changes clearly
<type>(<scope>): <subject>
<body>
<footer>
Types:
feat: New featurefix: Bug fixdocs: Documentation onlystyle: Code style changesrefactor: Code refactoringtest: Adding/updating testschore: Maintenance tasks
Example:
feat(contract): add learning reward distribution
Implements the reward distribution mechanism for completed lessons.
Tokens are distributed proportionally based on participation score.
Closes #42
- Automated checks run first (CI/CD)
- Code review by at least one maintainer
- Security review for sensitive changes
- Final approval and merge
If this is your first contribution, look for issues labeled good first issue. These are scoped to be approachable without deep project knowledge. Feel free to comment on an issue to claim it before starting work.
- Follow Rust idioms and best practices
- Use
cargo fmtfor formatting - Address all
cargo clippywarnings - Write self-documenting code with clear naming
- Follow naming standards in
docs/NAMING_CONVENTIONS.md - For TypeScript modules, run
npm run lintinindexer/to enforce naming conventions
- All new features must have unit tests
- Bug fixes should include regression tests
- Integration tests for contract interactions
- Minimum 80% code coverage for new code
- Document all public functions with doc comments
- Update README for user-facing changes
- Add inline comments for complex logic
- Include examples in documentation
- Never commit secrets or private keys
- Follow Soroban security best practices
- Report security issues privately (see SECURITY.md)
- Review dependencies for vulnerabilities
| PR Size | Expected Review Time |
|---|---|
| Small (< 50 lines) | 1-2 days |
| Medium (50-200 lines) | 2-3 days |
| Large (200-500 lines) | 3-5 days |
| Extra Large (500+ lines) | 5-7 days |
- Correctness: Does the code work as intended?
- Security: Are there any security concerns?
- Performance: Are there performance implications?
- Maintainability: Is the code easy to understand and maintain?
- Testing: Is the code adequately tested?
- Documentation: Is the code properly documented?
- Be respectful and constructive
- Explain the reasoning behind suggestions
- Distinguish between required changes and suggestions
- Approve promptly when requirements are met
- If your PR has not received a review within the expected timeline, leave a comment pinging
@rinafcode/maintainers. - PRs with no activity for 30 days after review feedback will be marked
staleand closed after a further 7-day notice. You may reopen at any time. - Disagreements between reviewer and author that cannot be resolved in comments should be escalated to a maintainer via Discord
#code-review.
We believe in recognizing and rewarding contributors for their valuable work.
| Tier | Requirements | Badge |
|---|---|---|
| 🌱 Newcomer | First contribution merged | Newcomer Badge |
| 🌿 Contributor | 3+ contributions merged | Contributor Badge |
| 🌳 Regular Contributor | 10+ contributions merged | Regular Badge |
| 🏆 Core Contributor | 25+ contributions + consistent quality | Core Badge |
| ⭐ Maintainer | Invited by existing maintainers | Maintainer Badge |
Each month, we recognize one contributor who has made exceptional contributions.
Selection Criteria:
- Quality of contributions
- Helpfulness in community
- Innovation and creativity
- Code review participation
Contributors with significant impact are featured in our HALL_OF_FAME.md.
Active contributors may be eligible for TEACH token rewards:
| Achievement | Reward |
|---|---|
| First merged PR | 50 TEACH |
| Bug fix | 100-500 TEACH |
| Feature implementation | 500-2000 TEACH |
| Security vulnerability fix | 1000-5000 TEACH |
| Documentation improvements | 50-200 TEACH |
| Monthly MVP | 1000 TEACH |
Token rewards are subject to availability and maintainer approval.
All contributors are listed in:
- CONTRIBUTORS.md - Full contributor list with tiers
- Git commit history
- Release notes for significant contributions
- Contributor tier upgrade: Open a PR updating your entry in CONTRIBUTORS.md with your merged PR count. A maintainer will verify and approve.
- Token rewards: After a PR is merged, comment on it with
@rinafcode/maintainers reward requestand a maintainer will process the allocation. - Hall of Fame nomination: Open a Hall of Fame discussion using the nomination template. Nominations are reviewed quarterly.
- 💬 Discord: Join our community
- 📧 Email: contributors@teachlink.io
- 🐦 Twitter: @TeachLinkDAO
- 📖 Documentation: docs.teachlink.io
By contributing to TeachLink, you agree that your contributions will be licensed under the MIT License.
Thank you for contributing to TeachLink! Together, we're building the future of decentralized education. 🎓