[IPython-dev] Introduction to Contributing workshop (Python Sheffield)

[Thomas Kluyver]

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.

In the end we had 11 people besides me. The session was 1h45 minutes long,
and I'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'd work on,
then circulated to help different groups.

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'd mentioned as part of the bug
fixing process.

Technology:
* 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's
Linux laptop.
* 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't sure what the relevant
packages were called. They worked it out themselves after a while.
* Running the development version of IPython in a virtualenv proved
surprisingly difficult. I'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).
* I had the repository and the bug reports on a memory stick in case the
Wifi failed, but happily it wasn't needed.

Group work:
* Group sizes of 2-3 work well: you can discuss what you're doing, but it'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.
* I'm not sure what the ideal teacher:student ratio is. I was kept busy
steering people in the right direction, and I certainly wouldn'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.
* 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 "This is an *actual* bug" in
a tone of mild surprise. It also meant that people had to get the codebase
and run the development version.
* 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).

That's everything I can think of now - let me know if you have any
questions about it.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120229/eea23330/attachment.html>