[IPython-dev] Introduction to Contributing workshop (Python Sheffield)
Wed Feb 29 13:06:02 CST 2012
On Wed, Feb 29, 2012 at 4:32 AM, Thomas Kluyver <email@example.com> wrote:
> 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.
First of all, many thanks!!! It's wonderful both that you did this and
even more that you wrote this detialed report. Hopefully some of them
will get hooked on ipython and will remain active, but even if they
move on to other things, there is still value in their participation
in the process.
> 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.
Care to make the materials you used to introduce things available?
I'm thinking if we can make this a 'sprint in a box', we'll be more
likely to repeat these events...
> 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).
> * 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.
Yes, we should provide copy-paste lines for the major distros with the
right package names, to save people some time.
> * 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).
Yup, again a copy/paste mini-howto would solve this.
> * 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.
This matches my experience from multiple occasions, 4 should be
avoided for actual coding. For a longer-term project it may be OK,
but coding-focused work does seem to break beyond 3 people.
> * 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.
Interesting and useful. Your point about forcing enough trial and
error on their own is a very good one.
> * 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.
Yes, we need to do more/better triage for this kind of tasks. Many
thanks for your leadership on this front already!
> * 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).
Glad to hear that, it should indeed become second nature.
Again, many thanks for this excellent work; I'm thrilled at the amount
of work you've put into improving our development process and
More information about the IPython-dev