Thank you for your interest in contributing to DKIM Verifier! This document outlines our Tri-Perimeter Contribution Framework (TPCF) and how to get involved.
We use a graduated trust model with three perimeters:
Anyone can contribute here without special permissions
- Bug Reports: Open issues for bugs, feature requests
- Discussions: Participate in GitHub Discussions
- Documentation: Suggest improvements via issues
- Translations: Submit translation updates
- Testing: Test beta versions and provide feedback
- Code Review: Comment on pull requests
Access: Public, no approval needed Scope: Read-only access, issue creation, discussions Review: Maintainers review all contributions
Contributors who have demonstrated sustained, quality contributions
- Pull Requests: Direct PR submissions
- Code Changes: Implement features, fix bugs
- Test Development: Add unit/integration tests
- Documentation Editing: Direct doc improvements
- Triage: Help triage and label issues
How to Advance:
- 3+ quality contributions accepted from Perimeter 3
- Demonstrated understanding of codebase and standards
- Positive community interactions
- Maintainer nomination
Access: Write access to feature branches, PR creation Scope: All repos, except main/release branches Review: Maintainer approval required for merge
Core maintainers with full repository access
- Release Management: Cut releases, manage versions
- Merge to Main: Approve and merge PRs
- Security Response: Handle security vulnerabilities
- Governance: Make project decisions
- Infrastructure: Manage CI/CD, hosting
Current Maintainers: See MAINTAINERS.md
How to Advance:
- Sustained contributions over 6+ months
- Deep expertise in email security / WebExtensions
- Unanimous approval from existing maintainers
- Demonstrated leadership and mentorship
Access: Full repository access, release permissions Scope: All operations including security-sensitive Review: Peer review from other maintainers
- Check Issues: See if someone is already working on it
- Open Discussion: For large features, discuss first
- Read CLAUDE.md: Understand project architecture
- Review Roadmap: See ROADMAP.md for planned features
- Language: JavaScript ES2024, TypeScript checking via JSDoc
- Style: Follow existing conventions (enforced by ESLint)
- Types: Add comprehensive JSDoc type annotations
- Tests: Add tests for new functionality
- Docs: Update documentation for user-facing changes
-
Fork & Clone
git clone https://github.com/YOUR_USERNAME/dkim_verifier.git cd dkim_verifier -
Create Feature Branch
git checkout -b feature/your-feature-name
-
Make Changes
- Follow code conventions (see CLAUDE.md)
- Add
// @ts-checkto new .mjs.js files - Use tabs (4 spaces width) for indentation
- Double quotes for strings
- Semicolons required
-
Run Checks
npm run lint # ESLint (zero warnings required) npm run checkJs # TypeScript type checking npm run test # Unit tests
-
Commit
git add . git commit -m "Brief description of changes"
- Use clear, descriptive commit messages
- Reference issue numbers:
Fixes #123
-
Push & PR
git push origin feature/your-feature-name
- Open Pull Request on GitHub
- Fill out PR template completely
- Link related issues
Must Have:
- ✅ All CI checks passing (lint, type check, tests)
- ✅ Descriptive title and description
- ✅ Tests for new code (aim for >80% coverage)
- ✅ Documentation updates if user-facing
- ✅ No merge conflicts with main branch
Nice to Have:
- 📝 Screenshots/GIFs for UI changes
- 📝 Performance benchmarks for optimizations
- 📝 Migration guide for breaking changes
Use the Bug Report Template
Include:
- Thunderbird Version: From Help → About
- Extension Version: From Add-ons Manager
- Steps to Reproduce: Detailed, numbered steps
- Expected Behavior: What should happen
- Actual Behavior: What actually happens
- Error Console: Any errors from Tools → Error Console
- Sample Email: If possible, provide .eml file (redact sensitive info)
Use the Feature Request Template
Include:
- Problem Statement: What problem does this solve?
- Proposed Solution: How should it work?
- Alternatives: Other approaches considered
- Use Case: Real-world scenario
- Impact: Who benefits? How many users?
See _locales/Readme.md for details.
- Check Existing: See if your language already exists
- Reference Locale: Use
_locales/en_US/messages.json - Submit PR: Add/update
_locales/YOUR_LOCALE/messages.json - Test: Load extension in Thunderbird with your locale
Current Languages: 15 supported Priority Languages: German, French, Spanish, Japanese, Chinese
All documentation lives in:
README.md- Project overviewCLAUDE.md- AI assistant / developer guideROADMAP.md- Feature roadmaptest/Readme.md,_locales/Readme.md- Component docs- Wiki - User guide
Small Fixes: Direct PR Large Changes: Open issue first for discussion
npm run test # Run in Node.js
npm run test:ci # CI mode with JSON outputBrowser Testing:
npx http-server . -c-1
# Open: http://localhost:8080/test/unittest/SpecRunner.html- Load extension in Thunderbird (see CLAUDE.md)
- Test with real emails (use test accounts)
- Check error console for warnings/errors
- Verify all features still work
- Target: >80% line coverage
- Current: ~70% (v6.2)
- Framework: Mocha + Chai + Sinon
- Node.js: >= 22.0.0
- Git: In PATH
- Thunderbird: 128.0 or later
npm installnpm run lint # ESLint
npm run lint:ci # CI mode (no warnings)
npm run checkJs # Type checking
npm run test # Unit tests
npm run pack # Package extension
npm run update-thirdparty # Update dependenciesVS Code (Recommended):
- Extensions: ESLint, TypeScript
- Settings already in
.vscode/settings.json
Other Editors:
- Ensure EditorConfig support (.editorconfig)
- Configure for tabs (4-width), LF line endings
- CLAUDE.md: Comprehensive developer guide
- ROADMAP.md: Feature plans and architecture
- Module documentation in source files
Look for issues labeled:
good first issue- Beginner-friendlydocumentation- Docs improvementstranslation- Localization helphelp wanted- Community assistance needed
- Ask questions in GitHub Discussions
- Tag
@maintainersfor guidance - Join discussion on complex issues
We follow our Code of Conduct. Summary:
- Be Respectful: Treat everyone with respect
- Be Inclusive: Welcome diverse perspectives
- Be Collaborative: Work together constructively
- Be Professional: Focus on technical merit
Violations: Report to maintainers privately
See SECURITY.md for:
- Responsible disclosure process
- Security vulnerability reporting
- Bug bounty (if applicable)
Do NOT open public issues for security bugs!
By contributing, you agree that your contributions will be licensed under the MIT License (see LICENSE.txt).
Note: We are considering dual-licensing with Palimpsest License v0.8 for future versions. Contributors will be consulted before any license changes.
If submitting code from other sources:
- Ensure compatible license (MIT, BSD, Apache 2.0)
- Add attribution to
THIRDPARTY_LICENSE.txt - Document in commit message
- Update
CHANGELOG.mdwith version and date - Update
manifest.jsonversion - Run full test suite:
npm run lint && npm run checkJs && npm run test - Tag release:
git tag v7.0.0 - Push tags:
git push origin v7.0.0 - Run
npm run pack - Upload to addons.thunderbird.net
- Create GitHub Release with changelog
We value all contributions! Stats tracked:
- Code commits
- Issues opened/commented
- PRs submitted/reviewed
- Documentation improvements
- Community support
Top Contributors: See GitHub Insights
Contributors are recognized in:
- Release notes (CHANGELOG.md)
- GitHub contributors page
- Special thanks in major releases
Want to be listed?: Make 3+ quality contributions!
- GitHub Discussions: General questions, ideas
- GitHub Issues: Bug reports, feature requests
- Email: See MAINTAINERS.md for contact
- Wiki: User documentation
See ROADMAP.md for:
- Planned features (v7.0 - v8.0)
- Architecture vision
- Priority areas
Want to work on roadmap items? Open an issue to claim it!
Thank you for contributing to email security! Together, we make email safer for everyone. 🛡️
Last Updated: 2025-11-22 TPCF Version: 1.0 Maintained By: See MAINTAINERS.md