Course assessment will be divided into 4 parts:
- Class participation: 15%
- Preliminary report and presentation: 25%
- Biweekly meetings and reports: 15%
- Project work, final report and presentation: 45%
Students are expected to assess and reflect their project experience according to their acquired theoretical knowledge.
You will receive mandatory reading material in the first few weeks of the course that will then be discussed in class. We ask for active participation from every participant.
Moreover, we will host a variety of guest speakers. Again, participation is mandatory and active engagement will count positively to your final grade.
The preliminary report is a moderately detailed study of your chosen FLOSS project (6–8 pages). The study should cover all of the aspects of FLOSS development covered in the theory part of the course that are relevant to the project of your choice. In the study, you should seek to demonstrate your understanding of the reading material and show that you are able to present your findings in a clear and concise manner. The study should cover at least:
- Short history of the project
- The motivations behind the project
- The project governance structure
- The project contribution history (e.g. many small contributions vs. few main developers)
- Information on who uses the project
- Information on any interactions or relationships with other projects
- Legal and licensing information
- How contributions are managed
- How communication is managed
- How releases are managed
- Funding structure
If possible you should try to document the discussions and background that led to the choices the project made. You should try, where possible, to research the answers through publicly available materials. If you can’t find the answers that way, then you can contact project members, but you should make it clear that you are working on a university project. Including a link to the lecture website in your first contact with a project member is a good way to do this.
You are expected to give a short (10 minutes) presentation in one of our sessions presenting your findings.
Students are expected to meet biweekly with their supervisors and submit a short report (around half a page) answering the following questions:
- Which actions did you take?
- Which interactions have happened since your last meeting?
- Describe your progress! Did you face any problems?
- What are you planning to do in the next 2 weeks?
Project Work and Final Report
The main part of the course comes from you working on a FOSS project of your choice. There are no strict rules on what form that work should take, but you should try to choose something that demonstrates your ability to work with the project, and demonstrates your understanding of the principles of FLOSS collaboration.
Assessment for this portion of the course will be based on a report (10–13 pages) that you write that describes your involvement with the project. In the report, you should critically assess your involvement. You should reflect on both your communications and contributions. Moreover, we expect you to describe how you interacted with the community and maintainers of the project. To assist you in writing that report, it might be useful to keep copies of email exchanges with the project, plus logs of chat interactions and copies of relevant web pages (for example bug submissions).
It is important that the work you do for this part of your assessment is not done in isolation from the other contributors to your chosen FLOSS project. You should not work alone on a patch or contribution and then submit it to the project at the last minute. Instead, you should discuss your contribution as soon as possible, and actively participate in a cycle of review and improvement, with the aim of producing a useful contribution to the project.
It is not a requirement that the project accepts your contribution to get a good mark for this part of your assessment. What you should aim to demonstrate in your report is that you are following the established practices for your chosen project, and that you have been working towards a useful contribution.
You also do not need to restrict yourself to a single contribution to the project. For example, you may wish to make contributions to several different areas of the project. Contributions to the documentation, web pages, test suites, and bug handling can be just as important as contributions to the projects source code.
Finally, you are again expected to give a short (10 minutes) presentation in one of our sessions presenting your most intriguing experiences.
Guidelines for the Project Report and Final Presentation
The main objective of your final report is to
- describe the work you have done in the project phase on a high-level,
- summarize the lessons you learnt during the semester, and
- critically reflect on your project work including communication with the community.
The text should be written in a scientific style, i.e. you should abstract from irrelevant details, back up your claims with references, and use succinct language. For both the level of detail and focus you can imagine your fictive reader to be familiar with computer science and the basics of FLOSS (e.g. your fellow lab course students). The report should not be an aggregation of your biweekly reports nor be of a technical nature (don’t get into technical details!). Instead, it should contain a more general and high-level summary and reflect on your work and experiences.
Here is a list of necessary aspects that should be covered in a good report:
- A very brief summary what the project is about; you can refer to your preliminary report for details
- Reflection on your preliminary report: did you change your mind in some aspect? Did reality coincide with your expectations?
- A succinct description of all issues you worked on including references to them
- Summary of your communication with the community (maintainers and other contributors)
- Give us one more detailed story about the process of one of your contributions
- Critical assessment of what went well and what went wrong in your contributions. Yes, you should be critical - admitting mistakes won’t negatively affect your grade.
- Constructive feedback on what works well/not so well in the project, e.g.
- communication: strategies and platforms, wording (e.g. Is it inclusive? Is it clear?), etc.
- project management
- transparency and community involvement (e.g. for decision processes)
- community engagement
Some nice-to-haves for a very good report:
- Relate your work with what you learnt in the theory part
- Relate your work with what you heard from the speakers
- Comment/report on some special/unique aspect of the open-source projekt you worked on
- Suggestions to improve the contribution process of the project. Do you have ideas to make it more engaging, more transparent, more fun?
- Your own ideas, visualisations, …
While the above list suggests a rough structure, you may very well deviate from it. Once again, we remind you that it is not a requirement that your pull-requests were already merged by the community nor that you necessarily wrote many lines of code. You should explain what your contribution was, what the problems you encountered were, how you tackled them, and what can be learnt from that effort.
The final presentation should talk about the final report in the sense that it should summarize what one would find when one reads it, highlight the main learnings, and motivate the audience to read the report. You will have to explain the necessary context for the audience to understand what you are explaining. The talk should be no more than 10 minutes, and there will be 5 more minutes for questions.