Contributions to QFieldCloud are welcome! This guide covers the process for submitting changes.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/opengisch/qfieldcloud/llms.txt
Use this file to discover all available pages before exploring further.
Before You Start
1. Communicate Your Ideas
Before investing time in a PR, discuss your proposal with the QFieldCloud team:- Create an issue: Open a GitHub issue detailing your suggestion
- Wait for feedback: The development team will review and provide guidance
- Clarify details: Engage in discussion to refine the approach
2. Check Existing Issues
Search for existing issues or discussions related to your idea:Development Workflow
1. Fork and Clone
Fork the repository and clone with submodules:2. Create a Branch
Create a feature branch frommaster:
feature/description- New featuresfix/description- Bug fixesrefactor/description- Code refactoringdocs/description- Documentation changestest/description- Test improvements
3. Make Changes
Develop your changes following the code style guidelines.4. Commit Changes
Write clear, concise commit messages:- Use imperative mood (“Add” not “Added”)
- First line: concise summary (50 chars or less)
- Reference issue numbers: “Fix #123: Handle null project descriptions”
- Explain why, not just what
5. Push and Create PR
Push your branch and create a pull request:Pull Request Guidelines
PR Title and Description
Title: Clear and descriptive- Summary: What does this PR do?
- Issue reference:
Closes #123orRelated to #456 - Changes: List of main changes
- Screenshots: Before/after (for UI changes)
- Testing: How to test the changes
PR Checklist
Before submitting:- Branch is based on latest
master - Code follows code style guidelines
- Tests are included for new features/fixes
- All tests pass locally
- Documentation is updated (if applicable)
- Commit messages are clear and descriptive
- PR description is complete
- No merge conflicts
Draft PRs
If your PR is not ready for review, mark it as a draft PR. Draft PRs should:- Be checkable without breaking the stack
- Have the specific feature testable (even if incomplete)
PR Review Process
- Automated checks: CI runs tests and linters
- Code review: Team members review your code
- Feedback: Address review comments
- Approval: Once approved, your PR will be merged
Code Style
QFieldCloud uses automated tools to enforce code style.Pre-commit Hooks
Install pre-commit hooks to automatically check code before commits:git commit.
Pre-commit Configuration
See.pre-commit-config.yaml for the full configuration. Key hooks:
1. Ruff (Linting and Formatting)
Ruff is used for both linting and formatting Python code:2. Flake8 (Additional Linting)
3. mypy (Type Checking)
Static type checking with mypy:4. django-upgrade
Automatically upgrades Django code to 4.2 standards:5. Standard Hooks
Basic code quality checks:check-ast: Validate Python syntaxcheck-yaml: Validate YAML filescheck-json: Validate JSON filescheck-merge-conflict: Detect merge conflictsend-of-file-fixer: Ensure files end with newlinetrailing-whitespace: Remove trailing whitespacemixed-line-ending: Enforce LF line endings
Run All Pre-commit Hooks
Manually run all hooks:Code Style Guidelines
Python
- PEP 8: Follow Python style guide
- Line length: 88 characters (Black default, used by Ruff)
- Imports: Group into stdlib, third-party, and local
- Docstrings: Use for public methods and classes
- Type hints: Add where beneficial
Django
- Use Django 4.2 features (enforced by
django-upgrade) - Avoid deprecated patterns
- Use ORM instead of raw SQL where possible
- Follow Django naming conventions
Templates
- Use Django template language best practices
- Escape user input (auto-escape is on)
- Keep logic minimal in templates
Testing Requirements
Write Tests
All new features and bug fixes should include tests. Example test:Run Tests
Ensure all tests pass before submitting:Check Coverage
Maintain or improve test coverage:Documentation
Update Documentation
If your changes affect:- API: Update API documentation or docstrings
- Setup: Update README.md or setup docs
- Features: Update user-facing documentation
Docstrings
Use clear docstrings for public APIs:Branching Strategy
Main Branches
master: Main development branch- Feature branches: Created from
master
Branch Protection
master is protected:
- Cannot push directly
- PRs required
- CI checks must pass
- Code review required
Merge Strategy
PRs are typically merged using:- Squash and merge: For feature branches (clean history)
- Merge commit: For important multi-commit PRs
Common Scenarios
Updating Your Branch
Keep your branch up-to-date withmaster:
Fixing Failed CI
If CI fails:- Check the error in the GitHub Actions logs
- Fix the issue locally
- Commit and push:
Addressing Review Comments
- Make the requested changes
- Commit with a clear message
- Push to update the PR
- Reply to comments to notify reviewers
Resources
Getting Help
- GitHub Issues: For bugs and feature requests
- Pull Requests: For code review questions
- Email: sales@qfield.cloud for funding features