Tutorials¶
Here there are some important points for organizing the tutorials for the SciPy conference. They are based on the experience of previous conferences so please, for the sake of keeping future organizers happier, you are encouraged update this document in the parts that are necessary.
Decision points¶
Tracks¶
2013 had 3 different tracks (introductory, intermediate and advanced) with 4 slots of 4 hours each per track.
Feedback was positive for this arrangement both years, and we fairly easily filled 60-80 slots per tutorial.
More details are in mailings/tutorials_announcement.rst
2014 had 4 different tracks (introductory, intermediate, advanced, topics) with 4 slots of 4 hours each per track.
2015 had 5 different tracks: 1 full 2 day track for Software Carpentry and 4 tracks (Basics, Statistics and Machine Learning, Performance and Optimization, and Special Topics), which each specified a knowledge level for the individual tutorial as beginner, intermediate, or advanced, with 4 slots of 4 hours each per track. Machine Learning (2 connected tutorials) was so popular we actually had a 6th tutorial track on day 2 to repeat the tutorial from day 1.
Seating¶
Before 2013, we had open seating (i.e. anybody can go to any tutorial). In 2013 and 2014, we required people to sign up to attend the tutorial they were interested in, and in both years several tutorials were full.
In 2013, we had people at the door of full tutorials checking names as folks entered. This was effective, but a bit annoying.
In 2014, most of the tutorials were either full or close to full. Even “full” tutorials had capacity for an extra ~10 people. We did not check names at the door, and there were no complaints about lack of seating.
In 2015, most tutorials were either full or close to full, even with more tracks. Rooms ranged in size from about 60 to about 95 max and some space was left for volunteers and people to step in.
Introductory Track¶
There are two approaches to the introductory track: a single, coherent curriculum, or a mishmash of multiple intro-level tutorials. In 2013-2014, we found we needed to solicit intro tutorials from the community.
In 2013, the committee chose specific people from the community and asked them to submit intro tutorials. There were more submissions than spaces available, and this led to a nice selection of intro topics.
In 2014, we make a general solicitation when the proposal due-date was extended, and this led to a good selection of intro-level submissions.
In the early days of SciPy, there was a single tutorial track which served as a broad intro to scientific computing in Python. In years since we’ve moved away from that, but there was some discussion around whether it would be good to return to a multiday, coherent tutorial for beginners.
One idea for this would be to outsource to Software Carpentry, but it’s not clear that Greg Wilson would support doing this. Another option is to specifically solicit intro proposals from a group of 3-4 people who are willing to work together and do a 2-day intro track from the ground up. With this, the intro track would look a lot more like the original scipy conference tutorials.
In any case, we need to make sure that the intro sections are taught by someone who has experience in getting people started from the ground-up: i.e. you can’t just say “pull this from github” or “run Python from the command-line”: the students may not know what “github” and the “command line” are!
In 2015 we did have a Software Carpentry track for 2 days to try to reach out to people who are truly new. This worked pretty well: there were reports of fewer newbies in the lower level tutorials and the SC tutorial went well, but it wasn’t very well attended. We think this is still a good idea, but needs to be advertised better and to be possibly broken into 4 hour chunks like the other tutorials instead of keeping people in the track the whole time.
Tracks and call for proposals¶
It is a pre-condition to have the tracks nailed down before the call for submissions announcement. In 2013, 3 different tracks (introductory, intermediate and advanced) were scheduled, and we decided to have 4 slots of 4 hours each per track. In 2014, we had four different tracks (introductory, intermediate, advanced, topical). More details can be seen in mailings/tutorials_announcement.rst
In 2014 and especially 2015, we really chose the tracks based on the submissions we got.
Require that people will have their materials ready a month ahead of time and recommend that they use iPython notebooks to teach with so that the students have the materials to use later and to be able to better follow along.
Introductory Track¶
This is one of the most important in terms of bringing new people into the SciPy community. In 2013, we had to pull the attention of instructors for most of the tutorial submissions in this category. We will need to encourage submissions and/or invite people to teach these topics. We may want to specify four 1/2 topics and invite proposals for those specific topics.
Suggested 1/2 day topics in order:
Introduction Scientific Python Basics (Numpy and IPython)
Introduction to plotting with Matplotlib
Software carpentry: git/GitHub, unit testing
Introduction to data analysis with pandas
Introduction to Julia (this was presented in 2014, and received quite well)
Intermediate Track¶
Prerequisite should be basic understanding of SciPy stack, i.e. numpy, scipy, matplotlib etc.
Advanced¶
Under the hood or advanced concepts.
Preselection¶
After the last deadline, the tutorial co-chairs should carefully study the proposals and, depending on the requirements and ‘hot topics’ for the conference, select the candidates that are best suited. For the selection it is important that you do some research about the quality of the tutors as teachers, as this is a critical parameter for increasing the quality of the tutorial tracks.
Get reviewers besides the two tutorials co-chairs to help review. Let everyone know that the reviews will be shared with the submitters. Comments are particularly important in addition to the score values.
Take notes about the submissions, because these are going to be important, specially for providing feedback in non-acceptance mails. In 2013 we almost had a 3:1 submission ratio, so better be ready for justifying the rejections. This year we did not provided this, and some submitters got very disappointed.
For doing the preselection, it is important to get in touch with the general conference co-chairs, as they have a broader vision of the conference, and also past conferences, so they can provide a very nice insight on many different aspects of the selection.
Once the preselection is complete, send a mail to the selected tutors and ask for confirmation. Be patient and wait until everybody confirmed. In 2013 we had a case that took several days to confirm. In this case it helps sending a last call and requiring him to confirm in less than 24 hours (this probably helps people waiting for company management approval). He confirmed on-time.
- Important: Once the list of tutorials is confirmed and prior to
making it public, please please please, send a non-acceptance message for non-selected submitters. In 2013 some folks got angry because they found their submissions were not accepted by reading the list of accepted tutorials in the official website. This should not happen again (in 2014 we were careful to do this, and included specific points on what, if anything, could have made the submission stronger).
After the messages for rejection are sent, the list can be made public. Do the proper announcements for this.
It is important that chairs would not hurry up too much in this stage, because the selection is one of the most critical parts of the process. Take your time for this, and our experience is that 2-3 weeks for tackling the complete selections process would be fine.
Pre-tutorials tasks¶
Two months before the conference, send a welcome message to tutors with a reminder to define the software requirements as well as scripts and exercises ready by two weeks before the tutorials start. The reason of having the exercises already defined is to allow tutors help each other during the actual tutorials. You can find an example of the welcome message in mailings/tutorials_welcome_tutors.txt.
Also, one month before the conference send, and in a separate message, send the results of the tutorial surveys for the previous year. They should contain important information for them to prepare their material (and for themselves as instructors).
In 2013 we encouraged tutors to help each other during the tutorials. This turn out to work great, specially on the introductory ones, where people tends to have more problems because they are not familiar with the environment. You can find the message sent 1 month before the tutorials in mailings/tutorials_help_other_tutors.txt.
In 2014, we made this even more explicit and asked in the acceptance email if tutors would confirm their willingness to assist in another tutorial.
In 2015 we tried this again to varying degrees of success. The tutorials with the best help had their own helpers.
2 weeks before the tutorials, create a mailing list for all tutors (in 2013 it was tutors2013@scipy.org) as well as different mailing list for each tutorial. The general tutorial mailing list will be useful not only as a communication channel between organizers and tutors but also between them too (for helping each other, for example). The specific mailing lists per each tutorial will serve for tutors to communicate with their pupils, and for organizers to send the results of the surveys (see below).
Email lists should work so that as people sign up for tutorials, they are added to the class email list.
We can make the github repo with a README file part of the application requirements next year, and then we can just automatically check the repos daily for things like check_env.py and some ipython notebooks. Maybe we could even break the stipend up to give peple $200 if they have materials up 10 days prior, and then the rest when they do the tutorial.
During the 2 week before, send a couple of messages to the tutors reminding that they must send their instructions to attendees for following there tutorials. It is critical to ensure that tutors do not send that information the night before, for example (and despite all our efforts this actually happened in 2013).
Just in case, maybe programming a pre-tutorial install session will be a nice safeguard for people not doing a good job reading messages from tutors. But the goal is that nobody would actually need to attend to this session (we achieved this in 2013).
Give suggestions for style in the tutorial: use notebooks to share information and materials with students so they can follow along at their own pace. Encourage instructors not to flip around between too many screens, which can be very distracting and hard to follow. Make sure they plan in breaks which correspond to the times snacks are available.
Post-tutorial tasks¶
Immediately after the tutorials are finished, a survey must be sent to the attendees for assessing the performance of the different tutors. You can find the survey for 2013 here:
https://www.surveygizmo.com/s3/1291753/SciPy-2013-Testing-Individual-Tutorial-Experience-Feedback
I don’t know if that will survive for next years, so at the end of the document there is a text version of it.
IMPORTANT: There can be tutors attending as pupils to other tutorials, so it is not enough to send the survey to attendees, but you should send it also to all tutors too.
When the results would be ready, send them in a sensible format (e.g. text or PDF; never, ever, send a MS Word or other proprietary format) to the tutors list. The results might be useful for next year tutors, so please store them in a sensible and private place. The reason for keeping the results private is that this is somewhat sensible info and some tutors may not be happy to see the survey results publicly available in a general way.
After sending the results of the survey, take your time to comment the results with tutors on the mailing list and finally send another message congratulating all of them for all the effort done.
And last but not least, take your time to update this manual so that other tutorial chairs would find clear instructions for the next awesome SciPy conference.
Enjoy organizing the tutorials for the next conference!
Text version for the tutorials surveys¶
Mainly have a rating (1-Strongly Disagree, 5-Strongly Agree) with a few fields for comments.
Individual Tutorial Experience Feedback (This feedback will be shared with the presenters):
Please select the tutorials you attended/wish to comment on:
(For each tutorial checked, repeat the next five questions)
1) The requirements for this tutorial were adequately communicated/distributed (i.e software packages required, installation, slides, data files, etc)
[1-5]
2) I did not have any problems running the exercises that were part of this tutorial
[1-5]
3) What do you think of the balance between talk and exercises? When answering, please keep in mind that the overall time is limited.
[Too much Talk/Just Right/To many Exercises]
4) Did the level of the tutorial match its advertised level (intro/intermediate/advanced)?
[Too Basic/Just Right/Too Advanced]
How could this tutorial be improved?
[General Comment Field]
Overall Tutorial Experience:
1) I learned more from attending the SciPy Conference tutorials than you would have learned from reading books and online tutorials alone?
[Yes/No]
Would you recommend these tutorials to other friends and colleagues?
[Yes/No]
3) What are ways we can improve the overall organization of SciPy Tutorials? [General Comment Field]
[General Comment Field]
