Machine Learning Tokyo is a nonprofit organization dedicated to democratizing ML. We’re a core team of ML Engineers and Researchers and a community of 3,000 members in Japan. Our mission is to create, grow and sustain an inclusive, collaborative and engineering-focused environment. In the past we have organized more than 50 hands-on Machine Learning and Deep Learning workshops, study groups and paper readings and provided more than 250 hours of study and implementation. Our team created this list of best practices for internal use but we thought it might be helpful for other communities as well. Feel free to drop us a line or add things we might have missed in the comments.
Deep Learning Workshops
(1) We usually work with Google Colab at our DL workshops. Folks have different hardware, operating systems, browsers, frameworks, IDEs, they might have never heard of Jupyter Notebooks, and they would have to install different requirements for each workshop. (we’ve been through this. it’s not fun.) With Colab everything is done within the notebook regardless of the aforementioned issues. Note: It’s free and easy to access, but participants have to have a Gmail account. Also, this is not the only solution (e.g. virtual environments) but it has been the easiest and most efficient solution for us.
(2) Please take a moment to explain what Colab is and how to access it. This will save a lot of time and headaches. Most importantly: Make sure that the code in a Colab Notebook runs without errors from top to bottom. Write clean code. Document well. Talk to your team members to review your code and run it on their machines. The goal of every notebook is to be self-explanatory and reproducible.
(3) Treat workshops as standalone sessions. Never assume that your audience knows what you have covered in previous workshops (unless it’s an explicit prerequisite, but even then you’ll most likely have participants who didn’t attend previous sessions).
(4) Data pipelines. If you use toy datasets that you just import and download within the notebook (e.g. MNIST) everything should be smooth. If you use custom datasets or people need to do build individual datasets (e.g. scrape images) be prepared that these things take time and there will always be people having issues.
(4)(a) Always have one or two TA’s that have your back!
(5) Less is more. Go over one topic properly and slowly so that people have something that works and can be reproduced anytime after the workshop. We mostly code live from scratch and go line by line. Dimitris likes to involve the audience sometimes, by saying “Now, what do I write?” That’s always a good idea. 🙂
(6) Know your audience. The best thing would be to have the attendees fill out a form before the workshop to understand their level and backgrounds. If this is not possible, do it on the spot: Ask some questions related to the knowledge, theoretical background and practical skills of the attendees at the beginning of the workshop. Usually the description of the workshop sets some standards that are not followed. Be prepare to adapt your presentation based on the level of your audience.
(7) Involve the audience e.g. by asking questions during the workshop. The more active one is the better she or he can understand and remember new concepts.
(8) Adapt your speaking style. When you explain something hard or complicated, give some time to the audience to process it, say something casual, even a joke. Don’t try to have a constant/monotonic mode while presenting.
(9) Time and practice your presentation at least twice so that you know how long it takes, internalize the code and the structure of the presentation etc. It is often the case that you will want to change things in your presentation/code after a rehearsal.
(10) If you are going to write code live and from scratch practice it again and again! It will take time but it is the only way to make sure that you know exactly what you should do. The conditions are different when doing it at the workshop, distractions, less focus, questions from the audience, necessity to explain things… Be sure that you can reproduce the code at least 3 times in the row without mistakes before you do it live. Bear in mind that it always takes longer at the workshop.
(11) Sometimes you will get questions on technical stuff or math that you don’t know the answer to. Just say that you don’t know or you’re not sure, it’s normal and totally fine. Maybe even ask the audience. Typically someone knows the answer or at least something that can help. This is a community, we’re a team. So things we don’t know we’ll figure out together.
(12) We always encourage participants to ask questions. But sometimes people are too shy to speak up, that’s why there is also an option to ask online questions. There are some great tools for engaging the audience in different ways, which is generally always a good idea.
(13) Ask for feedback about the workshop and make the feedback form accessible during the workshop itself. This is very valuable and will help to improve not only workshops, but you as a presenter and instructor.
(14) We sometimes prepare a document (cheat sheet) which briefly summarizes the topics covered during the event. It’s also nice to give the printed version to attendees.
Paper Reading Sessions
(2) Tell people to prepare 2 questions to ask at the beginning of the session (or in general follow these guidelines on how to lead a technical reading group).
(3) Don’t expect people to actually follow the 2 previous points; prepare a brief presentation summarizing the paper. 🙂
(4) Keep the group small (6 to 10 people + reading leader should be ok).
(5) Convince people that it’s okay to ask any question related to the paper; there are no dumb questions. The idea of the reading group is for everybody to learn something and have their questions answered.