Responsibilities Assigned Within the Team

Salary

This task pays a fixed salary of 6 MVP points, plus up to 18 quality points for exceeding the minimum requirements — for a total of 24 points, with a maximum of 4 points per person.

Minimum Viable Product (MVP)

By the end of this task every teammate has a short, clear responsibility statement (one–two sentences) that says what they mainly take care of during the project. This is not a life‑long title; it simply makes day‑to‑day work smoother and avoids “who does this?” moments. Keep it practical and beginner‑friendly (e.g., “Owns CLI menus,” “Keeps tests green,” “Prepares weekly demo”).

To complete the MVP, each person creates one GitLab issue in the project that contains their responsibility statement. Then, in the project README.md, add a small Team Responsibilities section that lists all members and links to their issues. Now everyone (including the tutor) can see who to ask for what.

Example: Team 'ByteBusters' make it explicit

Each member opens an issue and assigns him/her-self to the issue, like “Testing & CI basics” or “Menu navigation & UX text.” The README has a bullet list with names and links to these issues. When questions pop up, they know exactly who to ping.

Technical Details

In GitLab, create assign one issue per person with a short description: Main focus, Backup/secondary, and Typical tasks (3–5 bullets). Add a simple label like role to make them easy to find. In README.md, add a ## Team Responsibilities table (Name → Role summary → Issue link). Keep wording simple and aligned with what you’ll actually build (procedural Python scripts or CLI Java programs).

Responsibilities should connect to common early‑course roles: Coordinator/PM-lite (keeps board tidy, reminds deadlines), Feature Implementer (writes core functions/classes), Tester (writes/updates basic unit tests with pytest/JUnit), Docs Maintainer (updates docs/ and README), DevOps-lite (runs CI template, fixes simple pipeline breaks). One person can hold two light responsibilities, but avoid overwhelming.

Quality

Quality means your responsibilities are well-scoped and non-overlapping: it’s clear where each role starts and ends, and there are no “grey zones.” Add 1–2 sentences to each issue describing hand‑off rules (e.g., “If I’m blocked for a day, I ask in chat and tag the backup”). Include a short glossary of any technical terms you use so beginners (and future teammates) understand them.

Show thoughtfulness: map responsibilities to team strengths (e.g., based on Belbin insights or preferences) and to your chosen project scope. Mention simple backup rules (who substitutes whom) and how you’ll review each other’s work (e.g., “At least one peer review before merge”). This makes your team resilient when someone is sick or busy and improves code quality without advanced tooling.

Example: Team 'NullPointers' remove grey zones

They split work by outcomes: “Input/Output flow,” “File storage,” “Search & filters,” “Testing & CI,” “Docs.” Each issue states boundaries like “Search delivers a function that returns filtered results; I/O only prints them.” They add “If blocked >24h, tag backup in the issue and mention in daily chat.”

Example: Team 'PixelPenguins' match roles to strengths

With one strong writer, they assign Docs Maintainer; the most organized member becomes Coordinator; two coders share Feature Implementer by module. Their README table links every name to an issue, and they note: “Every PR needs one review; the Tester checks tests run locally and in CI.”