Instructor Notes
These notes come from the first in-person run of the course (HU Berlin library, morning of 2026-09-24) and the feedback gathered afterwards. Items marked to confirm are proposals that have not yet been checked against how long the Berlin run actually took.
Who the course is for
The course is written for librarians, not for researchers or engineers. In Berlin, participants knew metadata, versioning, knowledge management and long-term preservation well, and knew little about engineering, the hardware life cycle, or quality control. Start from what they know and say clearly, early, why the course is for librarians. See the learner profiles for examples of who to expect.
Pacing and time
Each episode is currently listed with 20 minutes of teaching and 10
minutes of exercises, so the five episodes add up to about 2.5 hours
before breaks, introductions and feedback. The listed times have not
been checked against a real run. To confirm: compare
them with the Berlin timings and update the teaching: and
exercises: values in each episode.
Suggested structure for a half-day session (to confirm):
| Block | Content | Notes |
|---|---|---|
| Opening | Icebreaker and introduction | Keep the icebreaker to 30 minutes at most |
| Episodes 1 to 3 | Introduction, how OSH works, licensing | Short break after the licensing episode |
| Feedback check-in | Short group discussion | See below |
| Episodes 4 and 5 | Best practices, communities | |
| Close | Questions and written feedback |
Icebreaker
Open with questions that start from what participants know: “What do you work on? What do you know about open science hardware? What do you think it is?” Take no more than 30 minutes. Use the answers to link back to things the group already knows, such as open data, open software and git forges, science communication, patents and licensing, and the local research community.
Breaks and feedback sessions
Plan at least one break and one feedback check-in. Berlin participants suggested making these explicit, so decide in advance when they happen and how long they last, and tell the group at the start. A check-in can be as simple as asking what is unclear so far and what the group wants more of. To confirm: when and how long they ran in Berlin, and what worked.
Discussion prompts
- In the licensing episode, ask: “What do you currently tell your researchers about licensing?” The answers show where participants already advise on licenses and where they are unsure.
- When discussing why researchers hesitate to share, note that “open” can feel risky because of fear of being scooped, and that being cited can be a strong incentive.
Course length options
The course can run as a three-hour beginner course, or as a longer or more advanced course. Participants in Berlin suggested this split, and the beginner version could still cover all five episodes at an introductory level. Licensing in particular is covered at introductory depth and could be a separate course.
Invite a project developer
If you can, invite the developer of an open science hardware project to join a session live. Hearing how a real project was built, documented and shared makes the topics concrete, and the complete story of a project can also stand alone as a case study. This is a suggestion from the Berlin run, not yet part of the course.