7
edits
Changes
→General tips
== General tips ==
*Do not assume experience with Git or the Command Line. Be careful about the Bash shell as well. If you want your attendees to have familiarity with certain tools, don’t assume that they do. It is especially annoying if you go to a workshop where those tools are not the focus, but it is assumed that attendees are well-versed in them. Generally, be very explicit about requirements, both in terms of software and in terms of experience. Specify what people will need to get started and throughout the process up-front, and what concepts they'll need to be familiar with to get benefits from the workshop.
*At the same time, when teaching it can be good to send people to do an exercise and, if they can't figure it out or run into issues, they can use git to move further along in the program so they are caught up with the rest of the class. However, if git is not the focus of the workshop and it is not an assumed skill, the git commands to do so should be very clearly communicated to the attendees.
*Avoid sports metaphors or idioms that may not make sense outside a certain cultural group. If attendees need to have knowledge of a particular domain prior to taking the workshop, that should be clear in the workshop description.
*Asking attendees to raise their hands if they need help is problematic. It is ableist. It also requires people to self-identify as needing help in front of a room of their peers. One alternative approach is to provide attendees with two different color post-it notes. As the workshop progresses, they attach one color to the top of their computer when they have finished an exercise. They use another color to indicate when they need assistance. This still requires self-identification of needing help to an extent, but it is not as obvious as raising a hand.
== Gaining teaching experience ==
