Skip to content

github-pr-template.md

Latest commit

 

History

History
595 lines (395 loc) · 11.8 KB

github-pr-template.md

File metadata and controls

595 lines (395 loc) · 11.8 KB
Raw

Pull Request Template

Location: .github/pull_request_template.md

📋 Pull Request

Description

What does this PR do?

Why is this change needed?

How does this increase p(e/uto)?

Related Issues

  • Closes #
  • Related to #
  • Depends on #

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 📚 Documentation update
  • 🎨 Style/UI change (formatting, layout, design)
  • ♻️ Refactoring (no functional changes)
  • ⚡ Performance improvement
  • ✅ Test update
  • 🔧 Configuration change
  • 🌍 Community/content update

Branch/Community

  • Main ê/uto
  • CoCreators/uto
  • Music/uto
  • Fashion/uto
  • bt/uto (Blue Team)
  • eco/uto
  • chill/uto
  • startup/uto
  • ai-alignment/uto
  • Multiple branches
  • Infrastructure/All branches

Changes Made

Key Changes:

Files Modified:

Testing

Testing Done:

  • I have tested these changes locally
  • All existing tests pass
  • I added new tests for new functionality
  • I tested edge cases
  • I tested on multiple browsers/environments (if applicable)

Test Results:

Manual Testing Steps:

Screenshots/Videos

Before:

After:

Documentation

  • I updated relevant documentation
  • I added code comments for complex logic
  • I updated the README (if needed)
  • I updated the CHANGELOG (if applicable)
  • I added/updated JSDoc or docstrings
  • No documentation updates needed

Documentation Updated:

Breaking Changes

Are there breaking changes?

  • No
  • Yes (describe below)

Breaking Changes Description:

Migration Guide:

Dependencies

New Dependencies:

  • None
  • Package: version (reason)

Updated Dependencies:

  • None
  • Package: old version → new version (reason)

Removed Dependencies:

  • None
  • Package (reason)

Performance Impact

  • No performance impact
  • Improves performance
  • May decrease performance (justified below)

Performance Notes:

Security Considerations

  • No security impact
  • Improves security
  • Potential security implications (described below)

Security Notes:

Accessibility

  • No accessibility impact
  • Improves accessibility
  • Accessibility considerations documented below

Accessibility Notes:

Checklist

Code Quality:

  • My code follows the project's style guidelines
  • I have performed a self-review of my code
  • I have commented complex or non-obvious code
  • My changes generate no new warnings or errors
  • I have removed any console.logs or debug code
  • I have checked for and removed any TODO comments (or created issues for them)

Testing:

  • I have added tests that prove my fix/feature works
  • New and existing unit tests pass locally
  • I have tested edge cases
  • I have tested error handling

Documentation:

  • I have updated relevant documentation
  • I have added inline comments where needed
  • I have updated the CHANGELOG (if applicable)

Community:

  • My commit messages follow the conventional commits format
  • I have squashed commits into logical units (if applicable)
  • I have requested review from appropriate people
  • I am ready to address review feedback

Philosophy Alignment:

  • This change aligns with ê/uto's mission and values
  • This change respects the "no rules, only choices" philosophy
  • This change increases p(e/uto) in some way

Review Requests

Requested Reviewers:

  • @
  • @

Why these reviewers?

Specific Feedback Needed:

Deployment Notes

Deployment Considerations:

  • No special deployment steps needed
  • Requires configuration changes (detailed below)
  • Requires database migrations
  • Requires environment variable updates
  • Should be deployed during low-traffic period

Deployment Steps:

Rollback Plan:

Additional Context

Context:

Alternative Approaches Considered:

Future Work:

Questions for Reviewers:

Post-Merge Tasks

  • Update related documentation
  • Notify affected users/branches
  • Create follow-up issues
  • Update project board
  • Announce in Discord #
  • Post on X/Twitter (if significant)
  • Update Round Table (if needed)

Contributor Affirmation

  • I have read and agree to follow the Code of Conduct
  • I have read the Contributing Guidelines
  • I understand my contributions will be licensed under the project's license
  • I am authorized to submit this contribution

🌟 For Reviewers

Review Checklist

Code Review:

  • Code is clear and understandable
  • Code follows project conventions
  • No obvious bugs or issues
  • Error handling is appropriate
  • Performance is acceptable
  • Security considerations addressed

Functionality:

  • Changes work as described
  • Edge cases are handled
  • No unintended side effects
  • Backwards compatibility maintained (or migration path provided)

