A Helpful Guide to Your First Drupal Sprint
by Lilian Ma
Cross-posted with permission from Genuine Interactive
It’s almost time for your first Drupal Sprint, but you’re not sure what to expect and what you do to be prepared. Here at Genuine, we want all contributors to be prepared for the 2014 Global Drupal 8 Sprint Weekend so we’ve put together answers to some key questions.
What to expect from a Sprint?
First and foremost, you’ll witness the hard work and dedication that goes into Drupal. But what makes Drupal so successful? The three big Cs: Community, Collaboration, and Contribution.
Drupal was built by a community and this community continues to advance Drupal year after year through Sprints, camps, and meet ups. At the 2014 Global Drupal 8 Sprint Weekend, you’ll spend the day working with members of the Drupal community who share the same passion about Drupal. The day will also be filled with conversations around all aspects of Drupal, how others use it, and how they want to help improve it.
A successful Sprint is comprised of everyone tackling problems from the issue queue, which involves people working together. During the Sprint, people will work together, have one-off discussions, break out into groups, comment on issues or IRC chats (see below for more info). You can expect to collaborate and meet a number of people while everyone works on solving issues.
Whether you spend the sprint writing documentation, contributing patches or reviewing patches, by the end of the day you’ll have contributed something back to Drupal. Every issue that is worked on or solved during a Sprint will help make Drupal better.
What do you need set up before a Sprint?
Prior to the Sprint, it is important that you have the tools and resources you need setup to be able to participate. This includes setting up an account on drupal.org. Without a drupal.org account you will not able to work on issues in the issue queues.
Additionally, a lot of communication during a Sprint happens in the #drupal-contribute IRC channel. So you should come to the Sprint with an IRC client (Chatzill Firefox plugin, Pidgin, Adium, etc.). Drupal.org provides information on how to get setup with IRC for drupal.
If you plan on only contributing documentation or test submitted patches, all you need is an understanding of the documentation standards and a web browser. For testing patches you can use the simplytest.me service to spin up a Drupal website with the patches you are testing. To test patches, a rudimentary understanding of Drupal is helpful, so be sure to read up if you are not familiar.
If you are planning on developing and contributing patches to issues, it is important to have an environment setup prior to the sprint. The basic tools you will need are:
- A local webserver
- A code friendly text-editor
You should also have an understanding of:
How does the issue queue work?
Every project on drupal.org (modules, themes, Drupal itself) has an issue queue used to track bugs, tasks, improvements, and feature requests. Sprints revolve around the queues, with everyone working together to solve issues. So it is important to know the basics of how the issue queue works in a Sprint.
Each issue in the queue lists columns of information, including:
- Summary: a brief description of the issue
- Status: the current state of the issue (more info below)
- Priority: importance of the issue
- Category: type of issue
- Component: which part of the system is related to this issue
- Assigned to: who is assigned to this issue (more info below)
The status of the issue informs you what state the issue is in, and what action needs to be applied. Although there are a number of statuses for an issue, generally during a Sprint, issues will fall into the following statuses:
An active issue is one that users are currently still discussing and proposing solutions. Users can participate in an “active issue” by helping to describe the problem and potential solutions.
An issue that “needs work” is one that is ready to have someone work on the proposed solution, and/or continue or fix work that has already been completed but rejected.
After work has been completed, the issue status is changed from “needs work” to “needs review.” Issues in the “needs review” state are waiting on community member(s) to test the posted solution and verify that it works as expected and solves the issue. After reviewing, an issue can be set back to the “needs work” status, if the posted solution does not solve the issue or needs additional work, or the issue can be moved to the “reviewed and tested by community” status.
Reviewed and tested by the community
After multiple community members have tested and verified a patch for an issue, it can then be moved into the “Reviewed and tested by the community state.” This state tells the project maintainers that the solution for this issue is ready to be merged into the code base.
After a project maintainer has merged a solution for an issue into the code base, they will mark the issue as “fixed.”
An issue can be closed for many reasons (as can be seen by the many different closed states). The issue can be a duplicate, not really an issue, cannot be replicated, or it has been fixed and completed.
To work on an issue during a Sprint, it is important to pay attention to the summary, status, and assignment. Issues that can be worked on during a Sprint are ones that have the status of “Active,” “Needs work,” or “Needs Review.”
If you find an issue that interests you, the next step is to check who is assigned to it. If an issue is assigned to a user then that signifies they have claimed it and are currently working on it. If no one is assigned to an issue, you can assign it to yourself and inform the community by clicking the “update issue button.” After you have completed your work on the issue, be sure to un-assign it and update the status from “needs work” to “needs review” so that another community member can continue work on it.
For more in depth information on how to work with the Drupal issue queue, take a look at the documentation provided on the drupal.org website,
Everyone who participates in a Sprint is there because they want to help make Drupal better. It is important to remember to have fun and enjoy the work you are doing. Sprints should be lively and laid back, so that the many different people who participate feel comfortable collaborating with each other.
The Drupal community is composed of a wide range of people, all of whom are different. Everyone has their own way they like to work and participate. There is no wrong way to be helpful and constructive during a Sprint. We are all there to work together to make Drupal better, so respect those you are working with.
With so many different people participating in a Sprint, remember to be polite to other community members. This is true not only for people you interact with in person at the Sprint, but also in the issue queues and IRC channels. Being vulgar and hurtful with comments will not win you any fans in this community.
A Sprint is about helping each other work to improve Drupal. You do not need to be an expert to help someone who has a question, or needs help contributing. Collaborate and work together.
Still have questions or having trouble with setup?
During the 2014 Global Drupal 8 Sprint Weekend at Genuine, we will have community members from OwnSourcing available to help get you setup or troubleshoot any issues you are having. If you are having issues with the issue queue, or with Drupal in general, there are always plenty of people available to help in the Drupal IRC channels, specifically in #drupal and #drupal-contribute.
Hope these answers helped prepare you for the 2014 Global Drupal 8 Sprint Weekend on Saturday, Jan. 25 and for all future Sprints!
If you haven’t already, please RSVP by Monday, Jan. 20 to attend the 2014 Global Drupal 8 Sprint Weekend at Genuine Interactive. This will help Genuine and Acquia with event resourcing and provide you with building access.