Top Tips for Open Source Contribution Sprints

Open Source community leaders’ tips on running successful contribution sprints – In 2018, many people seem to understand the value FOSS delivers–technical, business, and otherwise. Improved ROI, shared risk and benefit, and not competing in IT when you’re not in the IT business all make sense. We FOSS service providers spend less time nowadays explaining how “open” and “secure” can go hand in hand, for example, and a lot more time convincing potential clients and adopters about the merits of our particular solutions. But when it comes to open source culture, there are a few areas that I find myself regularly explaining to “outsiders.” One of those is the Contribution Sprint.

“My top tip? Sprint Again ASAP.” – Rakesh James

What’s a sprint?

Contribution Sprints–aka Hackathons, Sprints, Coding Nights, and similar–are at the heart of the Free and Open Source Software (FOSS) world. These events are where a lot of contribution happens (in code and otherwise), held as stand-alone events or as a parallel track within larger community events. Most importantly, this is where communities and strong working relationships between contributors are built who might be on opposite sides of the world most of the year. A great sprint can have a huge impact on contributors’ lives and careers, and on open source software projects as they continuously strive for improvement and community growth.

Picture five, 25, or 250 people working in a space together to solve hard problems. Their contributions will benefit anyone who uses their particular flavor of open source project. They might be hunched over laptops, coding hard; they might be slinging sticky-notes and animatedly discussing marketing messaging and promotion; or they might be building training curricula, software demos, or a thousand other possible ways to contribute to FOSS, its projects, and communities.

“New community members especially may only know one company and how things are done there. Sprints are not only about getting your hands on code. They’re about getting to know people, networking, broadening one’s horizons. More than once, I’ve seen long-pending features or bug fixes taken care of because the right people bumped into each other at a sprint. And where else could you get that much best practice knowledge all in one place?” – Martin Wiederkehr

Run a brilliant sprint

We’ve prepared and published a Open Source Contribution Sprint Guide on GitHub (aka “How to run a brilliant sprint!”). If you’d like to know more about the nuts and bolts of setting up one of these events, check it out! And our guide is itself is open source, contributions welcome! They’ll go towards making everyone’s sprints better in the future.

“There is no better way than a contribution sprint to educate, entertain and gel a team of developers of different skill levels and states of mind. They will all go home exhausted, excited, very motivated, and a whole lot smarter then they came in.” – Anja Leichsenring

Thank You, Top Tip Contributors!

Preparing this article and the Brilliant Sprint Guide, I spoke with a number of open source colleagues who have planned and run contribution sprints, mentored new contributors, and have helped FOSS flourish and thrive over the years. I asked them all about what goes into sprinting and their top tips for running a great contribution sprint. Let’s meet our contributors and their open source communities (several of them have also contributed to DDEV-Local!).

My thanks to all of you for your help and your contributions!

  • Heather McNamee – Open Strategy Partners – Drupal, TYPO3 CMS
  • Martin Wiederkehr – Business Manager, Team Leader, Product Owner, snowflake productions gmbh – TYPO3 CMS
  • Ruben Teijeiro – 1xINTERNET – Drupal
  • Rakesh James – Drupal Developer, CTI Digital – Drupal
  • Brian Gilbert – Director, RealityLoop – Drupal, Firefox Extensions, Safari Extensions, GitLab, Hammerspoon, Sequelpro, Sublime Text Addons, Alfred app Addons
  • Christiaan Jansen – Competence Lead Drupal, Ordina Digital Services – Drupal
  • Gregg Marshall – Drupal Architect – Drupal
  • Anja Leichsenring – Developer, TYPO3 GmbH – TYPO3 CMS
  • Adam Bergstein – VP Engineering, Hook 42 – Drupal, Pattern Lab, Ansible
  • Vijaya Chandran Mani – Solution Architect at TCS/Pfizer – Drupal

Top Sprint Tips

Fuel

  • Always provide a good environment with essentials like healthy food, water, and coffee. Chris Jansen especially recommends, “Never just have pizza and beer; offer healthy alternatives (pro-tip, falafel and halloumi burgers are great!).” It’s important that people feel comfortable and that you care about them. – Ruben, Chris, Brian, Anja, Vijaya
  • Make sure there are lots of power outlets, pizza, coffee, and water. – Adam
  • And Martin’s special tip: “Make sure you’ve got plenty of drinks (especially those unhealthy energy drinks) and food organised. A saturated contributor is a happy contributor.” 🙂

The TYPO3 CMS community has something of a “maximalist” approach to things running smoothly at sprints. Frequent core code sprint lead, Anja Leichsenring, explains:

“Always make sure that everything is taken care of. Nothing should concern the participants other than the code they’ll be working on. That includes providing accommodation, clear travel descriptions, food and beverages available around the clock, infrastructure plug-in ready, and a clear event scope defining what the goals are and what is out of that scope.”

 

Everyone has something to contribute

  • Be insistent that contribution sprints are for EVERYONE and make EVERYONE welcome, coder or not, independent of their background, skills, and experience. EVERYONE can contribute. – Ruben, Gregg, Chris
  • Always communicate in advance that there are tasks for non-programmers (documentation, UX, manual testing, etc) – Brian
  • Be aware you are dealing with very heterogeneous groups at a sprint. Don’t assume too much, ask in advance if you’re not certain about anything. – Martin
  • Everyone can help each other. Sit at a table with others and collaborate. Good things can and usually do happen. – Adam
  • Never try to be perfect. Never be afraid to ask for help. Be open to learning something new. – Rakesh

Prepare, prepare, prepare

  • Always prepare (some call this “triage”) a batch of short and easy tasks that can be accomplished in a short period of time. These make it easy to have a first-time success and avoid frustration. Gregg points out, “Friends of mine who ‘got something done’ have gotten involved and come back. Those who haven’t don’t sprint a second time. – Gregg, Ruben, Brian
  • Provide a Google doc that provides instructions, examples, links to documentation, set up a Slack channel or similar, and provide examples of open issues (technical, and not) so people can easily pick items. – Adam
  • Make sure the sprint is well publicized before and during the main event it is embedded in. If people are traveling to be there, make it really clear that everyone is encouraged to attend the sprint day so they can make their travel plans accordingly. – Gregg
  • Always have a quick and easy-to-setup development environment (like DDEV-LOCAL :P) for the newcomer attendees. – Ruben
    • As much as possible streamline the setup process and have ample documentation to get people to a productive state. – Brian
    • (DDEV has got you covered here! Quickstart instructions for Drupal, TYPO3 CMS, Backdrop CMS, and WordPress!)
  • Delegate as much as possible. Have shared responsibilities (broken down into easy/simple to carry out tasks) for organizing, communicating, and marketing code sprints. Plan and organize for when you hand over the organization of events to the next people in the community. – Heather, Vijaya
  • In the end, it’s about a lot of work packed into a little time; do what you can to make sure everyone feels comfortable while they are there. – Martin

 

Welcome, help & mentoring

  • Always have easily identifiable, dedicated mentors on-hand. Brightly colored mentor-team t-shirts work well. – Chris, Adam, Gregg, Ruben
  • Never leave people unattended. Some people are shy and won’t ask questions even when they are completely lost. – Ruben
  • Have someone welcoming people when they arrive and help get them either joined up with a group doing something they are interested in or to a new sprinter workshop. – Gregg
  • Always welcome new people. Not just at code sprints, but also at the events in general. If you’re organising the event, it’s your party, bring new people into the fold and connect them to others with introductions. – Heather
  • Always look to mentor a new mentor at every sprint. – Vijaya
  • Set realistic expectations (not everyone will complete whatever they are working on in the sprint, post what you have done in issue at the end, even if you plan to continue later.) – Brian, Rakesh
  • Help sprinters “wear their own shoes”, that is work on something that’s right for them, whether that’s novice tasks or some area of expertise they may have. Everyone has something to contribute. – Rakesh

“When I started my code sprinting with Drupal, I was not aware of how to create a patch file using the diff command. I went to IRC ask for the help and Daniel Wehner, started helping me. He ended up writing the exact command to create my patch file … with exact file names and everything … in IRC! LOL. Mentors are amazing.” – Rakesh James.

Planning: time & non-sprint activities

  • There are 24 hours in a contribution sprint day:
    • Don’t try to limit working times. Sprints tend to stretch deep into the night or even early morning hours. Let them be! – Anja
    • Be prepared to hand over the keys to the venue or stay there at least until midnight. A real code sprint starts when the sun goes down. – Martin
  • If you didn’t figure it out already, Anja is pretty hardcore about sprinting … 😛
    • Don’t try to coax social interaction from the team. They are there for work, that’s all they want and need. – Anja
    • Despite what I just said, organise one evening of social activity to bring people together outside the sprint rooms … but do let the team know exactly what will go on when and where so they’ll also know when they can get back to work. – Anja
  • Try to organise an optional “supporting program”. It’s a pity if you’re in a foreign city somewhere and don’t at least have the chance to see something other than the sprint. – Martin

Motivate, support, say thank you!

  • Make sure to acknowledge and thank contribution (via karma, tweet, etc.) – Vijaya
  • Thank people for attending and ideally follow up a few weeks after the sprint (ideally with some indication of that person’s success) – Gregg
  • Make sure there is noise on social media. People are proud to be part of the action, both the team and the listeners out in the community, but there’s often no time or thought of it during the event itself. Fill that gap. It’s a small effort that will pay off well. – Anja

“There would hardly be any open source software without code sprints. All major projects have them and for good reason; code sprints allow people to get together and work together closely on the tough, hairy problems that inevitably surface in any software project. They are also a great time for individual contributors to form life-lasting friendships and bond over the shared love they feel for the open source project they spend so much time on.

“I remember walking into the mentored sprint room at Drupalcon Amsterdam and thinking: ‘Wow, look at all these people working together. They all seem to know each other, where do I fit in?’ Turns out, most of them had never met each other before that day and still they were all passionately working together on all kinds of issues. Thinking hard together, having heated arguments about what solution would be best, coding together, reviewing each other’s code, and sharing lots of laughter. Some people made friends for life that day. I know; I was one of them.” – Chris Jansen

DDEV is here to help FOSS communities

At DDEV, the team has deep open source roots. We are building our business on an open source toolset and giving back as much as we can, as often as we can to the projects and communities we’re involved with. We’re creating resources to help open source communities run better contribution sprints and be more productive in the dev-to-deploy workflow. Check out our other resources.

Join Newsletter

Photo credits

Please follow and like us: