Skip to content

Project Selected

Salary

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

Minimum Viable Product (MVP)

By the end of this task your team can clearly state which project you will build and there is full agreement within the team. You will choose from a set of simple, high-level themes provided by the course — for example, “a basic variant of Conway’s Game of Life,” “a simple text-based library catalog,” or “a command-line data processor.” These are starting points, not detailed designs.

To complete the MVP, create a GitLab project under your team group with the chosen project name, and add a README.md file containing a short elevator pitch (3–5 sentences) describing: what the program will do, what kind of user it is for, and why it will be useful. Keep it realistic for the skills and tools you have now.

Example: Team 'ByteBusters' chooses a Library Catalog

The ByteBusters decide to build a command-line tool to store and search books by title and author. Their README says: “A simple Python program for small personal libraries. Lets the user add, list, and search books. Aimed at readers who want a lightweight alternative to spreadsheets.”

Technical Details

In GitLab, within your team group:

  1. Create a new project with a clear, final name (e.g., bytebusters/library-catalog).
  2. Add all teammates as Developers and your tutor as Maintainer.
  3. Commit a README.md that includes:
    • Project title
    • Short elevator pitch
      • 3–5 sentences describing the program’s purpose, target user, and usefulness (e.g., “A simple Python program for small personal libraries. Lets the user add, list, and search books. Aimed at readers who want a lightweight alternative to spreadsheets.”)
      • 2–3 simple goals (vague features) for the semester (e.g., “Add books,” “List all books,” “Search by keyword”)
      • One “non-goal” (what you will not do) to show scope control (e.g., “No online database connection in this version”).

Ensure everyone can access the repo and clone it successfully before moving forward.

Quality

A quality project selection shows you thought about your choice: it matches your skills, can be finished within the semester, and uses the team’s roles effectively. In the README, explain briefly why you chose it and how it plays to the team’s strengths (e.g., one member likes designing menus, another enjoys file handling). Mention any simple risks and how you will keep them under control.

Quality also means your README is clear, friendly, and gives a future reader (even outside the team) a good picture of what the program will do. Think of it as your project’s first “welcome sign.”

Example: Team 'NullPointers' align their choice

The NullPointers pick “Basic Budget Tracker” because two members like working with numbers, and one enjoys writing menu navigation. They note in their non-goal: “No advanced charts or export formats in v1,” so they can focus on getting add/list/search fully working by the deadline.

Example: Team 'PixelPenguins' scope carefully

PixelPenguins choose a text-based “Guess the Number” game with a twist: it logs previous guesses to a file. They make sure the README explains why it’s useful as a teaching tool for beginners, and list “Adding multiplayer mode” as a possible future idea, not part of this semester’s scope.