Skip to content

Team Collaboration Rule

Jump to bottom
jerry_yeo edited this page Dec 6, 2025 · 4 revisions

🛠️ Team Collaboration Rules

We define our team's development process and collaboration rules. All team members must adhere to the rules below to ensure smooth collaboration and maintain code quality.

1. Branching Strategy

We operate branches based on GitHub Flow.

📌 Branch Types

  • master: The main branch deployed as the product. (Direct Push Prohibited)
  • feature/*: Branches for developing new features.
  • hotfix/*: Branches for fixing urgent bugs occurring after deployment.
image

📌 Naming Convention

All branch names must include the Jira Issue Key for tracking purposes.

  • feature/[Jira-Key]-[Description]
  • hotfix/[Jira-Key]-[Description]

Ex) feature/SCRUM-53-guided_missile

2. Jira Integration & Commit Convention

We follow strict conventions to link issue tracking with code changes.

📌 Commit Message Format

Include the Issue Key in the commit message header to ensure it links with the Jira ticket.

  • [Type]-[Jira-Key]: [Description]

Ex) feat-SCRUM-53: Implement guided missile feature

📌 Work Rules

  • Traceability: Explicitly state the Jira Issue Key everywhere, including commit messages, PR titles, and branch names.
  • Status Management: Status changes of Jira tickets (To Do → In Progress → Done) must be updated manually by the assignee.

3. Pull Request (PR) Process

📋 PR Rules

  • 1 PR 1 Feature: As a rule, one PR should correspond to one feature unit.
  • No File Limit: There is no limit on the number of file changes, but please write with review efficiency in mind.

📝 PR Template

Please adhere to the template below when creating a PR.

🚩 What is this PR?

📢 Changes-Detail

📃 Progress Completed:

To-do:

✅ Checklist

[ ] Jira issue key is included

📸 Screenshots or Video

⚙️ Additional Notes

4. Code Review Policy

We undergo a rigorous review process to maintain code quality and stability.

🛡️ Branch Protection (master)

  • Direct Push Prohibited: All changes are merged only via PR.
  • CI Build Check: Merging is possible only if the CI build succeeds.
  • Review Requirement: Merging is possible only with approval from at least 2 reviewers.

👁️ Review Focus

Reviewers (Pool: 3 people) focus on the following points:

  1. MVC Pattern: Is the architecture pattern correctly followed?
  2. Consistency: Is it consistent with the existing code style and structure?
  3. Reusability: Is the code written with reusability in mind?

5. Review Communication Rule (Pn Rule)

We use the Pn Rule (Priority Rule) to clearly convey the reviewer's intent. Please add the tag at the beginning of your comment.

Tag Meaning Action Description
P1 Must be reflected Request changes Potential to cause critical errors in the service or requires mandatory correction. The author must reflect this or persuade the reviewer with valid reasons.
P2 Strongly consider Request changes Adoption is recommended. If it cannot be adopted, discussing it with appropriate reasoning is recommended.
P3 Reflect if possible Comment Adoption is recommended. If it cannot be reflected, stating the reason or future plan (e.g., Jira ticket) is recommended.
P4 Okay to reflect,
Okay to skip		 Approve The author may ignore this. It is sufficient to just consider whether it would be good to reflect the opinion.
P5 Just a trivial opinion Approve The author may ignore this without leaving any feedback.

Clone this wiki locally