In April, Boston Python ran its first ever CPython development sprint for new contributors.

Here was the pitch:

Want to contribute to Python? Join us for a 1-day development sprint on the CPython language implementation and standard library. This event is focused specifically on new contributors to the language! Several committers and experienced contributors will be with us to help with the mechanics of the contribution process as we triage tickets and make progress on bugs.
Our goal is for everyone to have submitted at least one patch by the end of the event!

20 new CPython developers got together and made progress on almost 40 tickets that afternoon:

(I assure you that these are the concentrated looks of people having fun on the inside as they work on tickets and chat on IRC :) )

This was a successful event: almost everyone made serious progress on at least one ticket, a bunch of tickets were resolved, and most people said they intend to keep contributing. I look forward to running more CPython sprints with Boston Python, and I'd love to see more user groups pursuing this event style to bring new folks into the contributor community.

Running a CPython development sprint for new contributors

One day (really, one afternoon) is not much time, so here's what we did to try and maximize the efficiency of those hours.

1. Audience

This was an event targeted at folks who were new CPython contributors but had prior open source contribution experience. The event assumed that everyone was comfortable with concepts like version control, patches, and issue trackers, freeing us to instead focus on the mechanics of contributing specifically to CPython.

We try to create many opportunities within Boston Python to learn the general tools of open source development. To folks interested in participating in this CPython sprint who didn't have the prerequisites, we gave the specific recommendation of working through the OpenHatch open source training missions at a Boston Python project night and then joining us at a future sprint.

2. Pre-event setup

Here are the pre-event setup instructions we sent out earlier in the week. They cover environment setup, communication, and the patch submission process:

A. Please get set up to use IRC (here's a quick-start guide) and visit #bostonpython and #python-dev on Freenode.
B. Please visit http://docs.python.org/devguide/#quick-start and complete steps 1 - 3 of the Quick Start guide, namely:
Get the source code
Build Python
Run the tests
Note that you may first need to install some dependencies, for example the mercurial revision control system or a C compiler.
The test suite should run to completion without errors. If you need help with any of these steps, please ask for help on IRC in #bostonpython.
C. Please create an account on the Python issue tracker at http://bugs.python.org/.
D. Please read through the following sections of the developer guide at http://docs.python.org/devguide/#full-table-of-contents:
1. Getting Started
2. Where to Get Help
3. Lifecycle of a Patch
4. Running & Writing Tests
10. Issue Tracking
17. Development Cycle

Completing these steps prior to the sprint ensured that we didn't get hung up on slow checkouts or build failures and could start making progress on tickets from the get-go.

3. Bitesized bugs

You could spend an entire afternoon just finding a ticket to work on. To avoid that, prior to the event helpers curated a list of tickets appropriate for first-time contributors, with a bit of annotation on the type and difficulty of the work to be done. Here's a small section of that list:

...
http://bugs.python.org/issue7152 - urllib build_opener skips ProxyHandler - requires analysis and experimentation to see if it is a real bug or a doc bug
http://bugs.python.org/issue10438 - example for calling static methods - simple doc clarification issue with suggested wording 
http://bugs.python.org/issue3423 - DeprecationWarning applies to wrong context with exec() -  a somewhat deeper C issue
http://bugs.python.org/issue5993 - webbrowser produces zombie processes - has been reproduced with python3 and firefox (but not chrome)
http://bugs.python.org/issue3158 - doctest doesn't find doctests in extension modules - fix needs refinement and a test added (via the Module/xxmodule, I think)
http://bugs.python.org/issue9033 - cmd module tab misbehavior - real solution requires a compatibility layer between readline and libedit, so this is a more involved project
http://bugs.python.org/issue2628 - ftplib Persistent data connection - patch needs updating, especially the tests
...

We strove for a diverse mix of tickets from which hopefully everyone could find something relevant to their interests, background, and computing environment: bugfixes, documentation, Windows, pure Python, C, tests, etc.

The most important feature of a good newcomer ticket is that it has a clearly-defined next step for someone to work on.

4. Experienced helpers

When you have a bunch of first-timers sprinting together, it's helpful to have experienced contributors in the room to answer procedural questions, make technical judgement calls, and take triage actions that require elevated issue tracker privileges. It's also very motivating to have the tight feedback loop of submitting a patch, going through a round of review or two within a few minutes, and getting your patch merged right at the event by the committer sitting next to you!

We were fortunate to have CPython committers R. David Murray and Jack Diederich with us, as well as contributors Sijin Joseph, Kent Johnson, Ned Batchelder, and Ned Jackson Lovely. Thank you to these helpers who generously donated their time and patience!

5. Follow-up

Not every ticket can get reviewed at the event. After a flurry of triage and patch submissions, it's important to follow up on those tickets and make sure they get timely attention and resolution in the issue tracker.

We kept a list of the tickets sprinters worked on and which tickets still needed attention after the event, checking in on them with our volunteer committers periodically over the last 3 weeks. I can happily report that almost all of the tickets worked on at the sprint have had responses and in many cases patches merged and resolution.