Pull Request Workflow

Pull Request Workflow

We welcome contributions that improve our WordPress ecosystem. To ensure a smooth review process, please follow this standardized workflow for submitting bug fixes and feature enhancements.

1. Preparation and Branching

Before starting any work, ensure your local environment is synced with the latest changes from the main repository.

1. Fork the repository to your own GitHub account.

2. Clone your fork and add the original repository as an upstream remote:

   git clone https://github.com/YOUR_USERNAME/wordpress.git
   cd wordpress
   git remote add upstream https://github.com/UditAkhourii/wordpress.git
   

3. Create a feature branch using a descriptive name and the appropriate prefix:

   • feat/ for new features or enhancements.
   • fix/ for bug fixes.
   • docs/ for documentation updates.

   git checkout -b feat/your-feature-name
   

2. Development Standards

To maintain consistency across our WordPress contributions, please adhere to the following:

• WordPress Coding Standards: Ensure your PHP, JS, and CSS follow the official WordPress Coding Standards.
• Documentation: If you are adding a new function or component, include inline documentation (PHPDoc/JSDoc) explaining the input parameters and return types.
• Atomic Commits: Keep your commits focused on a single logical change. Use the imperative mood in commit messages.

Example commit message:

feat: add custom REST API endpoint for MVP metrics

3. Submitting the Pull Request

Once your changes are ready and tested locally:

1. Push your branch to your fork:

   git push origin feat/your-feature-name
   

2. Open a Pull Request via the GitHub interface.
3. Fill out the PR Template: Clearly describe the problem you are solving or the feature you are adding. Mention any related issue numbers (e.g., Closes #123).

4. Continuous Integration and Review

After submission, your PR will undergo the following:

• Automated Checks: Our CI pipeline runs linting and basic syntax checks. PRs with failing checks will not be merged until resolved.
• Code Review: At least one maintainer will review your code. They may request changes or ask for clarification on specific implementation choices.
• Internal Components: If your PR modifies core internal logic (utility classes or private WP handlers), ensure you explain the impact on the public-facing API in the PR description.

5. Merging

Once approved and all checks pass, a maintainer will merge your PR into the main branch.

Note: We prefer Squash and Merge to keep the project history clean and readable. Please ensure your PR title is descriptive, as it will become the commit message for the squash.