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
{{ message }}
This repository has been archived by the owner on Jan 2, 2020. It is now read-only.
A work-along is a hands-on guided tour of a piece of code, tool, or other skill. For this type of session we suggest it be about an hour.
Tips
Keep it short. An hour is plenty long enough; more than this, and it becomes too much to absorb all at once.
Keep it simple. That hour will go by really fast for the demo leader - sixty minutes is really only enough time to cover a few introductory ideas. Remember, there's no final exam; if people walk away with a successful first couple of steps on the topic, that's all they need to get started and learn more in future.
Keep beginners on board. This means explicitly illustrating every step, and going slow enough for participants to copy down everything you're doing - so that everyone can follow along.
No slides. Slides can be boring. The presenter should live-demo all their examples, while everyone else follows along on their own machines.
Give people challenge problems. Take a couple of breaks to let your students try their new skills on a challenge problem or mini-project. This also gives you the chance to answer questions, and make sure no one gets lost.
Keep it real. Try and illustrate how you actually use the tool in your research; this way, everyone will understand not only how to use it, but why it's valuable in real practice.
Post the lesson notes. It takes some work to prepare the notes for a lesson - instead of letting them disappear afterwards, put them in a GitHub repository and share them back with the community. If you need help,
Coworking Session
Co-working sessions are a great way to get stuff done and discover new coding techniques. Get your Study Group together for a couple of hours to all sit down and work on their latest coding projects - and encourage everyone to ask each other questions when they get stuck, show off their work and talk to each other about what they're doing.
Tips:
Welcome beginners. Make sure everyone knows new coders are very welcome, and that it's okay to ask any question you like.
Do lightning intros. At the start of the session, go around the room and have everyone call out tweet-length descriptions of what sort of tools and language they're working in that day - and encourage people using similar tools to chat and work together.
Have a demo party. At the end of the session, give people a chance to show off what they're working on to the group - these should be really quick demos, meant to give people just a flavor of what people are doing - and start conversations afterwards.
The text was updated successfully, but these errors were encountered:
What do you say we move this to some kind of docs directory? I'd like to expand on some of this information with some of the more technical things, how to create an Etherpad, how to set up a repo for your lesson and add it to the bulib/studyGroupLessons repo, etc.
Interested in leading a session but not sure what to do?
Here are a few quick tips and ideas from Mozilla's Handbook:
Work-Along
A work-along is a hands-on guided tour of a piece of code, tool, or other skill. For this type of session we suggest it be about an hour.
Tips
Coworking Session
Co-working sessions are a great way to get stuff done and discover new coding techniques. Get your Study Group together for a couple of hours to all sit down and work on their latest coding projects - and encourage everyone to ask each other questions when they get stuck, show off their work and talk to each other about what they're doing.
Tips:
The text was updated successfully, but these errors were encountered: