These policies define how Group 9 operates throughout the CMPE 354 project. Every team member is expected to read, understand, and follow them.

---

• Primary channel: WhatsApp group chat for day-to-day coordination, quick questions, and announcements.
• GitHub Issues & Comments: All task-related discussions, progress updates, and review feedback must be documented on GitHub — not only on WhatsApp. If a decision is made on WhatsApp, it should be summarized as a comment on the relevant issue.
• Tagging: When a message or issue requires someone's attention, tag them directly. Don't assume people will notice on their own.

---

• Weekly meeting: Every Wednesday at 21:00. Attendance is expected from all members.
• Agenda: Should be shared in the WhatsApp group at least the evening before the meeting. Any member can add items.
• Meeting notes: A designated note-taker (rotating each week) documents the meeting and publishes it to the Wiki using the [Weekly Meeting Template].
• Absences: If you cannot attend, notify the group before the meeting and review the notes afterward.

---

• Every piece of work — no matter how small — starts with a GitHub issue.
• Each issue must contain:
  • A clear title and description of what needs to be done
  • Labels for effort (effort: high | moderate | low) and priority (pri: urgent | high | medium | low)
  • Assignees
  • Reviewers
  • A deadline
  • Clear acceptance criteria so the reviewer knows when the task is complete
• Progress should be tracked through comments on the issue with links to related wiki pages, commits, or PRs.
• Closing issues: The assignee does not close their own issue. A reviewer verifies that the acceptance criteria are met, leaves a comment confirming this, and then closes the issue. If changes are required, the reviewer will leave a comment notifying the assignee to make the updates, and the issue remains open.

---

• Commit model:
  • Use the following commit message syntax: <type>: <short-description>
  • Allowed commit types are: feat, fix, docs, refactor, test, and chore
  • Keep commit messages short, clear, and descriptive
  • Use one commit for one logical change only
  • Do not use vague commit messages such as update, changes, or final version
• Branching model:
  • Create a branch from main for each task: feat/<short-description>, fix/<short-description>, docs/<short-description>, refactor/<short-description>, or test/<short-description>
  • Never push directly to main. All changes go through pull requests.
  • Use one branch for one issue or task only.
  • Keep <short-description> short, clear, lowercase, and hyphen-separated.
  • Do not mix unrelated changes in the same branch.
  • Keep branches up to date with main before opening or merging a pull request.
  • Delete branches after they are merged.
• Pull Requests:
  • Reference the issue: include closes #<issue_number> in the PR description.
  • Assign at least one reviewer who is not the PR author.
  • PRs require at least one approval before merging. No exceptions.
  • The reviewer (not the author) performs the merge after approval.
  • Delete the branch after a successful merge.
  • Use a clear and descriptive pull request title.
  • Keep each pull request focused on a single logical change.
  • Do not merge pull requests with unresolved conflicts.
  • Update related documentation if the change affects requirements, diagrams, setup instructions, or user-facing behavior.
  • Ensure the branch is up to date with main before merging.
• Code standards:
  • Follow the team's agreed-upon style guide, enforced by the linter where possible.
  • Write unit tests for new features and critical bug fixes.
  • Document your code — especially public functions, modules, and API endpoints.

---

Lab reports are written collaboratively in/after each lab session and published on the Wiki:

• Deliverable links: The top of the report lists links to the main deliverables produced during that lab (e.g., scenarios, diagrams, wiki pages).
• Individual contributions: Each team member writes their own section under a heading with their name. Each contribution entry should:
  • Describe what was done in a short sentence
  • Include a link to the relevant wiki page, issue, or PR
• Deadline: Lab reports must be published to the Wiki within 48 hours of the lab session.
• Responsibility: One member is assigned to create the wiki page and compile the report; all other members are responsible for adding their own individual contribution section on time.

---

• The Wiki is the single source of truth for all project documentation.
• Every significant deliverable (scenarios, diagrams, requirements, meeting notes, reports) must have its own wiki page.
• Wiki pages should be linked from the sidebar for easy navigation.
• When creating a new page, check that it follows the naming conventions used in existing pages (e.g., Scenario-1, Weekly-Meeting-3, Lab-2-Report).

---

• Every issue has a due date. Meeting deadlines is a shared responsibility.
• If you anticipate a delay, communicate it early — at least 24 hours before the deadline. The team can help redistribute work or adjust timelines.
• Occasional delays with notice are understood. Repeatedly missing deadlines without communication will lead to a team discussion and potential reassignment of responsibilities.
• If a task is falling behind, the approach is to swap assignees rather than pile on more people. Adding more hands to a late task usually makes things worse, not better.

---

• Disagreements are first resolved through open discussion — ideally in the weekly meeting or on the relevant GitHub issue.
• If consensus cannot be reached, the team holds a majority vote. The result is binding.
• Personal conflicts should be addressed directly and respectfully. If needed, the team can mediate collectively.