Five more things on effective contribution days

Some time ago I wrote a post on our first EdWeb code sprint. Obviously things have moved on since 2016 – for one thing we have run quite a few contributions events since that pilot! Last December we hosted a Drupal 8 contribution day, as code sprints are now known, inviting some developers from the University of Dundee to take part. Over the years between my original post and our latest contribution day we have learned a lot about making the most out of this type of event. Now seems an excellent time to reflect on my original recommendations for staging a successful code sprint for any application or service and add a few extra things to the list.

Going back to 2016, I focused on five headings and suggested five important factors under each heading:

All of the original recommendations still hold true today; whether we’ve focused on EdWeb at our contribution events, or on Drupal more generally, we’ve pretty much stuck to the same basic structure for preparation, people involved, activities on the day, and follow-up work. Now, with a few more events under our belts, I would add another item to each of those headings.

Keeping in mind the original principles that act as the foundation, let’s take each of these new points in turn.

Set your goals

For a contribution event to be really effective, in addition to ensuring your participants have everything they need to prepare for the event you should make sure you understand what you want to get out of it. 

  • On the day, are you looking for targeted work in a specific area? 
  • R&D might be your aim – is there investigative work that you’d like to crowdsource from event attendees?
  • Are you looking to improve engagement with the development community around your application or service rather than fix specific issues or develop new features?

Like most days as a software developer, some contribution days will be about getting a lot of work done as efficiently as possible; others will perhaps be more about asking and answering questions than writing lines of code. Let your aims for a particular event shape the format of the event and the tasks you include.

Take stock of your roadmap

Having a clear understanding of the wider roadmap for your application or service before you run a contribution event may seem like an obvious point to make. Even open source projects which evolve organically go through periods of extensive requirements gathering to support a new direction, or times when the future path is not so clear. For a contribution day to be effective, uncertainty in general direction is not helpful. It’s more productive at such times to run workshops with stakeholders where you can explore those areas of uncertainty than to put on contribution events for developers. Software contribution events might then help you get things done!

Have an administrator for the practicalities

It is extremely useful to have someone who is responsible for picking up everything that does not directly contribute to the tasks being worked on by participants.  For example, setting up the room on the day, adding people to chat channels, making sure lunch is organised, ensuring participants have all the practical information they need to get them to the event location, etc.  If you have a small number of attendees, this role can be shared among the other roles, but if you have any more than a dozen or so participants, ideally you should aim to have a dedicated person to deal with these practicalities so they don’t interfere with progress on the day.

Add a crib sheet to your docs

On the day of your event, have a screen or whiteboard, or a pinned message in your chat channel, with a short list of key links and prompts that are essential to participants at your event.  Your crib sheet can be very short, but if you prep it in advance and share it on the day, it can save a lot of time on questions like ‘where do I find that setup page?’ or ‘where is the task list again?’. 

We didn’t have a crib sheet for our first EdWeb contribution event, but we used the feedback from that event to put one together, and have updated it after each new event. This really helps people to get started on the day, and we always receive very positive feedback from attendees on how useful it is.

Make contribution support a part of your workflow

The most beneficial and rewarding follow-up activity you can engage in after a successful contribution event is to find ways to make collaboration and contribution to your software something that happens naturally as part of the work you do. 

In open source communities, contribution events are an adjunct to the daily activity of building and maintaining all of the open source things.  You might start out with a developer contributing as a beginner at a dedicated event, but three weeks later wouldn’t it be great if that same developer is able to send you some code for a fix or new feature without having to wait for the next contribution event?  How fantastic if a year down the line that developer is taking part in one of your contribution events as a facilitator or setup assistant, helping others to contribute.

There are 2 critical factors here.  The first is that you use the contribution events to evolve your processes and standards so that regular contribution outside contribution days becomes more straightforward.  This will happen naturally if you’re doing the follow-up work after each contribution event to refine those processes.  That happened with EdWeb; our contribution events have run more smoothly each time, and our development processes are more efficient as a direct result of improvements that came out of contribution events.

The second factor is more challenging, and it’s a challenge that is common to open source projects: resources.  You can have the most efficient, effective processes, the most talented, experienced people available to review, deploy and test contributions, and the most enthusiastic potential contributors; if those people are not funded effectively to do the work of supporting contribution and collaborative development, then contribution and collaboration will not happen.  It’s not enough for the people to be capable and willing; organisational support and commitment to collaborative development is essential.

Conclusion

Contribution events are in themselves excellent opportunities for attendees to participate in the development of the systems they use, and for you to benefit from a community of developers with a broad range of skills and experience who are primarily outside of your core development team. Beyond the individual events, there’s great scope to further harness that experience to improve both your software and your development processes!

I will leave the last word to a couple of attendees from the Web Services development team at the University of Dundee who came to our Drupal 8 contribution day in December 2018.

We’ve got a wide range of experience in our team, one thing we all have in common is that we are new to Drupal. The contribution day at Edinburgh was an excellent introduction to open source Drupal and the great sense of community that surrounds it. We all started off the day without so much as an account on Drupal.org and by the end had signed up, worked on issues, and even contributed our own patches. We got a lot out of the day and are looking forward to the next one.

– Jonny Mayo, University of Dundee

It was a really lovely and empowering atmosphere they cultivated. I expected to feel out of my depth but they made it so everyone felt involved and able to give back.

– Erica Hall, University of Dundee