Drupal code sprint formats

I've been asked to facilitate a code sprint at Drupal Camp Delhi in a couple weeks.  I've never led a code sprint before, but I have participated in several.  I'm thrilled to do it, but then there are a lot of logistical questions that are rasied.  What format it should take? Who and how many should attend?  Will there be beer?  These are serious questions that I don't have clear answers to.  I thought about it and decided to describe the different formats I've witnessed.

General "grab an issue" sprint.

People show up and work on what they are interested in already.  They collaborate and ask each other questions, but generally just keep it informal and working groups form organically.
  • Preparation: Low
  • Easy to get involved: Yes, but tough for complete newbies unless there is prep.
  • Tangible results: Low
  • Group size: Any

Organized "grab an issue" sprint

A facilitator picks a bunch of issues ahead of time, organizes them (perhaps by experience level or skill type) and then doles them out to people who want to work on them.  People can work in pairs, or individually, but the end result is some amount of traction on a particular topic (piece of core, module, documentation, etc).  Angie Byron added to this a variation: "we've done a cool thing before in Montreal where we divided a room up into stations: the translation table, the testing table, the design table, etc. They start with an overview of what there is to work on, then a specific set of issues. Then, in periodic (hour-long, half-day, whatever) time chunks, rotate 'stations' so you get to learn how to contribute to multiple facets of Drupal."
  • Preparation: Medium
  • Easy to get involved: Yes because it is focused but the person shouldn't have to be an expert.
  • Tangible results: Medium
  • Group size: max 20 or so

Dedicated project w/ goals sprint

In this model, usually a group will take a module, pick a few objectives, plan out issues ahead of time and coordinate with a group who can hit the ground running.  Then the group will split up into pairs, work on issues and pass them off to the rest of the group for review and committal.  This format is usually punctuated with architectural discoveries and discussions which is great because many knowledgable people are in the room.
  • Preparation: High
  • Easy to get involved: No, people need to come with expertise.
  • Tangible results: High
  • Group size: small, maybe 8 people max for effective decision making

Do you have other formats which worked well?  Why and in what scenarios?

 

Tags: 

Comments

success

I think the basic question is how do you define success. What do you want to get out of the sprint for the people involved and what for the Drupal project in general. I think low maintenance sprints only work well for both the people and the project if people are already involved. For new people, high maintenance is always involved, they need more hand-holding. What I've seen in both Drupalcon sprints and specific sprints is that people who are not already involved and don't get hand-holding quickly drop out as they find no good way to engage. So depending on how many new people you have, you need more and more mentors in the room so you can size a successful sprint based on the mentors you have available.

I totally agree... That's

I totally agree... That's what I'm conflicted about.  The main success criteria for this camp is getting people involved, not producing code.  We are likely to have a bad ratio of newbs:mentors so this becomes difficult.  What format works best in this case?

mentor-optimized then

I think you should optimize for mentors then. That is pick a topic that you know pretty well and is hopefully of general interest, so you can get people engaged. Not having to mentor people with random issues help you not loose time on figuring out the random issue yourself and for the people to get related info from how you help others solve similar issues, etc. Then you can have people work together on figuring out issues, so they share knowledge from the start, and you have smaller 2-3-4 person groups to help. Later in the day once/if they are comfortable breaking out to smaller / individual work, they can do that then. IMHO.

Viselike this tamed of method

Viselike this tamed of method is echt commonwealth apt for, salutary fit for readers and a creator for you as get definitely shew the decorativeness of the communicator. It's subscription to bonk these kinds of articles around to taciturnity the run cerebrate nonviolence. Conveying those who o.k. can playacting things overripe in the venerable add!

free e cards

 

Issue-grabbing

In my experience the "General 'grab an issue' sprint" causes a lot of confusion, especially for newer contributors. One of the biggest challenges for novice contributors is knowing what to work on.

I suggest a variant of the "Organized 'grab an issue' sprint." Create a working document that lists the issues you've targeted for the sprint, like you describe. Use a publicly writable spreadsheet on Google Docs or suchlike. If there are just a few people, then the mentor can assign tasks to participants based on their skills and interests. (That works best in my experience, because it also nurtures the volunteers and builds an easy bridge for them to ask questions.) However, if there are too many people for one mentor to coordinate, then participants can use the spreadsheet to coordinate, filling in their name next to the issue they're working on and adding any notes about it to the spreadsheet.

