Contributing
Guide to contributing to PATH DRC EMR.
Overview
PATH DRC EMR welcomes contributions from the community. This guide covers how to contribute effectively.
Getting Started
Prerequisites
Before contributing, ensure you have:
- Git installed and configured
- GitHub account with repository access
- Development environment set up (see Local Development)
- Familiarity with OpenMRS concepts
Fork and Clone
# Fork the repository on GitHub, then clone
git clone https://github.com/YOUR_USERNAME/path-drc-emr.git
cd path-drc-emr
# Add upstream remote
git remote add upstream https://github.com/path-drc/path-drc-emr.git
Contribution Workflow
1. Create a Branch
# Sync with upstream
git fetch upstream
git checkout main
git merge upstream/main
# Create feature branch
git checkout -b feature/your-feature-name
Branch Naming
Use descriptive branch names:
| Prefix | Purpose | Example |
|---|---|---|
feature/ |
New functionality | feature/add-lab-results |
fix/ |
Bug fixes | fix/patient-search-error |
config/ |
Configuration changes | config/update-forms |
docs/ |
Documentation updates | docs/update-readme |
2. Make Changes
- Follow existing code patterns and conventions
- Keep changes focused and minimal
- Test changes locally before committing
3. Validate Changes
# Run configuration validation
mvn -P distro,validator clean verify
# Test Docker build
docker compose build
# Test locally
docker compose up -d
4. Commit Changes
Write clear commit messages:
git add .
git commit -m "Add lab results form for HIV program
- Add new form definition in forms/
- Update form mappings in encountertypes/
- Add required concepts to concepts.csv"
Commit Message Guidelines:
- First line: Brief summary (50 chars max)
- Blank line
- Body: Detailed explanation if needed
- Reference related issues:
Fixes #123
5. Push and Create Pull Request
git push origin feature/your-feature-name
Then create a Pull Request on GitHub.
Pull Request Guidelines
PR Description
Include in your PR description:
- What: Brief summary of changes
- Why: Motivation for the change
- How: Implementation approach
- Testing: How you tested the changes
PR Template
## Summary
Brief description of changes.
## Changes
- Change 1
- Change 2
## Testing
- [ ] Ran configuration validation
- [ ] Built Docker images locally
- [ ] Tested in local environment
## Related Issues
Fixes #123
Review Process
- Automated CI checks run on PR
- Maintainers review the code
- Address feedback and update PR
- PR is merged after approval
Types of Contributions
Configuration Changes
Most contributions involve configuration updates:
- Forms: JSON form definitions in
distro/configuration/forms/ - Concepts: Custom concepts in
distro/configuration/concepts/ - Locations: Location hierarchy in
distro/configuration/locations/ - Settings: Global properties in
distro/configuration/globalproperties/
Site-Specific Content
For site-specific contributions:
- Place files in appropriate
sites/{site}/directory - Follow existing structure
- Test with site-specific build
See Adding Sites for details.
Documentation
Documentation contributions are welcome:
- Fix typos and clarify existing docs
- Add missing documentation
- Update outdated information
Documentation lives in the docs/ directory.
Bug Reports
When reporting bugs:
- Check existing issues first
- Provide clear reproduction steps
- Include relevant logs
- Specify environment details
Code Standards
Configuration Files
CSV Files:
- Use consistent column ordering
- Include all required columns
- Use meaningful UUIDs (not sequential)
JSON Files:
- Follow existing formatting
- Validate JSON syntax
- Use CIEL concepts when available
XML Files:
- Maintain proper indentation
- Include XML declarations
- Validate against schemas
Naming Conventions
| Type | Convention | Example |
|---|---|---|
| Concepts | Descriptive English names | Lab Result - Viral Load |
| Forms | PascalCase | VitalsForm.json |
| Locations | Proper case | Main Hospital |
| Files | kebab-case | patient-registration.csv |
Testing Your Changes
Configuration Validation
# Validate all configuration
mvn -P distro,validator clean verify
Local Testing
# Build images
docker compose build
# Start environment
docker compose up -d
# Watch logs for errors
docker compose logs -f backend
Manual Testing
After startup:
- Log in at
http://localhost/openmrs/spa - Verify your changes work as expected
- Check for console errors
- Test affected workflows
Continuous Integration
Automated Checks
Pull requests trigger:
- Maven build validation
- Configuration validation
- Docker image build test
CI Requirements
PRs must pass:
- All automated checks
- Code review by maintainer
Getting Help
Resources
Questions
For questions about contributing:
- Check existing documentation
- Search closed issues and PRs
- Open a discussion on GitHub
Related
- Local Development - Development setup
- Building Images - Image build process
- CI/CD - Automated workflows