I’ve been thinking out how we can come up with new methods to make our sprinting time more productive. In the first two segments, I went over what our current thinking about how a sprint should run and what is expected of organizers and sprinters alike. We see that sprinting is somehow broken, because people lack motivation to sprint,
except the folks that rise to the level of elders.
All is lost with sprinting however. I think that there are a few things that
we can do to make sprinting more productive. The challenge is that you can’t just make rules and expect sprinters to respond. You can
’t say, “don’t show up without knowing what you are doing,” or we will lose valuable input from the community, since only elders will show up at that point. So, the new rules are for organizers, and the elders, not the would-be sprinters.
Organizers need to start offering free tutorials for folks interested in the projects. This accomplishes two things. First, you give training to the people that are interested in your project without alienating them. It would be easy to say “New Rule! You must have done the 20-minute-wiki tutorial to participate in the sprint.” But this tactic does nothing to help the feeling that people have when they call something elitist. While you might think it’s not elitist to have accomplished the 20-minute-wiki, someone else might struggle for hours with that task, especially if the documentation is not up to snuff. These contributors still offer valuable insight, and you want them contributing to your project.
The second reason free tutorials will help your project is that it gives you an opportunity to increase the popularity of your project. The more people that are interested in your way of doing things, the more potential sprinters you have. At the end of the tutorial, you can collect emails or instant message handles, even phone numbers if that is what it takes to grow a list of perspective sprinters. If you are willing to be generous with your time, maybe 1 out of 10 tutorial goers will be willing to return the favor. The tutorial would also allow you to open up a method for communication. Consider setting up an IRC (Internet Relay Chat) channel for your sprint, or using your project’s IRC channel to disseminate information about the sprint. This will show folks on IRC that you are not only doing a a tutorial (maybe you will get some online participation) but it will show tutorial goers that the channel exists for further assistance.
The free tutorial is a great way to provide a service that costs nothing more than time for the organizer. However, I don’t think this is the limit of what we can provide sprinters for their time. What we need to do is provide some sort of incentive other than the good of human kind to sprinters. The first thing is probably the easiest. Start holding sprints on a friday, or any weekday for that matter. This seems counterintuitive, right? The fact is, most people don’t want to take a weekend day off because they are busy with other weekend stuff. We all have families, clubs, interests outside of OSS software that we need to tend to. Also, this provides a monetary benefit to the project without actually costing the project anything. Many companies which use OSS software, and claim to support it will also be willing to let their employee take a day, or a 1/2 day to participate in a sprint. The way you sell this idea is
to have the sprinters describe the hands-on and in-depth training they will be receiving in the care of the sprint. This is no lie, the amount you can learn in an average sprinting day far exceeds the amount you receive on a regular basis.
Hold sprints in a unique location. Lots of people like to ski. For this reason zope/plone’s snow sprint is very popular. I think the reason this sprint is made possible is that people need to take a break from the every day, and getting to a new an exciting place has merit, both from a coding perspective, and a mental aptitude one. It so happens that I live in Colorado, which is one of the premier places in the US to ski. If anyone is interested in organizing a sprint nearby, I urge them to speak up. Also, I would be willing to provide a free tutorial on a weekday, so that hourly employees may be able to justify the cost of a trip to Colorado as an offset to the cost of free training.
It seems to me that the scope of a sprint is essential to it’s success. If the sprint is just to code something, it is much less likely to succeed than if you are to sprint on something in particular. Having everyone making a concerted effort on one topic makes it easier for organizers to coordinate folks, because organization can focus on one thing, and therefore tasks can be created ahead of time instead of doing so when everyone shows up.
Lastly, I think we need to reach out to the community of users, and find out if users of your project can support the OSS efforts of the tools they use. I think that the next logical step is to provide sponsorship for sprints themselves. Perhaps the sprint sponsor can provide a place to stay, or airfare to bring some of the sprinters together. Even providing a venue for the sprint, or beer and pizza is something, but it is hard to expect people to show up and spend their time and also their own money to be co-located with a bunch of other sprinters.
This is part two of a four part series on sprinting: The next [controversial] post is called Sprint Organization: But can we do more ? This will talk about how we might convince third parties to participate in the concept of sprinting by asking them to donate monetarily.
I’d add that tutorials and presenting (past and present work, useful tools, even vaporware) has been a big part of the plone and snowsprint culture (note, snowsprint is not a plone sprint anymore…).
Location is important, not just for glamor, but also for the ability to provide a certain amount of convenience isolation from the outside world. It should be easy for sprinter to stumble home drunk, happy, and code-burned in the whee hours of the morning. They should be able to commune and hack around the clock. There should be some possibilities for alternate activities, but not a distracting flood of them. Sometimes even lack of internet access is a boon.
How you define success is important too. I’m not sure if scope makes any difference if you have fuzzy goals or unrealistic expectations of what it takes to accomplish them.
Sometimes everyone hanging out in person is more valuable than the code created. Or clearing boilerplate bits like documentation, packaging and build so more people can easily participate. The attainable goals are set by who shows up… if a project has poor documentation and a shitty build and mostly beginners show, that’s what everyone is going to work on regardless of proclaimed goals.
Open source is best led by the needs of individuals and is most successful when it adapts to those needs. I think having clear topics that a sprint will tackle goes a long way to appealing to those needs and rallying troops around a cause, but a tight scope will almost always limit the participants. Sometimes that’s a good thing, but depends on what you are defining as success.
Heya
I’ve been reading your blog via rss and noticed it has been hacked, and it has been filled with spam content (only when viewed via rss).
I’ve tried emailing you about this, unsuccessfully, so I’m leaving the comment here instead, to let you know.
All the best,
lorg
I _think_ I have this resolved, but I won’t know until I publish my next Post. It turned out my older version of this site was hacked, and we found lots of evidence of this, and cleaned up where we could. At least the database was not corrupted.
cheers.
-chris
It seems it was not resolved
Nope, reinstalling WP now.
This is very disappointing. ugh… PHP.
Hi mate, I really like your site. With the abundance of misinformation about this subject on the internet, it’s great to see some refreshing content. Keep up the good work!