Testing:

  • Tests are comprehensive
  • Tests pass
  • Manual testing completed
  • Edge cases tested

Documentation:

  • Documentation is clear and complete
  • Code comments are helpful
  • README updated if needed
  • Breaking changes documented

Community:

  • Aligns with ê/uto values
  • Increases p(e/uto)
  • Good citizen of the codebase

Reviewer Notes

💬 Discussion

🎉 Merge Checklist

  • All review feedback addressed
  • All CI checks passing
  • At least one approval from maintainer
  • No unresolved conversations
  • Commits squashed/cleaned up (if applicable)
  • CHANGELOG updated
  • Ready to deploy

Thank you for contributing to ê/uto! 🌍

Every contribution moves us closer to ethical, abundant futures for all.

🌱 → 🌿 → 🌳 → 🌺

Part of the ê/uto Network

#technoheroism · #UTOideasMonday · #TechnoHeroThursday

📝 Template Usage Guide

For Contributors

When creating a PR:

  1. Fill out all sections - More information = faster review
  2. Be specific - "Fixed bug" → "Fixed null pointer exception in TruthAnchoring module"
  3. Link issues - Use "Closes #123" to auto-close issues
  4. Add screenshots - Visual changes need visual evidence
  5. Request appropriate reviewers - Tag people with relevant expertise
  6. Check all boxes - Don't skip the checklist
  7. Be responsive - Address feedback promptly

Tips:

  • Delete sections that don't apply (but keep the checkboxes)
  • Add context liberally - reviewers don't have your context
  • Explain "why" not just "what"
  • Be open to feedback
  • Thank reviewers for their time

For Maintainers

Customizing this template:

  1. Adjust sections - Add/remove based on your needs
  2. Modify checklists - Reflect your standards
  3. Update labels - Match your label system
  4. Add automation - Use GitHub Actions with PR metadata
  5. Set branch rules - Require checklist completion

Review Workflow:

  1. Check if template is properly filled
  2. Review changes thoroughly
  3. Test manually if needed
  4. Provide constructive feedback
  5. Approve when ready
  6. Ensure post-merge tasks complete

🔄 PR Lifecycle

1. Draft PR (Optional)

Create as draft if:

  • Work in progress
  • Need early feedback
  • Want to show direction

Mark ready when complete.

2. Ready for Review

  • All checklist items complete
  • Self-reviewed
  • Tests passing
  • Reviewers requested

3. Review

  • Reviewers provide feedback
  • Author addresses comments
  • Iterate until approved

4. Approved

  • All feedback addressed
  • CI passing
  • Ready to merge

5. Merged

  • Squash/rebase as appropriate
  • Delete branch
  • Complete post-merge tasks
  • Celebrate! 🎉

🏷️ Commit Message Format

Use conventional commits for clear history:

type(scope): brief description

Detailed explanation if needed.

Closes #123

Types:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation
  • style: Formatting
  • refactor: Code restructuring
  • test: Tests
  • chore: Maintenance

Examples:

feat(onboarding): add symbolic ritual section

Added 5 symbolic onboarding rituals with templates
and examples. Updated table of contents.

Closes #42

fix(gmsf): correct Truth Anchoring threshold

Changed confidence threshold from 0.90 to 0.95
based on community feedback and calibration data.

Fixes #87

docs(readme): update installation instructions

Clarified steps for Windows users and added
troubleshooting section.

🤖 Automation Hooks

This template works well with GitHub Actions:

Auto-labeling:

# .github/workflows/label-pr.yml
if: contains(github.event.pull_request.body, '🐛 Bug fix')
  uses: actions-ecosystem/action-add-labels@v1
  with:
    labels: 'type: bug'

Auto-assign:

# Auto-assign reviewers based on files changed

Status checks:

# Ensure checklist items are checked

🔗 Zettelkasten Links

Upstream:

  • [[contributing-guidelines]] - Contribution process
  • [[code-of-conduct]] - Community standards

Related:

  • [[issue-templates]] - Issue creation
  • [[review-process]] - Code review standards
  • [[git-workflow]] - Branch and commit strategy

Downstream:

  • [[merge-strategy]] - How PRs are merged
  • [[release-process]] - From PR to release
  • [[changelog-management]] - Version documentation

Great PRs build great communities. 🚀

Quality over speed. Clarity over brevity. Collaboration over ego.