How to Fill the Feature Sponsoring Contract

Complete the form together before class, but leave the gray tutor fields and all signatures empty. Be concrete: another student should be able to understand exactly what will be built and how completion will be checked. A checked box becomes part of the contract; an unchecked box does not.

A-B: Identify the contract and teams

A1 is assigned by the tutor. In A2, choose a short memorable name, such as Easy CSV Export.

In B1-B4, use the teams' official names and exact course-section codes. The sponsoring team offers points; the sponsored team builds the feature in its own project.

C: Identify the existing starting point

A GitLab reference is an exact pointer to something in GitLab. Do not write only “our repository” or “the login issue.” Use references such as:

Use C1-C2 for the existing feature issue and project. Select and complete either C3 or C4 to freeze the starting code version. Use C5 only when another reference needs explanation.

D-E: Describe the user-facing promise

Choose D1 for a new user-facing function or D2 for an improvement users will directly notice. In D3, name the users; “everyone” is usually too vague. In D4-D5, state what those users gain and what the software will do.

Example: “Project administrators can export the currently displayed participant list as a CSV file containing name, email, and status.”

Use E1 to list what is included and E2 to prevent misunderstandings. Example exclusion: “Custom column selection and Excel formatting are not included.”

F-G: Decide how completion and quality will be checked

Select at least one check in F1-F4, then complete its smaller fields. Never leave words such as “agreed tests” unexplained: identify the issue section, environment, steps, command, scenario, and expected result. Use F5 for any additional observable check.

Example: “On Firefox and Chrome, open Participants, filter status to Active, select Export CSV, and receive a CSV containing only the visible active participants.”

In G1-G5, check only the quality obligations you actually expect. Use G6 for a concrete extra condition, not phrases such as “good quality” or “clean code.”

H-J: Record evidence, points, deadline, and additions

In H1-H5, state where evidence will be stored. Future merge-request or job numbers are recorded on the completion form; here, identify the target project, planned file, pipeline, issue, or demonstration.

In I1, write the whole number of bonus points offered. In I2, write one unambiguous deadline with date and time, for example 2026-10-19 23:59. The deadline cannot be changed after approval. Use J1 only for additional agreed conditions that do not contradict the rest of the form.

K-L: Check, sign, and ask for approval

Before signing, both teams should read the complete form, especially the point-loss conditions. The required representatives sign in K1-K2 using their names, Neptun codes, and signatures. Do not sign before the in-person contract process. The tutor completes A1 and L1-L4.

Final check: Is the feature user-facing? Is the starting version exact? Can someone follow the acceptance checks without guessing? Are all checked obligations realistic before the fixed deadline? If any answer is no, improve the form before signing.