Pull Request Guidelines - OmegaOoh/ku-tangtee GitHub Wiki

Request Guidelines

1. Use Pull Request template for the first comment

## Title: [Brief description of the changes]

### Description
- **What have you done? Should be clear and easy to understand** e.g. Restrict edit activity to host
  - Provide a concise overview of what changes have been made and why.
  - e.g. Add permission class for ActivityDetail PUT request method handler, so that only the host can edit an activity
  - etc.
- Major Work or Features
  - detail ...
  - detail ...

### Functional Acceptance Criteria
- The given Functional Acceptance Criteria must work. The topic can be broad, e.g. Edit feature works properly
  - Then specify the detail(s) if needed
  - e.g. If the host edits, the information will be updated.
  - e.g. If anyone else edits, show an error message and the information won't be updated.
- Functional Acceptance Criteria
  - detail ...
  - detail ...

### Checklist
_A self-assessment section to ensure that all necessary steps have been completed before submission._
- [ ] I have performed a self-review of my code.
- [ ] I have added tests to cover my changes.
- [ ] I have updated the documentation, if applicable.
- [ ] My code follows the Coding Guidelines.

### Type of Change
_Categorizing the nature of the changes helps reviewers understand the scope quickly._
- [ ] Bug fix
- [ ] New feature
- [ ] Documentation update
- [ ] Other (please specify)

### Additional Information
- **Does this PR introduce a breaking change?** (Yes/No)
  - If yes, describe what users need to do to adapt.
  - e.g. .env change ...
  
- **Other information:** 
  - Include any other context or information relevant to the PR.
  - e.g. only works for backend

Example:

## Title: Backend function for searching the activity

### Description
- Keyword search function in ActivityIndex
  - Overwrite get_queryset in ActivityIndex, so that the page only shows activities that match the keyword.

### Functional Acceptance Criteria
- Search by keyword (ActivityIndex)
  - Can now use query parameter keyword to filter activities name (i.e. http://localhost:8000/activities/?keyword=value with value for filter)

### Checklist
- [x] I have performed a self-review of my code.
- [x] I have added tests to cover my changes.
- [x] I have updated the documentation, if applicable.
- [x] My code follows the Coding Guidelines.

### Type of Change
- [ ] Bug fix
- [x] New feature
- [ ] Documentation update
- [ ] Other (please specify)

### Additional Information
- Does this PR introduce a breaking change? No
  
- Other information:
  - Only works for the backend.

2. Review Request

  • Targeted Review: If you want the particular team members to review, tag them for a review.
  • Open Review: If the changes are broad or general, consider requesting no one or everyone.

3. Notify Changes

  • Comment: When making updates to the pull request, provide a concise comment that outlines the changes.
  • Template Update: Edit the initial comment if the modifications significantly impact the original pull request template.

Review Guidelines

1. Review Request

  • Prioritize Active Requests: If the PR specifically requests for your review or has an open spot, please take a look.
  • Respect Existing Assignments: Avoid reviewing a PR if another reviewer is already assigned unless explicitly requested.
  • Contact the Author: If you're interested in reviewing a PR that doesn't need a reviewer, you can contact the author.

2. What to review

  • Pull Request
    • Ensure PR and the code are accurate and aligned with project requirements.
    • Ensure all PR changes are acceptable
  • Functionality
    • Verify that the changes meet the specified functional acceptance criteria.
  • Code Quality
    • Clarity: Ensure that the code is easy to read and understand. Check for clear naming conventions and logical structure.
    • Consistency: Check adherence to Coding Guidelines.
    • Efficiency: Look for opportunities to optimize the code for performance without sacrificing readability.

3. Change Requests

  • Suggest Changes: Suggest changes when something unexpected occurs.
  • Provide Feedback: If you want to suggest changes, offer clear explanations and alternative approaches.
  • Prioritise Issues: Focus on addressing issues that impact correctness, security, or maintainability.

4. Comments

  • Ask questions: If you don't understand something, ask the author to explain it.
  • Give suggestions: Offer ideas for improving the code, but make change requests if the changes are required.