Pull Request Process

Pull Request Process

We welcome contributions to this repository. To maintain code quality and ensure a smooth integration process, please follow these guidelines when submitting a Pull Request (PR).

1. Preparation and Branching

Before submitting a PR, ensure your local environment is synchronized with the latest changes from the main branch.

• Branch Naming: Use descriptive prefixes for your branches to help maintainers identify the intent of the contribution:
  • feature/ – For new components, plugins, or themes.
  • fix/ – For bug fixes.
  • docs/ – For documentation improvements.
  • refactor/ – For code cleanup without functional changes.

2. Coding Standards

All contributions must adhere to the WordPress Coding Standards (WPCS). This ensures consistency across the codebase.

• Documentation: Every new function, class, or hook must include a DocBlock.
• Security: Ensure all user inputs are sanitized and outputs are escaped using standard WordPress functions (e.g., sanitize_text_field(), wp_kses()).

3. Submission Checklist

When opening a Pull Request, please provide a clear and concise description of the changes. Your PR description should include:

• Problem/Purpose: Why is this change necessary?
• Proposed Changes: A high-level summary of what was added or modified.
• Verification: Steps to test the changes manually or evidence of automated test results.

Example PR Description format:

## Summary
Updated the custom post type registration to support Gutenberg blocks.

## Changes
- Added 'show_in_rest' => true to the 'portfolio' CPT.
- Integrated block templates for consistent layout.

## How to Test
1. Activate the plugin.
2. Navigate to 'Portfolio' -> 'Add New'.
3. Verify the Block Editor loads correctly.

4. Review and Approval

Once a PR is submitted, it enters the peer review phase.

• Automated Checks: If CI/CD pipelines are active, your PR must pass all linting and build checks before it can be merged.
• Peer Review: At least one maintainer will review your code. They may request changes or ask for clarification on specific implementation choices.
• Revision: If changes are requested, push the updates to the same branch; the PR will update automatically.

5. Merging

After receiving an "Approve" status from a maintainer and passing all automated checks, your PR will be merged into the main branch. We generally prefer Squash and Merge to keep the commit history clean and readable for all users.

Note: If you are proposing a major architectural change, please open an Issue first to discuss the implementation with the maintainers.