Contributing to Django PostgreSQL Anonymizer#
Thank you for your interest in contributing to Django PostgreSQL Anonymizer! This guide will help you get started.
π Quick Start#
Fork the repository
git clone https://github.com/CuriousLearner/django-postgres-anonymizer.git cd django-postgres-anonymizer
Set up development environment
make dev # Or manually: python -m venv venv source venv/bin/activate pip install -e . pip install -r requirements.txt
Run tests to ensure everything works
make test-all
π Commit Message Format#
This project follows Conventional Commits specification. Please format your commit messages as:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Types#
feat: A new featurefix: A bug fixdocs: Documentation only changesstyle: Changes that do not affect the meaning of the coderefactor: A code change that neither fixes a bug nor adds a featureperf: A code change that improves performancetest: Adding missing tests or correcting existing testsbuild: Changes that affect the build system or external dependenciesci: Changes to CI configuration files and scriptschore: Other changes that donβt modify src or test filesrevert: Reverts a previous commit
Examples#
feat: add support for custom anonymization functions
fix: resolve memory leak in batch processing
docs: update installation instructions
feat(presets): add new healthcare anonymization preset
fix(utils)!: breaking change to table introspection API
Setup Git Message Template#
git config commit.template .gitmessage
π§ͺ Testing#
Run all tests:
make test-allRun specific tests:
make test-models,make test-commandsRun integration tests:
make test-integration(requires PostgreSQL with anon extension)Check coverage: Coverage reports are generated in
htmlcov/
π Code Quality#
Before submitting a PR, ensure your code passes all quality checks:
make check # Runs all checks below
make lint # Ruff linting
make format # Ruff formatting (auto-fix)
make type-check # MyPy type checking
make security # Bandit security scanning
π Pull Request Process#
Create a feature branch
git checkout -b feat/amazing-new-feature
Make your changes
Follow the existing code style
Add tests for new functionality
Update documentation as needed
Add your changes to
CHANGELOG.rstordocs/changelog.rst
Test your changes
make test-all make check
Commit your changes (using conventional commits format)
git add . git commit -m "feat: add amazing new feature"
Push to your fork and create a PR
git push origin feat/amazing-new-feature
PR Requirements
β All tests pass
β Code quality checks pass
β Documentation updated (if applicable)
β Changelog updated
β Conventional commit format used
π― Areas for Contribution#
High Priority#
New Anonymization Presets: Industry-specific rule sets
Additional Anonymization Functions: Custom PostgreSQL functions
Performance Optimizations: Large dataset handling improvements
Documentation: Examples, tutorials, best practices
Medium Priority#
Admin Interface Enhancements: Better UX for rule management
API Improvements: Additional REST endpoints
Monitoring & Alerting: Integration with monitoring systems
Database Support: Support for other PostgreSQL-compatible databases
Good First Issues#
Test Coverage: Increase test coverage for edge cases
Documentation: Fix typos, improve examples
Bug Fixes: Address issues marked as βgood first issueβ
Code Cleanup: Refactoring, type hints improvements
π Bug Reports#
When reporting bugs, please include:
Environment Details
Python version
Django version
PostgreSQL version
Package version
Steps to Reproduce
Minimal code example
Expected vs actual behavior
Error messages/stack traces
Additional Context
Relevant configuration
Database schema (if relevant)
Anonymization rules (if relevant)
π‘ Feature Requests#
For new features, please:
Check existing issues to avoid duplicates
Describe the use case - why is this needed?
Provide examples - how would it work?
Consider backwards compatibility
Offer to implement - we welcome contributions!
π Development Guidelines#
Code Style#
Follow PEP 8 (enforced by Ruff)
Use Ruff for code formatting and linting
Add type hints where possible
Write docstrings for public APIs
Testing#
Write tests for all new functionality
Aim for >95% test coverage
Use descriptive test names
Include both unit and integration tests
Mock external dependencies appropriately
Documentation#
Update docstrings for API changes
Add examples for new features
Update README if user-facing changes
Consider adding to example project
Security#
Never commit secrets or credentials
Validate all user inputs
Use parameterized queries
Follow security best practices
Run security checks with
make security
πββοΈ Getting Help#
Documentation: Check the README and example project
Issues: Search existing issues for similar problems
Discussions: Use GitHub Discussions for questions
Code Review: Donβt hesitate to ask for feedback
π License#
By contributing to Django PostgreSQL Anonymizer, you agree that your contributions will be licensed under the BSD-3-Clause License.
Thank you for contributing to Django PostgreSQL Anonymizer! π