You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following comments were left by @hsaunders1904 following his delivery of Section 4
In one of the exercises, pupils are asked to resolve comments made by their partners on a PR. The exercise says that if there isn't time to resolve a comment, they should open an issue and link back to the comment. Many of the pupils didn't seem to know what an issue was, and issues are disabled on forked GitHub repositories by default. So there was a decent chunk of time a) explaining what an issue was, b) showing how to enable issues (after working it out ourselves) and c) showing how to open one, which I think was out of the scope of this section and is covered in section 5.
While the advice in the exercise is obviously good advice, it did lead the class down a bit of a rabbit-hole. I'm not aware of any students that actually ended up opening an issue at this point.
In the 'Empathy in review comments' slide, one of the bullet points says:
'Only provide a few non-critical suggestions - you are aiming for better rather than perfect'
Which I don't really agree with. I don't think pupils should go away feeling like the number of comments they make on a PR should be limited. They should make as many comments as they feel are appropriate; particularly if the PR is on the larger side. I took this bullet-point out when delivering the course.
In the 'Code Review in Your Own Working Environment' exercise, I didn't get any feedback/conversation at the end. This may well just have been due to the way I delivered it, but for instructors delivering this section in the future: it may be useful to talk through an example process, or write some questions at the beginning of the session that will be asked at the end. I think this might help with engagement.
I felt the break time was misplaced in the slides. We broke after the code review section (which had lots of time-consuming exercises), then got through the reuse and packaging sections (which were less exercise heavy) after the break.
The text was updated successfully, but these errors were encountered:
The following comments were left by @hsaunders1904 following his delivery of Section 4
In one of the exercises, pupils are asked to resolve comments made by their partners on a PR. The exercise says that if there isn't time to resolve a comment, they should open an issue and link back to the comment. Many of the pupils didn't seem to know what an issue was, and issues are disabled on forked GitHub repositories by default. So there was a decent chunk of time a) explaining what an issue was, b) showing how to enable issues (after working it out ourselves) and c) showing how to open one, which I think was out of the scope of this section and is covered in section 5.
While the advice in the exercise is obviously good advice, it did lead the class down a bit of a rabbit-hole. I'm not aware of any students that actually ended up opening an issue at this point.
In the 'Empathy in review comments' slide, one of the bullet points says:
Which I don't really agree with. I don't think pupils should go away feeling like the number of comments they make on a PR should be limited. They should make as many comments as they feel are appropriate; particularly if the PR is on the larger side. I took this bullet-point out when delivering the course.
In the 'Code Review in Your Own Working Environment' exercise, I didn't get any feedback/conversation at the end. This may well just have been due to the way I delivered it, but for instructors delivering this section in the future: it may be useful to talk through an example process, or write some questions at the beginning of the session that will be asked at the end. I think this might help with engagement.
I felt the break time was misplaced in the slides. We broke after the code review section (which had lots of time-consuming exercises), then got through the reuse and packaging sections (which were less exercise heavy) after the break.
The text was updated successfully, but these errors were encountered: