At the first Astro Hack Week in 2014, we ran tutorials every morning, and hacking in the afternoon. Topics of the tutorials in that year were ipython and ipython notebooks, classical and Bayesian statistics, supervised and unsupervised machine learning. The afternoons were reserved for hacking and break-out sessions (short, informal tutorials on topics that come up during the workshop). Because participants told us during the evaluations after Astro Hack Week was over that they liked the format this way, we kept it essentially unchanged in 2015, but changed the tutorial topics around.
This time, we asked participants what they’d like to learn in the tutorials during the initial applications. This led to the slightly funny situation where participants had to apply to the workshop without knowing all the topics (though they generally seemed remarkably happy to trust us that we’d pick good topics and applied, anyway), but it gave us the possibility to ask applicants what they would like to learn more about (after all, the workshop is for them!). Collating all 167 responses, Phil Marshall and I ended up with the following chart:
From there, we sorted topics into groups and distilled a workable programme based on (1) participants’ preferences, and (2) — not to be underestimated — what we thought we could get speakers for. I liked this way of organising tutorials, and I think the participants got more out of it than if we’d simply decided on something. Our final list of topics was: (1) intro to scientific python and visualization, (2) “big data”, (3) Machine Learning with Scikit-learn, (4) Bayesian Statistics and Sampling, parts I and II.
Astro Hack Week is too short to go into excruciating detail on any of these topics. The aim should be to give participants an overview, and, more importantly, practically useful knowledge so that they can dive right in (and some references so they can read some more on the details or mathematical foundations on their own). Additionally, there will always be topics that are left out. If they turn out to be of overwhelming interest, and there’s an expert in the room, one might encourage that expert to organize a break-out session. Last year, we had break-out sessions on parallelization, software licensing, Approximate Bayesian Computation, Hierarchical Inference and others. Some of these might become full-blown tutorial topics in the future, others might not. As an organizer, I fretted a lot about all the topics we couldn’t fit in, but in hindsight I think that’s largely unnecessary.
The tutorials are designed to be interactive, with preferably short periods of lectures followed by exercises the participants can do themselves. That doesn’t have to be—as Brendon Brewer very successfully showed—a coding exercise. It can be a simple pen-and-paper maths exercise instead. The crucial point here is that it really has to be interactive for participants to take something away from it and be able to apply their newly learned knowledge right away during the afternoons. Jupyter notebooks turn out to be a great tool for that kind of tutorial.
Unlike regular conferences (where the organizing committee rarely also gives talks), we tried to handle as many of the tutorials ourselves. We invited some outside experts for the rest. Additionally, the structure of Astro Hack Week (with a broad range of knowledge in the audience) meant that for any of the tutorials, there would be more experts among the participants. We did not take enough advantage of this during this last Astro Hack Week (and thanks to Kelle Cruz for pointing out that there is room for improvement there and some other excellent advice regarding the tutorials). In the future, I would make it obvious to participants that if they had knowledge on the topic of the tutorial, they should identify themselves to their table and effectively help run with the tutorial during the exercises. This has several advantages to the group as a whole. It helps relieve the pressure on the lecturer(s) during the exercises, where they will be in high demand to answer questions. It also helps those in the room who already know the contents of the tutorial to feel involved, and firms their knowledge by requiring them to explain it.
I think the mix of participants makes Astro Hack Week unlike most other conferences or summer schools. Instead of having a clear structure with an experienced lecturer imparting knowledge and an audience learning, we had participants at all levels of experience in the audience at the same time, some who might be just as expert in that topic as those holding the tutorials themselves. It is important to point this out to the lecturers in advance. One thing I heard from several lecturers at Astro Hack Week (and something I also experienced myself a lot) was anxiety that the tutorial was too easy and not sophisticated enough. That it would bore the more experienced participants in the room. I don’t think that actually happens. I have yet to hear anyone say at Astro Hack Week (or in the evaluations) “well, that was too easy”. Most lecturers (me included) overestimate what participants already know and underestimate their tolerance for repetition. Additionally, Astro Hack Week is very fast-paced and the amount of information that is conveyed in five days huge. It is easy to overestimate the amount of information anyone can pick up in this short amount of time. Also, participants, especially experienced ones, come with the full knowledge that some of it, they’ll already know.
I think that next time, I’d point this out to all lecturers at the very beginning: having experts in the room is a feature, not a bug. I certainly understand why it can be intimidating. Don’t be afraid of them, but use them to your advantage. If you don’t know the answer to a question a participant asks, pass it on to them. Use them during the exercises to relieve pressure on yourself and to facilitate collaboration (this will come in handy during the hacking, too!).
I’d like to stress this collaborative aspect more at future Astro Hack Weeks, though it might be that getting experts in the audience to identify themselves might not always be straightforward (they may be reluctant to do so for various reasons). Are there ways to facilitate this kind of collaboration more easily? Do you have experience with this kind of workshop? I’d love to hear your opinions!