And, not just "code" sprints!

I recommend not limiting it to "code" sprints. It's definitely easier to get people involved and motivated at a camp, but a majority of the people who attend a camp are intimidated by core and contrib development, and many will not be programmers. Make sure to have options for these people as well!

Shameless plug: Consider a sprint to work on core issues. In particular, if your participants are fluent in English, you could try an issue summary sprint. :) Resources:
http://groups.drupal.org/node/167534
http://xjm.drupalgardens.com/blog/core-and-you

Issues Summary - Excellent Idea

I think issue summary sprint is an excellent idea for people who dream of working in core issues some day. I stumbled upon my first issue summary sometime back and it just brought a smile on my face, though reading long threads for replies was enriching in some cases I always felt that due to terminology deficit on my part I didn't get all comments and issue summary was right there explaining you the issue in lucid ways. Issues tagged novice is a great repo for low hanging yet important contributions and will give sprinters a good degree of satisfaction.

I hope to start doing it for WSCCI issues and will be proposing this for drupal camp mumbai sprint.

My experiences from code sprint at drupal camp pune

I have been part of just one community driven code sprint and that was at drupal camp pune 2009, we had high goals, enthusiasm and were looking fwd to it. Addison Berry and some really good developers from all of over India culminated at Dcamp Pune including gurpratap, sumitk, fine folks from srijan etc. At the end of it all, I just felt physically tired and some degree of personal satisfaction. Looking back:

1> Goals were abstract - translation sprint, documentation sprint, porting modules to 7 (I took a shot at pathauto) there was little leadership on specifics.

2> No feedback loop - We worked in silos, formed some teams but didn't review progress or ideas.

3> Lack of mentorship, though we planned it and talked about it we weren't able to setup proper channel. At the end it was vague do WTF you want and not in a productive way.

Some Observations (these are mine alone):

1> Contribution = code prevailed as common mindset, though people understood virtues of other forms of contribution in theory.

2> Fail Silently - If someone was stuck, they were not open to talk about it.

3> People wanna contribute - Almost everyone I met wanted to contribute and make a name for themselves and were positive about the whole concept.

Hoping to see a write up on what u plan to do for Delhi sprint, doesn't hurt to ask but can you also lead mumbai's sprint?

Well corganisng code sprints

Well corganisng code sprints in Delhi is something that has always been discussed a lot in local F/OSS communities. And the conclusion of most of such discussions have always been that we don't have many people who want to contribute. They would come, participate and try to learn new things. It is very rare that we get regular motivated contributors out of code sprints. And the effort always goes waste. That does not mean that we should not have a code sprint. What I am trying to point out is that probably out of 10 out of 300 people will be really interested in contributing, IMHO.

Being a volunteer for DrupalCamp Delhi, I would like to tell you about discussions on the kind of crowd we are expecting. As of now, we believe that a lot of students are going to be there for the event. Most of them will be new to Drupal and will be there to now what Drupal really is, rather how they can use Drupal. Getting newbies involved is a difficult task as it will become more of a Drupal tutorial rather than a code sprint.

We do have a lot of companies using Drupal in someway or the other. Srijan, OSSCube will be in a better position to comment on how they and other professionals look at contributing to Drupal, how they have been involved in contributing, and how much they will be willing to contribute during the event.

Personally, IMHO I believe that most of the attendees wouldn't want to contribute. They will be there to learn Drupal and to learn how they can use Drupal for personal benefits, business which is good. However, most of them won't take that extra step to contribute as they don't understand the concept and they don't feel the need to contribute. But, that's a personal opinion.

I really believe that it will be worthwhile to have a short session on contributng to Drupal (how the community works, how and why is it important to contribute, benefits of contribution from business/personal point of view, why should students contribute and how can they benefit, in what ways can one contribute). If there is a plan, then te plan should be discussed during the session. The code sprint should begin after that.

