You are completely free to choose the tool for your presentation: PDF, Powerpoint, Keynote, Jupyter Notebooks, live coding, whatever. Just, please also make the sources available in the GitHub repo (more about the repo below)

If you choose Jupyter Notebook, please do *not* create a huge notebook where you then scroll up and down all the time during the lecture: this has proven to be very confusing for the students and it defeats the idea of allowing them to play around with the code, because they spend most of their time trying to locate on their little screen the exact spot you are showing on the projector

Every lecture gets its own repo on GitHub under the ASPP organization. The repos will be created in the next days, you can find the link from the schedule: https://aspp.school/wiki/schedule

You don't have to use that repo for developing the lecture material: feel free to use whatever repo you are already using. That repo is meant to be for long term storage of the exact material (including exercises and solutions) that has been presented at ASPP2021 and should not be changed after the school. So it is fine to just copy the relevant material on that repo a couple of days before the lecture

You don't need to specify the link to the repo in your presentation. This has proven to be very confusing, because students try to type the link in their browser, make typos and waste time trying to find the right spelling. You can just tell them to follow the link from the schedule. If you intent to work on a fork of the repo under the ASPP organization, do *not* give the students the link to your fork: this messes up the following points

Any exercise of a significant size and that includes a significant amount of coding should have a stub solution in form of a python file in the repo. Short exercises that can be executed directly in the notebook or that do not imply any significant amount of coding can live in a notebook and do not need to follow the procedure below.

You will ask students to fork the ASPP repo to their own personal account and work on a solution there together with their peer. When they are ready, they will post a PR against the ASPP repo. If every exercise has its own stub solution file already in the repo, this will make sure that all PRs are against the same file, which helps avoiding confusion. Given that the first lecture is the one about git, students will have all the required theoretical knowledge to manage this. Experience shows us that the beginning will be with some hiccups, but they will become PR-professionals until Thursday, when managing PRs and creating forks and such is going to be vital for the pelita project. For all of this to work smoothly it is important that you don't mention your fork of the ASPP repo, or students will be confused and some will fork from your repo instead of the ASPP's one, etc..

The above system with PRs makes it possible for you to have a look at some proposed solutions and comment them, also in terms of coding style and such: this is very cool for the students and they learn a lot from this. You can then decide if you want to merge a PR as-is, if you want to ask the corresponding team to fix the PR for you, or you can decide not to merge anything and just commit your own solution

Every exercise of significant size should have solution posted at the latest at the end of the lecture: this is for posterity.