Feature Definitions
Salary
This task pays a fixed salary of 12 MVP points, plus up to 30 quality points for exceeding the minimum requirements — for a total of 42 points, with a maximum of 7 points per person.
Background¶
This section guide you to some additional material that will help you understand the task better. It is not mandatory to read it, but it can be useful for your team.
Minimum Viable Product (MVP)¶
By the end of this task your team has at least six features clearly defined for your chosen project. A “feature” here is a small, user‑visible capability (e.g., “Add a book,” “List all books,” “Search by keyword”). Keep features simple and finishable by beginners within a short time; avoid vague items like “Improve program” or “Refactor everything.”
For the MVP, create one GitLab issue per feature. Each issue must briefly state the goal or benefit in plain language (one–two sentences) and include a short usage example (“As a user, I can… so that…”). These issues will guide your planning, prioritization, and pricing later.
Example: Team 'ByteBusters' define 6 features for a Library Catalog
They create issues: Add book, List books, Search by title, Delete book, Save to file, Load from file. Each issue has a one‑line benefit (“Search helps users quickly find a book”) and a tiny usage note (“User enters a keyword; matching titles are shown”).
Technical Details¶
Create a simple issue template (or copy‑paste) with these fields:
- Summary (1 line)
- User value (1–2 sentences: who benefits and why)
- Usage example (Given/When/Then or “As a user…” line)
- Done criteria (what must work to claim MVP for this feature)
- Labels: feature
Store the six (or more) issues under your project and add a ## Planned Features section in README.md that lists their titles with links. Keep scope beginner‑friendly for procedural Python or CLI Java (e.g., text menus, file I/O, basic search/filter), and avoid external services for now.
Quality¶
Quality means each feature is unambiguous, useful, and tied to a real use case/domain. Anyone reading the issue should understand what will be delivered and why it matters. Add a tiny acceptance example (e.g., “Given a catalog with ‘Dune’, when I search ‘Dun’, then I see ‘Dune’ in results”) and a clear done list (inputs, outputs, error message if something is missing). If a feature depends on another, link it (“Load from file depends on Save to file”).
Use simple, consistent naming and avoid overlaps (“Search by title” vs “Filter by keyword” may be the same). Prefer vertical slices that show value end‑to‑end (input → processing → output) over low‑level tasks (“Create Utils class”). This keeps the project focused on user value and makes estimating and testing easier later.
Example: Team 'NullPointers' make features crisp
They rewrite a vague “Improve file handling” into two clear features: Save to CSV (user can export), Load from CSV (user can import). Each has a tiny Given/When/Then and notes the dependency (Load depends on Save’s file format).
Example: Team 'PixelPenguins' keep it user‑focused
For a simple cellular automaton, they define: Create grid, Toggle cell state, Step one generation, Run N steps, Save pattern to file, Load pattern. Every issue includes who benefits (“Beginners can experiment step‑by‑step”) and what “done” looks like (“After 10 steps, the program prints the final grid without crashing”).