Open-source software for Joomla, Gitea, and web platforms. Home of MokoSuite, MokoGitea, and MokoCLI.
Tennessee
contributing/pull-request-guide.-
Pull Request Guide
How to create, review, and merge pull requests.
Creating a PR
Title
- Short and descriptive (under 70 characters)
- Matches commit convention type prefix:
feat: add S3 storage support
Body Template
## Summary
- Brief bullet points describing what changed and why
## Test Plan
- [ ] Unit tests added/updated
- [ ] Manual testing steps completed
- [ ] CI passes
## Related Issues
Closes #42
Before Submitting
- Branch is up to date with
main - All tests pass locally (
make test) - Linting passes (
make lint) - Code standards pass (
make phpcs) - CHANGELOG.md updated
- No debug code, console.log, or print statements left in
Review Process
- Automated checks — CI runs lint, phpcs, phpstan, tests
- Maintainer review — at least one approval required
- Address feedback — push additional commits to the PR branch
- Approval — reviewer approves when satisfied
- Merge — maintainer squash-merges the PR
Review Turnaround
- Target: 48 hours for initial review
- Hotfixes (priority: critical): same-day review
- If no review within 48 hours, ping the maintainer
Merge Strategy
- Squash merge — preferred for feature branches (clean history on main)
- Merge commit — for large multi-commit PRs where individual commits matter
- Never rebase merge to main (avoids rewriting published history)
After Merge
- Branch is auto-deleted
- Verify deployment if applicable
- Close related issues if not auto-closed by commit message
PR Etiquette
- Keep PRs small and focused — one logical change per PR
- Large features should be broken into incremental PRs
- Respond to review comments promptly
- Don't resolve your own review threads — let the reviewer confirm
- Use draft PRs for work-in-progress that needs early feedback
Pages