Bonus points
Bonus points are extra points that belong to your team. Your team can earn, lose, spend, and transfer them during the semester. Their purpose is to reward active participation and encourage professional collaboration between teams.
At the end of the semester, your team may distribute up to 40 remaining bonus points among its members. The distribution does not have to be equal, but the team should agree on it. These points can then be added to the members’ grading points.
Bonus points can become a debt
Your team’s bonus-point balance can be negative, but it cannot go below −30 points. A negative balance must be distributed among the team members at the end of the semester and will be deducted from their grading points. The team cannot choose to ignore this debt.
Earning Bonus Points¶
Active Participation During Class¶
Your team can earn bonus points by actively contributing during class. Active participation includes:
- answering questions;
- sharing useful ideas and experiences during discussions;
- asking relevant questions that help the class move forward;
- taking an active part in class activities.
You do not need to give a perfect answer to participate. A well-explained attempt, a useful question, or a different point of view can also help the class and may earn bonus points. The points are awarded to the team, even when one team member earns them through their participation.
How many points can your team earn?
During each class, there will usually be an opportunity to earn 0–10 bonus points through active participation. A team that participates regularly can expect to earn around 3–5 points per class. These numbers are planning guidelines, not guaranteed rewards: the actual number depends on the available activities and the quality of the team’s participation.
Weekly Expected Results¶
For most weeks, your team will receive a list of Expected Results Before This Week. These work like homework: they describe what your team should complete before the next class so that you can take part in the following activities. Only work recorded in your team’s official GitLab project before the class counts.
Completing the expected results at an acceptable level does not automatically earn bonus points—it means your team arrived prepared. However, high-quality or especially thorough work may earn bonus points. Missing, incomplete, or inadequate work may result in a deduction.
At the beginning of the class, some teams may be selected to present their results. Therefore, every team should be ready to show and briefly explain its work.
Contracts Between Student Teams¶
Teams may make contracts with each other and use bonus points as payment. For example, one team may provide a service to another team, such as giving structured feedback, testing a product, or sharing relevant technical knowledge. Teams may also sponsor another team’s work when they consider it useful or valuable.
These contracts are not only about exchanging points. They give you an opportunity to practise professional communication and collaboration: clearly describing what you need, agreeing on responsibilities and results, documenting the agreement, and delivering what was promised.
Detailed contract rules
The available contract types and the rules for creating, documenting, completing, and paying contracts will be described later on this page.
How Can Your Team Use Bonus Points?¶
Using Points During Final Grading¶
At the end of the semester, your team may convert up to 40 remaining bonus points into regular grading points. This is a limit for the whole team, not for each team member. The team decides how to distribute these points among its members, and the distribution does not have to be equal.
Your team does not have to use its remaining positive points. However, a negative balance is a debt and must be distributed among the team members and deducted from their grading points. The team cannot choose to ignore it. The team’s balance cannot fall below −30 bonus points, so this is the maximum possible debt for the whole team.
Contracts Between Student Teams¶
Your team may spend or transfer bonus points through contracts with other student teams. You may use the points to purchase an agreed service, such as structured feedback, product testing, or technical assistance. Your team may also sponsor another team’s work without purchasing a service in return—for example, because the planned result would also be useful to your project.
The bonus points are transferred from one team’s balance to the other team’s balance according to the contract. Before any work begins, both teams should clearly agree on what will be provided and how many points will be transferred.
Detailed contract rules
Detailed rules for contracts, payments, and sponsorships will be added later in this page.
Team-to-Team Contracts¶
Software engineers rarely work only within one team. Real projects often depend on other developers, testers, specialists, customers, and external service providers. Team-to-team contracts give you a safe way to practise this kind of cooperation during the course. Your team may request knowledge, feedback, testing, or extra capacity that it cannot efficiently provide on its own, while offering its own skills, tools, experience, or useful project results to others. To do this successfully, you must clearly explain what you need, agree on the expected result, communicate during the work, and build trust by documenting responsibilities, deadlines, and payment. Bonus points act as a limited budget, so your team must decide when outside help is worth its cost and when providing a service is worth the effort. You may also sponsor work that benefits your project, several teams, or the wider course community without receiving a direct service in return. These are important software engineering skills because creating a good technical solution is not enough: you must also coordinate with others, manage resources, keep agreements, and help different people work toward a shared result.
General Rules¶
Team-to-team contracts are formal agreements. Both teams must understand and accept the conditions before signing.
- Contracts may only be created and handled during scheduled classes.
- Contracts may be created during any scheduled class from Week 4 until Week 11, or until the last class if it takes place earlier. The teams set the completion deadline, and the tutor transfers the agreed bonus points during the week when completion is properly proven.
- The agreement must be recorded by hand on the official form.
- A contract becomes valid only after the tutor has reviewed, approved, and signed it.
- A contract may only concern code or documentation that already exists. The tutor will check this before approval.
- A team with a negative bonus-point balance may not enter into a new contract. Existing valid contracts remain in effect.
A majority of both teams must be present: at least 3 members from a 4- or 5-member team, or 4 members from a 6-member team. Each participating student must verify their identity.
Prepare the contract before class
Contract handling is much faster if you discuss the agreement and complete the form before class. Leave the signatures empty until the contract is handled in class. A clear and correctly prepared contract may also earn bonus points.
Ethical and professional conduct
Both teams must act ethically and professionally throughout the cooperation and follow the course standards during the entire contract process. If these expectations are not met, the tutor may, at their discretion, deduct up to twice the number of bonus points stated in the contract from either or both teams.
Contract Completion¶
All contracts follow the same completion process. The teams must write a completion deadline on the contract before it is approved. This deadline cannot be changed later, so both teams should plan carefully, consider possible risks, and allow enough time to complete the work.
At the first in-person class after the deadline:
- Both teams must be present according to the attendance rules.
- They must bring the completed contract completion form.
- The team receiving the service must use the form to confirm whether the agreed work was completed.
- The tutor records the result and transfers the agreed bonus points. The tutor does not evaluate the service as a customer; they act only as an ethical moderator.
If the teams do not present the completion form at this class, both teams lose the number of bonus points stated in the contract. The deduction is recorded and applied when each team distributes its points during final grading or earlier.
Breaking a contract
If one team breaks the contract, that team must pay the other team half of the agreed bonus points as compensation. This compensates the other team for lost time, preparation, planning, reserved capacity, or work performed based on the agreement.
Tutor intervention
The tutor may terminate a contract at any time if, based on their professional judgement, they identify misuse, unethical conduct, or an inappropriate professional attitude. Any related point transfers or penalties will be decided according to the circumstances and the course rules.
Contract Types¶
Teams can use four types of contracts, depending on what kind of cooperation they need. In every case, the contract must start from an existing and clearly identified GitLab artifact, describe the promised work, and define a concrete result that can be checked at completion.
| Contract type | What is it for? | Starting point | Expected result |
|---|---|---|---|
| Feature Sponsoring | Supporting a useful feature in another team’s project | Existing feature issue and exact code version | The sponsored team implements the feature in its own project |
| Implementation | Asking another team to implement a fix or feature in your project | Existing issue and exact code version | A merge request with the implementation and agreed supporting materials |
| Review | Asking another team to inspect your work and give professional feedback | Exact version of the artifact to review | A written review with explained findings and useful suggestions |
| Testing | Asking another team to try your software in agreed situations | Exact executable version and instructions | A test report describing what was tested and what happened |
Feature Sponsoring¶
A Feature Sponsoring contract allows your team to support the development of a feature in another team’s project. Your team does not receive the feature in its own codebase. Instead, it promises bonus points because it considers the feature useful, interesting, or valuable. The sponsored team earns the agreed points by implementing the feature in its own project and providing the agreed evidence.
This is similar to Kickstarter, crowdfunding, or internal company funding. A team presents an idea and explains why it is worth supporting. Other teams decide whether they trust the proposal enough to commit part of their limited bonus-point budget. The sponsored team then has to deliver what it promised.
A Feature Sponsoring contract must specify:
- Starting point: an existing GitLab issue and a link to the exact version of the code before development begins, such as a commit or tag.
- Promised feature: a clear description of the behaviour or result that will be added. The referenced issue must already contain this information.
- Scope: what is included in the feature and what is not.
- Acceptance checks: concrete and observable conditions used to decide whether the feature was completed successfully.
- Required evidence: usually tests, documentation, screenshots, or a working demonstration.
- Agreed points and deadline: how many bonus points the sponsoring team will transfer and when the feature must be completed.
The sponsoring team confirms completion by checking the agreed acceptance conditions. It should judge the delivered result against the written contract—not against new expectations introduced after the work has started. The tutor acts as an ethical moderator and checks whether the process is fair and professional.
Example
Team Pine sponsors Team Fox with 6 bonus points to add CSV export to Team Fox’s application. The contract references the existing feature issue and the current commit. It states that users must be able to export the displayed records as a valid CSV file containing the agreed columns. Completion is shown through an automated test, updated user documentation, and a short demonstration.
Feature sponsoring gives the sponsored team additional motivation and shows that others recognize value in its idea. The sponsoring team learns to assess proposals, compare expected value with cost, and manage a limited budget. Both teams practise presenting ideas, defining scope, agreeing on measurable results, evaluating delivery, and taking responsibility for professional commitments.
Implementation¶
An Implementation contract allows your team to ask another team to implement a bug fix or a new feature in your project. The providing team works with your existing code and delivers the result back to your repository. Unlike Feature Sponsoring, this is a direct service: the team paying the bonus points receives the implementation.
This is similar to hiring a contractor, working with an external development team, or asking another team inside a company to contribute to your product. The receiving team must clearly explain what it needs and provide everything required to begin. The implementing team must understand an unfamiliar codebase, follow its conventions, and deliver work that can be inspected and integrated.
An Implementation contract must specify:
- Starting point: an existing GitLab issue and a link to the exact code version on which the work will be based.
- Required input: repository access, build and run instructions, relevant documentation, test data, configuration, and any other information needed to perform the work.
- Promised implementation: the bug fix or feature that the providing team will deliver.
- Scope: which parts of the system may be changed and what is outside the contract.
- Acceptance checks: concrete and observable conditions used to decide whether the implementation works correctly.
- Quality expectations: agreed requirements for tests, documentation, code style, compatibility, or other relevant qualities.
- Required evidence: a merge request containing the code, relevant tests and documentation, and instructions for checking the result.
- Agreed points and deadline: how many bonus points will be transferred and when the work must be completed.
The implementing team should deliver its work through a merge request and must not merge it into the target branch. The receiving team reviews the result and decides whether it meets the written acceptance conditions. Accepting the contract result does not require the receiving team to merge it immediately, but the decision must be based on the agreed requirements rather than preferences introduced after the work began.
Example
Team Pine pays Team Fox 8 bonus points to fix an issue in Team Pine’s application where uploaded filenames containing spaces cannot be opened. Team Pine provides the issue, the starting commit, repository access, and instructions for running the application. The contract states that files with spaces in their names must upload and open successfully without breaking the existing upload behaviour. Team Fox delivers a merge request containing the fix, an automated regression test, and a short explanation of the change.
This contract helps the receiving team obtain useful development work while learning to describe technical needs precisely. The implementing team gains experience with unfamiliar code, existing conventions, external requirements, and professional delivery. Both teams practise requirements clarification, effort and risk estimation, repository collaboration, code review, testing, documentation, and responsibility for an agreed result.
Review¶
A Review contract allows your team to ask another team for a structured and independent opinion about an existing artifact. The reviewed artifact can be almost anything connected to the project, such as GitLab issues, source code, documentation, a meeting memo, design, idea, pitch, or presentation. The reviewing team does not rewrite or implement the work unless the contract explicitly asks for suggested changes. Its main deliverable is a clear, useful, and well-supported professional opinion.
This is similar to peer review, code review, design critique, expert consultation, or asking stakeholders to evaluate a proposal before investing more work in it. An outside team may notice unclear assumptions, risks, inconsistencies, or improvement opportunities that the original team no longer sees.
A Review contract must specify:
- Artifact to review: an exact and stable GitLab reference, such as an issue, commit, merge request, document version, uploaded presentation, or meeting memo.
- Purpose of the review: what the receiving team wants to learn or improve.
- Review perspective: for example, technical quality, clarity, feasibility, maintainability, usability, completeness, consistency, or persuasiveness.
- Scope: which parts must be reviewed and which parts are outside the contract.
- Review method or criteria: the questions, checklist, guidelines, or standards the reviewing team will use.
- Promised deliverable: where and how the review will be recorded in GitLab, such as a review document, issue, issue comment, or merge-request discussion.
- Expected detail: what each finding should contain, such as its location, explanation, importance, and an actionable suggestion.
- Agreed points and deadline: how many bonus points will be transferred and when the review must be completed.
A review contract must require a meaningful review process and a useful report, but it must not require the reviewing team to find a fixed number of problems. The artifact may already be good, and reviewers must not invent weaknesses simply to reach a quota. Positive findings are also valuable when they explain what works well and why.
Example
Team Pine pays Team Fox 5 bonus points to review six feature issues before development begins. The contract links the exact issues and asks Team Fox to check whether each issue clearly describes its purpose, expected behaviour, boundaries, and acceptance conditions. Team Fox records its review in a new GitLab issue, identifies unclear parts, explains why they may cause problems during implementation, and suggests concrete improvements. If an issue is already clear, the review explains why it is ready for development.
The receiving team gains an outside perspective before mistakes become expensive. The reviewing team learns to examine work carefully, apply explicit criteria, and communicate criticism without taking control of the other team’s project. Both teams practise critical thinking, quality assessment, constructive feedback, professional communication, and making decisions based on evidence.
Testing¶
A Testing contract allows your team to ask another team to examine how your software behaves under agreed conditions. The testing can be manual or automated and may focus on functionality, usability, compatibility, performance, installation, accessibility, or another relevant quality. The activity must be systematic: simply trying the application or clicking around without a plan is not enough.
This is similar to working with an independent test team, quality-assurance specialist, beta tester, or external laboratory. Testers receive an identified version of the software, follow an agreed approach, record what they did, and report what happened. Their task is to provide trustworthy evidence—not to prove that the software is good or bad.
A Testing contract must specify:
- Software to test: an exact executable version identified by a release, tag, commit, package, deployed instance, or other stable reference.
- Required input: access details, installation and usage instructions, test accounts, test data, supported environment, and known limitations.
- Testing goal: what the receiving team wants to learn about the software.
- Scope: which features, user flows, platforms, environments, or quality characteristics will be tested.
- Testing method: the scenarios, test cases, checklist, exploratory-testing charter, tools, or other systematic approach that will be used.
- Expected coverage: a tangible description of the planned work, such as the selected user journeys, input categories, environments, or compatibility combinations.
- Promised deliverable: a GitLab-stored test report describing the environment, performed tests, observed results, and supporting evidence.
- Reporting format: how errors and unusual behaviour will be documented, including reproduction steps, expected and actual behaviour, severity or impact, and relevant screenshots or logs.
- Agreed points and deadline: how many bonus points will be transferred and when testing must be completed.
A Testing contract must not require the testing team to find a fixed number of defects. Well-working software may produce few or no findings. Completion is judged from whether the agreed testing was performed systematically and documented properly. A test that passes is still a useful result, and unexpected but non-defective behaviour should also be recorded when it may help the receiving team.
Example
Team Pine pays Team Fox 5 bonus points to test the registration and login flows of a tagged release. Team Pine provides the deployed address, test accounts, supported browsers, and usage instructions. Team Fox tests the agreed successful and unsuccessful scenarios in two browsers, including empty fields, invalid email addresses, incorrect passwords, and repeated login attempts. It records the environment and results in a GitLab test report and creates separate issues for reproducible defects.
The receiving team gains evidence about its software from people who are less familiar with it and therefore less likely to avoid problems unconsciously. The testing team learns to plan repeatable checks, observe behaviour carefully, separate facts from assumptions, and report results so that another developer can act on them. Both teams practise test design, quality assessment, reproducibility, technical communication, evidence collection, and risk-based thinking.