Monday August 5 2019, C3.4 & C3.5, 08:00 AEST
Tuesday August 6 2019, C3.4 & C3.5, 08:00 AEST

Development Sprints, also known as just ‘sprints’, are an unstructured session where attendees can work on projects with peers, hack on things, or see what others are working on.

PyCon AU will provide the space, power, and internet, you provide the projects.

There will be a “Development Sprints” wall at registration where you can list your project throughout the conference. We’ll also hold a brief project/idea pitch at the beginning of the sprints where everyone will have the opportunity to announce what projects they’re working on.

Sprints are not fully catered, however just across the way from the Convention Centre is Harbourside, a shopping complex that has mulitple foodcourts and restaurants. There is also a Coles and several convenience stores within walking distance for snacks.

If you’ve registered for the sprints but you’re still not sure if you should attend, Naomi Ceder has written a post about why you should sprint at PyCon, and the same holds true for PyCon AU’s sprints.

Tips to prepare for the sprints

For attendees bringing projects

Development sprints are often a chance for attendees to make their first open source contribution. If you’re bringing a project with you, here are a few tips to help prepare for the sprints in advance and make the most of the 2 days of community coding!

  • Prepare a list of first-timer features or issues. If this is in GitHub we recommend having an issues list that is appropriately tagged.
  • Have an elevator pitch ready that explains what your project does, what contributions you’re looking for and what things you can teach contributors.
  • Bring an open mind and welcome all sorts of contributions. Our conference has attendees from all walks of life and they can contribute many things to your projects including things that aren’t lines of code. Be open to suggestions of documentation, diagrams, editing or usability feedback!
  • Make sure you’re clear about everything a potential contributor will need before they contribute. Will they need a specific version of Python? Do they need specific compiler tools? Do they need to have a Windows/macOS/Linux machine? If possible, document these requirements. Better still, document your entire onboarding process for a first-time contributor. If you don’t have the time to do this before the sprints… maybe this could be your first sprint activity?
  • If your codebase has a prerequisite that requires a large download, work out if you can pre-download that prerequisite. It doesn’t matter how good the WiFi is - if everyone downloads a multi-gigabyte Docker image at once, it’s going to get messy.
  • Think about what you want as the outcome of your sprint. Do you want to gain new regular contributors? Do you have specific bugs that you want to squash? Are you looking to improve visibility of your project? Do you need “hands on” user feedback for a feature or API change? These goals aren’t necessarily mutually exclusive - but having a clear idea of what you want to achieve will help you direct the activities of your sprinters.
  • Remember that for many people, this will be their first sprint, or their first time contributing to Open Source. In a surprising number of cases, it will even be the first time they’re using tools like Git and GitHub. There will be a lot they don’t know about the conventions of your project, and the conventions of contributing to open source. They’ve shown an interest in learning; the most important thing you can do is show patience, and a willingness to teach. If someone has a good experience sprinting, they’re more likely to turn up at a sprint at their next conference - or to continue contributing in their spare time - which means the entire community benefits.

To help find contributors and raise interest for your project, write up your project details and place it on the “Development Sprints” wall at registration so that attendees can peruse throughout the conference.

Finding a project to work on

If you’re coming to the sprints but you’re not sure what to work on, thats absolutely OK! Here are a few tips to help you get started:

  • Visit the registration desk and check out the listed projects on the “Development Sprints” wall.
  • Keep an eye out on twitter #pyconau and the attendee slack for people sharing their projects. Perhaps speak to them in the hallway over the weekend before attending the sprints
  • Be prepared with an elevator pitch for the types of projects that interest you, the skills you want to learn, or the skills that you’d like to share!
  • Joining a sprint isn’t a lifetime commitment. It’s an offer to help, and an opportunity to learn. If you don’t feel like you’re helping, or you don’t think you’re learning (or aren’t enjoying what you’re learning), don’t be afraid to say no, or try joining another project.
  • Don’t forget to bring your “can do” attitude! You’re going to be exploring a new codebase, experiencing problems you haven’t seen before, and learning new things. You’re going to experience setbacks. Perseverence is a key part of the sprinting experience; but if you do persevere, you’ll leave the sprint with new knowledge and new skills.