Teaching notes
Based on the pedagogical concept. Administrative tasks are here.
Week | Duration | Topic | Preparation | Session Notes |
---|---|---|---|---|
1 | 90 min | Topics | Preparation | Session notes |
2 | 180 min | Git | Preparation | Session notes |
3 | 180 min | Python 1 | Preparation | Session notes |
3 | 180 min | Python 2 | Preparation | Session notes |
4 | - | Group-work | - | |
5 | 90 min | Best Practices | Preparation | Session notes |
6-11 | - | Group-work | - | |
12 | Flexible | Code Review | Preparation | Session notes |
Preparation
- Announce project on instagram
- Advertise the project in the lecture or other courses based on the mailing - check if not applicable
- Update dates and rooms for sessions
- Update the rating average in the badge (change the badge-link on index.md) and participation
- Review the pedagogical concept in preparation of the project
- Check whether
pre-commit run --all
runs without errors in Codespaces - Check whether
colrev package --init
works
Student communication notes
The overlap is a bit unfortunate and it is difficult for me to understand whether you will be able to contribute to the project work if you miss these sessions. At the same time, I would like you to participate in the project, and prior experience with Python and Git certainly helps.
What I would suggest going forward is to check the materials of the sessions (available at https://digital-work-lab.github.io/open-source-project/), and to start finding a team (as described in the slides for the first session). Naturally, we expect everyone, including yourself, to contribute equally to the project.
If you have any questions on the process or materials, please let me know - I am happy to help.
All of the following items must be completed before the session unless stated otherwise.
Week 1: Topics
- Send out welcome and information mailing before the first session
- Link the feedback issue in VC, explain our process of evaluation and improvement, summarize our improvements from last semester
Week 2: Git
- Check whether the
rec_dict.patch
applies (git diff > rec_dict.patch
) - Carefully prepare the explanation of branching and committing (focusing on the states of a file and explaining the commands and state changes based on the workflow).
- Print some of the overviews
- Send out comment-on-issues mailing
Week 3: Python
- Prepare the
tutorial_python
branch and update the commit-SHAs in the notebooks
Python prep
git checkout tutorial_python
git branch tutorial_backup
git rebase -i HEAD~16
# edit the "update click" commit (before the tutorial starts) with the latest pyproject.toml
git rebase main
git push -f
When the pyproject.toml fail: checkout –ours pyproject.toml, poetry add bibtexparser
- Update git-commit SHAs in the notebooks
-
Test the tutorial in Codespaces
- Create a list of topics and students (first/second choice) and facilitate issue discussions
Facilitating issue discussions
Thank you, @pmao0907 and @MingxinJiang for offering to switch to #360 . This leaves a group of 3 with @CelinaSchwarz , @omanovb and @QuynhMaiNguyen 👍 Can you select a group lead, fork the repository and link your repository in this feed?
Week 4: Group work (no session)
- Distribute the survey via VC, asking students to upload it (upload box).
- Send out the prep-best-practices mailing
- In the issue feeds, ask students to link their fork
Week 5: Best practices
- Review responses from the survey and prepare the session
Weeks 6-11: Group work / Hacking sessions
Guidelines for the hacking sessions:
- Ask questions instead of offering solutions
- Suggest the use of Iterators for API retrieval
Week 7
- Send out hacking-sessions mailing
Week 10
- Send out pull-request mailing
- Send out evaluation mailing
Week 12: Code review
The code review session should be in my office (with a Computer screen connected via a long HDMI cable).
- Print and pre-fill evaluation sheets
- Check whether connectors (e.g., HDMI) are required and provide them
- If projects require access tokens (API keys), provide them to the group
- Remind students to complete the evaluation
After the session:
- For implementing the feedback from the pull request, we should ensure that efforts are fair between teams (e.g., selecting issues to address or adding suggestions)
- Include a summary of todos in the pull request
Hello @x, @y,
following up on the code review session, I took the following notes. Please address them by **XXXXXX**:
- [ ] Fix the pre-commit warnings (the line-too-long warnings can be ignored in the test files)
- [ ] Reduce information printed when running `colrev search` (ideally, one line per record)
- [ ] Add the volume/number fields (if possible)
- [ ] Remove unnecessary files/changes from pull request (e.g., `.pre-commit-conig.yaml`, `colrev/ops/search.py`, or the `search` submodule)
If there is anything I can help with, please let me know 👏
After feedback was implemented by the students
- Send out project completion mailing
- Notify students about the option to observe the merge and release process (Zoom meeting)
- Merge pull requests and add contributors (see merge-notes)