{{ draft() }}
Note: The MDN community often held doc sprints during 2010-2013. Starting in 2014, these events were broadened in scope to "Hack on MDN" events that include code hacking as well as documentation projects. Most of the advice below applies equally well to "Hack" sprints and documentation sprints.
これは、Doc sprint（集中的な文書関連イベントを実施する短い期間）を組織化するためのガイドです。Doc sprint を組織化した経験者からのアドバイス、コツを含み、あなたが同じことがをする助けとなるものです。このガイドはまた、FLOSS Manuals Book Sprints という書籍からのアイディアを引用しています。
Doc sprint とは、短い期間に、集まってドキュメントを作成することを指します。実際に、もしくは仮想的に集まって、決められたトピックや、それに関連した文書を協力して作成します。
Sprints can be virtual or in-person, or some combination. For a virtual sprint, everyone participates from wherever they happen to be located, communicating solely through mediated channels. For an in-person sprint, participants gather in the same location for the duration of the sprint, so that they can communicate face-to-face. Hybrid sprints can be mostly-in-person with some remote participants, or mostly-virtual with some local gatherings. In-person sprints require more logistical planning, to secure a meeting location, to get everybody there, and to house and feed them during the sprint.
Another way to categorize sprints is by topical focus. For example, a sprint might focus on a particular subject area, such as Web development, or translation into a particular language.
コミュニティとコンテンツに関して明確な目標を設定しましょう。次のようなことについて決めておくことによって、doc sprint の詳細を決めやすくなります。
決定した目標に応じて、スプリントの形式を決めましょう（仮想的に集まるのか、実際に集まるのか、それともその組み合わせなのか）。想定する参加者も、併せて決めておきましょう。
例えば、コミュニティメンバーを増やすことが目的なら、その地域の人が、実際に集まって行う形が最適でしょう。なぜなら長距離の移動も必要ありませんし、参加者がお互いに会って親睦を深められるからです。また特定の領域のトピックに焦点をあてたスプリントで、想定される参加者がお互いをよく知っているけれども、地理的に分散している場合は、仮想的に集まる形式をとると良いでしょう。
長距離の移動が必要な参加者のいるスプリントの場合、開催期間を 3 日間（例：週末 2 日と平日 1 日）はとったほうが良いでしょう。ただし長すぎないように注意が必要です。公開の、ローカルな、実際に集まるsプリントの場合は、多くの人が参加できると思われる日に、1 日だけ開催すると良いでしょう。仮想的に集まるなら、平日 1 日と休日 1日の 2 日開催とすることが多いです。例えばパリの Mozilla オフィスでは、毎水曜日に、ローカルなドックスプリントが開催されています。実際にオフィスに来る参加者が大半ですが、モントリオールからリモートで参加する人もいます。
参加者が全員参加するカンファレンスがあるなら、その後に開催するのも良いでしょう。その場合は、参加者がカンファレンス後にスプリントへ参加する時間を取れることを確認しておきましょう。またカンファレンスの期間中にスプリントを開催するのは避けたほうがよいでしょう。
仮想的に集まる形式をとるなら十分な作業時間を取れるように、タイムゾーンに気をつけましょう。ヨーロッパとアメリカやアメリカとアジアのように、異なるタイムゾーンからの参加者がいる場合は、参加者が起きていられる時間に計画しましょう。ただし全員にとって都合のよい時間はありえないことにも留意が必要です。
また、仮想的に集まる形式の場合には、2-3 週前に日程を設定できます。実際に集まる場合は、予定や移動の調整が必要なので、2-3 週よりも前に日程を決めておく必要があります。
スプリントを公開し、参加者を広く募ることもできます。その際には、必ず参加できることがわかっている参加者が何人かいるようにしましょう。彼らが全員参加できるように日時を設定しましょう。非公開のスプリントの場合は、参加者を招待するだけでよいでしょう。ただし招待状は個別に送信し、なぜ参加者として選ばれたのかを詳細に説明するものである必要があります。
公開のスプリントの場合は、トピックに興味のある既存グループを見つけておくと良いでしょう。例えば、特定の地域を対象とした集合型スプリントの場合、その地域で活動している Web 開発者のミートアップを見つけておくと良いでしょう。告知は送るグループにとって適切な手段でおこないましょう。告知文には、スプリントの詳細と参加登録方法が記載された Web ページへのリンクもつけておくと良いでしょう。Eventbrite と Lanyrd は参加登録も行えるサイトの例です。Mozilla の開発者向けイベントに、実際に参加するのは登録者の半数程度となっています。
ターゲットとする人々に適切にリーチできるなら、SNS も利用しましょう。Web 開発者をターゲットとするなら、まず Twitter、次いで Google Plus が、Facebook や LinkedIn と比べて効果がありました。しかし地域によって SNS の利用は異なります（例えばブラジルでは Orkut の利用者が多い）。ターゲット層に多くのフォロワーを持つ人に、イベント告知のポストをシェアしてもらえるようにしておきましょう。
Logistics for in-person sprints are greater for longer sprints and those where sprinters travel to attend. A short or locals-only sprint need relatively little logistical support.
You need to figure out how much the event is going to cost, and where the money is going to come from.
Costs to consider in your budget include:
Some of these costs can be self-funded by participants, meaning that they pay for their own costs. There are a variety of ways to save money, which are mentioned in the following sections.
It may be possible to get sponsorship from Mozilla to fund some of the costs of your event. It helps to have a clear focus for your event, and a specific plan and budget. If there is a Mozilla Rep in your area, work with them to request budget and swag through the Reps program. Otherwise, you can submit a developer events request in Bugzilla.
Have a way to track what tasks need to be worked on, who is doing what, and what has been completed. For MDN doc sprints, we use a wiki page for advance planning, and an etherpad for tracking work during the sprint.
Often, people want to help but don't know where to start, and deciding among many options takes too much mental effort. For any given participant, give them a couple of possible tasks ("you could do A, or B"); this simplifies their choice, without making them feel like they're being bossed around.
One of the benefits of in-person sprints is that people can work together in ways that they might not be able to when they're not in the same place, for example, by working out ideas together on a whiteboard or by brainstorming with sticky notes. Still, there are opportunities for collaboration and camaraderie in any type of sprint. Chatting via IRC is essential for virtual sprints, and still very helpful for in-person sprints (for example, for sharing links). For a greater sense of "virtual presence", consider using a video conferencing service, such as Google Hangout.
As an organizer, look for common interests among the participants and for ways that they can work together.
Be sure to take time to celebrate accomplishments at the end of the sprint. This gives participants a better feeling than when the sprint just ends without any summary. If possible, have people "demo" what they have done, even if it is just showing a new article page.
Also, share the sprint accomplishments via a blog post, to celebrate publicly as well. This is important for any kind of sprint, but especially for virtual sprints, where the participants might not all be online at the official end of the sprint for a wrap-up session.