Suggested activities & evaluation

The seminar was designed giving a significant importance to practice. For this reason, we involved two practice partners, and invited them to present their projects in the second session of the seminar. Students chose a project of their preference, and therefore two groups of 4-5 students were formed.

Students had to think of a contribution they could make to the practice partner’s project. This contribution had to be related to open source hardware and touch on any of the modules we taught. But it didn’t have to necessarily involve designing or prototyping. For example, students could propose a new hardware or software feature for a project, but also could perform an analysis of the business model, test a product to provide exhaustive feedback and alternatives for improvement, design and write documentation, etc.

Students were free to choose their project as a group, and we supported this decision along the seminar in different ways. When they met the practice partners, we facilitated a brainstorming exercise. Then, mid-seminar, students had to do an interim presentation. The goal here was for them to present their plan and receive feedback before investing time and effort.

At this point, we mostly assessed the scope and incentivized students to go as concrete as possible with their project, even if it was a very specific one. By the end of the seminar students presented their work to everyone including the practice partners, and had to deliver a final report one month later. We used these instances as components of grading. Following university guidelines, students were evaluated considering content, format and presentation.