Team Policies

TEAM POLICIES

1. Work Allocation & Responsibilities

• Every task follows the pipeline: issue → branch → PR

• A detailed issue must be created with:

  • Clear description of the task
  • Proper tags for effort (effort: high | moderate | low) and priority (pri: urgent | high | medium | low)
  • Assignment to 1–2 assignees (never more than 2)
  • Assignment to a project for roadmap visibility
  • 1–2 reviewers (different from the assignees) mentioned in the issue description
  • Deadline and acceptance criteria explicitly written

• Updates on the task must be posted as comments under the issue, with links to artifacts.

• Issues are almost never closed by their creator. Instead:

  • Reviewers close the issue when acceptance criteria are met.
  • If a reviewer is unavailable, another team member can voluntarily review and close.
  • Issues must always be closed with a comment explaining how the deliverable satisfies acceptance criteria.

2. Collaboration Guidelines

• Participation: Everyone is expected to contribute and take on tasks regularly.

• Disagreements:

  • First resolved through discussion.
  • If unresolved, resolved by majority vote.

• Working groups: Teams may form domain-specific subgroups (e.g., frontend, backend, documentation). Independent work is allowed if it aligns with project goals.

• Communication:

  • All updates should be visible via issue comments.
  • Important documentations should be available from the Wiki home page.
  • Major decisions (task assignments, process changes) require agreement from the team.

3. Code & Quality Standards

• Branching:

  • Naming: [feat|fix]/<issue_number>-<issue_title>
  • ❗Branches are never pushed directly to main.❗

• Pull Requests (PRs):

  • Must include a detailed description with closes #<issue_number> reference.
  • Reviewers different from the PR creator must be assigned.
  • At least one reviewer approval is required (preferably all reviewers).
  • ❗Unreviewed PRs are never merged.❗
  • After approval, a reviewer merges to main.
  • Branch is deleted after successful merge.

• Style & Quality:

  • Agreed style guide must be followed in codes (which will be achieved by using a Linter).
  • Unit tests are mandatory for new features and critical fixes.
  • Code must be documented (functions, modules, APIs).

4. Deadlines & Commitments

• Deadlines: Every issue must include a due date.
  • Team members are expected to meet deadlines.
  • If a delay is anticipated, notify the team as early as possible.
• Accountability:
  • Missing a deadline occasionally is acceptable with notice.
  • Consistently missing deliverables without notice may result in task reassignment or reduced responsibility until trust is restored.
  • When a task is falling behind, we don't assign more people. Instead, change some assignees. See The Mythical Man-Month: “Adding manpower to a late software project makes it later."