I am still not sure what could be the best way to contribute. I have conducted a code sprint myself with students (though it was on contributing to Firefox). All the students were new and had never contributed to even a single open source project. It became success! We spoke about how and in what ways to contribute to Firefox, did a tutorial, discussed ideas to work on in the code sprint and helped out every participant when they needed help. I believe that will work well with students. Also, that ways other ways of contributing (other than code) can be highlighted. It will be a great way to actually show how to contribute docs, issues, etc.

Hey,

Hey,

So what about if we change expectations:

The goal is not to produce code, patches, etc.  The goal is simply to get people involved and to improve their skills.  Our success is measured in how many people meet on IRC later, start visiting forums, or meet up for coffee.

This could sounds like a training.  But a training is formal, it assumes a certain level of general knowledge and requires preperation.  It takes time.

Maybe we should just get people to self-identify as experts in a given area, and then lead mini BoFs where people group around them and look at stuff.  Groups of... 4?  4 seems like a human level.  How they spend the time is up to them, but I kinda like this approach.

 

My recent first time experience

I just attended my fourth big Drupal event (Badcamp) and I had a great first time experience contributing in a documentation sprint. I'm a themer and designer and I haven't contrinbuted any code to drupal.org and so the chance to contribute to some documention was rewarding. This documention sprint was very easy casual small and we produced some good results.

The format was

Preparation: Low
Easy to get involved: Yes, all levels help
Tangible results: High
Group size: probably any

We produced results and I was also introduced to some great people and now I have a new  linode server....

+1 to  Jacob Singh's comment

 

I'm leaving that last piece

I'm leaving that last piece of spam on because it is so weird.

The Delhi code sprint was pretty good I think - about 20 people showed up.  Due to schedule issues I could only participate for about a 1/2hr.  Here's what I did:

I optimized for learning and community above productivity, which meant the goal was for people to work together and get to know eachother.

I made a list of possible topics which I knew people would want to learn about / work These included:

  • Git workflow / patching (Vaidik led this and kicked ass w/ about 1/2 the group)
  • Novice issue queue
  • Hindi translation.

Then, people volunteered via http://piratepad.net/DCD11 to lead other groups like:

I don't know how much actual code got completed, but I heard from people that the git workshop was good, the highrise port got done (don't see it though) and that the Hindi translation group did good work.

Attendees, would love your feedback.

 

Awesome

Perhaps this is a bit off topic but in any case I have been surfing about your blog and it looks really neat. impassioned about your writing. I am creating a new blog and hard-pressed to make it appear great and supply excellent articles. I have discovered a lot on your site and I look forward to additional updates and will be back.  Ankauf Briefmarken

reply to post

Well Jacob, I personaly like the first one that you mentioned. The general grab an issue sprint. There everyone can express what is in their minds in a cool and inforaml way. I think it is the most effective way to make a point. All the best for all your works.For more click here

xzgshb bob's pharmacy

walgreens pharmacy in bridgeport ct formulation of ventolin pharmacy kickapoo indian medicine man
soma pharmacy reference fda albuterol risks holistic vetinary medicine alternative vetinary medicine
cvs pharmacy escondido ca albuterol for fat loss forums hear bipolar alternative medicine
compare price for flea medicine can you use expired albuterol sulfate there ingham internal medicine associates mi
xu chongming auricle medicine albuterol sulfate expired effects nebulizer pet pharmacy maine
old read's drugstore bottle albuterol expired medicine inhaler anxiety medicine treating com
pharmacy job morris minnesota expired dangers albuterol sulfate white wolf medicine native american
chondromalacia patella physician and sports medicine epocrates albuterol intire monograph cvs pharmacy cooley lake
faculte de medicine nice epinephrine albuterol bronchiolitis placebo university of iowa medicine
bolton pharmacy hartford ct link donna pharmacy los angeles
historically black college of pharmacy chinese medicine providor
glass medicine bottle
rite aid pharmacy stamford ct
pharmacy port hawksbury nova scotia
ohio department of family medicine
isamea medicine woman
medicine baclafen
va hospital pharmacy
fortune 500 companies pharmacy services
lynchburg family medicine residency
medicine osteopathic
pharmacy gpi
american institute for preventative medicine
best pharmacy prices
articles dealing with medicine
industrial medicine jamestown ny
heads of agency and medicine
pulmonary and sleep medicine associates mi
pharmacy fraud whistle blowers