Task Point System (TPS): Student Guide

How to create clear tasks, collaborate fairly, and review your teammates' work professionally.

Core idea: TPS is not only for tracking work. It is also a team accountability process. Every task should be understandable, reviewable, and evidence-based.

1) Why task quality matters

  • Clear tasks prevent confusion and repeated work.
  • Good descriptions help teammates review fairly.
  • Consistent review behavior protects team trust.
  • Your contribution score depends on accepted work.
If a teammate cannot understand your task from the title + description alone, the task is not ready.

2) Your responsibilities

  • Create tasks before doing significant work.
  • Keep each task atomic (one clear deliverable).
  • Review teammate tasks and vote responsibly.
  • Request revisions when details or quality are insufficient.
  • When completing a task, provide evidence (summary + link).

3) Workflow and statuses

Use these statuses correctly throughout the lifecycle:

Status Meaning What happens next
Proposed Task idea is created and waiting for teammate votes. Majority approve -> Open. If teammates request changes, owner edits and a new version is created.
Open Task is approved to start implementation. Owner completes work and submits completion details.
Completed Owner submitted completion with evidence. Majority approve -> Accepted. If majority request revision, owner submits a completion update and voting restarts.
Accepted Team approved the delivered work. Counts as accepted contribution.
Rejected Task was not accepted in the workflow. Review with lecturer/team and decide whether to replace with a new task.

4) How to write a strong task

When creating a task, your title should be brief, and your description should include:

  1. Context: What part of the project this belongs to.
  2. Goal: What should be achieved at the end.
  3. Scope: What is included and what is excluded.
  4. Implementation plan: Main steps you will take.
  5. Acceptance criteria: Clear checks teammates can verify.
  6. Dependencies: Any blocked item, related task, or required input.
Strong acceptance criteria sound like: "API returns 200 with required fields", "UI shows validation errors", "unit tests for edge case X pass".

5) Description template (recommended)

Context:
Goal:
Scope In:
Scope Out:
Plan:
Acceptance Criteria:
Dependencies/Risks:

Copy this directly into the Description box and fill each line.

6) How to review teammate tasks

For Proposed tasks

  • Approve if the task is clear, scoped well, and testable.
  • Request revision if important details are missing.
  • In your comment, explain exactly what should be improved.

For Completed tasks

  • Read the completion summary carefully.
  • Check the Git commit/file URL evidence.
  • Verify that acceptance criteria are actually met.
  • If not met, request revision with specific actionable feedback.

7) Completion submission quality

When the owner clicks Mark Completed, two fields are mandatory:

  • Completion Summary: what changed, where, and why.
  • Git Commit or File URL: concrete evidence teammates can inspect.

Good summary: mentions files/modules changed, behavior added/fixed, and test/verification done.

Weak summary: "Done", "Fixed everything", or no traceable proof.

8) Professional feedback style

A revision request should always help the owner succeed in the next attempt.

9) Quick checklist before submitting or voting

Before creating or updating a task

Before approving a completed task

Do not approve just because someone asked. Approve only when evidence is clear.