Some thoughts on the workshop I ran in Sheffield last night, introducing people to contributing to IPython. Hopefully this will be useful to anyone doing a similar event in the future.<br><br>In the end we had 11 people besides me. The session was 1h45 minutes long, and I&#39;d asked them to make sure Python and git were installed beforehand, and to make a github account. They worked in 5 groups of 2-3, each group tackling one quickfix bug. I showed a few slides to introduce what we were doing, then got them to read the bugs and pick which one they&#39;d work on, then circulated to help different groups.<br>

<br>Overall, I was very pleased with how it went. All 5 groups succeeded in submitting pull requests (one was finished off when the author got home). All the groups managed to get to grips with their issue, and most of them added automated tests as well, which I&#39;d mentioned as part of the bug fixing process.<br>

<br>Technology:<br>* Everyone seemed to be OK with github, and there were only a couple of difficulties with git itself. One person had a Windows laptop, so rather than attempting to set it up with git, that pair worked on the other guy&#39;s Linux laptop.<br>

* The pair working with the Qt console had some difficulty getting the dependencies installed. One had an older version of Ubuntu without the necessary ZMQ, the other had Fedora, where I wasn&#39;t sure what the relevant packages were called. They worked it out themselves after a while.<br>

* Running the development version of IPython in a virtualenv proved surprisingly difficult. I&#39;d assumed that many people would be familiar with virtualenv, but it caused some confusion. Clearer instructions would have helped with this (create virtualenv, activate, install IPython, move out of source directory, run).<br>

* I had the repository and the bug reports on a memory stick in case the Wifi failed, but happily it wasn&#39;t needed.<br><br>Group work:<br>* Group sizes of 2-3 work well: you can discuss what you&#39;re doing, but it&#39;s small enough that everyone is involved. We did a coding event with groups of 4 previously, and it felt like some people were just watching.<br>

* I&#39;m not sure what the ideal teacher:student ratio is. I was kept busy steering people in the right direction, and I certainly wouldn&#39;t want to mentor many more groups by myself. But with a second mentor, maybe groups would have got help too quickly, and learned less than they did by trial and error. So approx. 1:10 was a reasonable number.<br>

* I think quickfix bugs were a good thing to do: small enough for newcomers to tackle in a couple of hours, but a concrete achievement - one person, on reproducing the bug they were working on, said &quot;This is an *actual* bug&quot; in a tone of mild surprise. It also meant that people had to get the codebase and run the development version.<br>

* People seemed quite at ease with the idea of adding tests for their bug - perhaps because many of them are professional coders (a number write Java or .NET at work, and do Python as a hobby).<br><br>That&#39;s everything I can think of now - let me know if you have any questions about it.<br>

<br>Thomas<br>