1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
---
title: Doc sprints
slug: MDN/Community/Doc_sprints
tags:
- NeedsUpdate
translation_of: MDN/Community/Doc_sprints
---
<div>{{MDNSidebar}}</div>
<p>{{ draft() }}</p>
<div class="note">
<p><strong>Note: </strong>MDN社区在2010 - 2013年期间经常举办文档迭代。 从2014年开始，这些事件的范围扩大到“<a href="https://blog.mozilla.org/community/2015/04/17/a-highly-productive-hack-on-mdn-weekend-in-berlin/">Hack on MDN</a>”事件，其中包括代码窃取以及文档项目。 下面的大部分建议同样适用于 "Hack" sprints和documentation sprints。</p>
</div>
<p><span class="seoSummary">这是组织</span>documentation sprint<span class="seoSummary">的指南。 它包含来自组织</span>doc sprints<span class="seoSummary">的人的建议和提示，以帮助您更好的组织文档。 本指南还借鉴了<a href="http://write.flossmanuals.net/book-sprints/introduction/">FLOSS手册书籍</a>的书籍。</span></p>
<h2 id="什么是_doc_sprint">什么是 doc sprint?</h2>
<p>doc sprint 是一段时间，一群人像你一样可爱的人，合作撰写关于给定主题或相关主题的文档。</p>
<h2 id="sprints_的分类">sprints 的分类</h2>
<p>sprints可以是线上的，也可以是线下的，也可以线上线下一起进行。对于线上sprints而言，每个人都可以在不同的地区参与，只需要通过中间渠道进行沟通。对于线下sprints，参加者在sprints期间聚集在同一地区，以便他们可以面对面进行交流。线下sprints需要更多的后勤规划，确保会议地点，可以容纳所有参与者，并且在sprints期间需要提供食物与安置参与者。</p>
<p>另一种分类sprints的方式是通过专题聚焦。例如sprint可能关注特定的主题，比如：Web开发，或翻译特定语言。</p>
<h2 id="计划一次_sprint">计划一次 sprint</h2>
<h3 id="设定目标">设定目标</h3>
<p>明确这次 sprint的目标, 包括内容和社区效应。 这能够帮助你更好地计划低层次的细节。</p>
<ul>
<li>你想要记录一个特定的主题区域吗?</li>
<li>你想要创建一种特定类型的文档或者资源吗? 比如说，教程，代码示例，或者特定语言的翻译。</li>
<li>你想要吸引更多人加入到MDN，做出贡献吗？</li>
<li>你想要增进社区成员的凝聚力吗?</li>
</ul>
<h3 id="决定类型和范围">决定类型和范围</h3>
<p>基于你的目标, 确定 sprint的类型 (线上的，也可以是线下的，或者是线上线下一起进行) 和范围 (这是参与者会关注的)。</p>
<p>比如说，你想要吸引新的社区成员，你可以选择本地的线下sprint, 因为不需要长途旅行, 而且参加者还可以见面. 如果您想要专注于特定的主题领域，其中内容贡献者是地理上分离的，而且早就彼此认识，那么一个线上sprint就很合适。</p>
<h3 id="选择日期和时间">选择日期和时间</h3>
<p>对于需要长途交通的线下sprint， 我们已经发现了三天 (比如说两天周末和一天工作日) 就足够做到很多重要的工作。也不会占用大家日常生活的很多时间。对于公开，本地，线下的sprint，大部分人只能够付出一天的时间. 对于线上的sprint, 我们通常进行两天: 一个工作日外加周末的一天。 As an alternative example, in the past there has been mini-sprint for writing and translating docs, every Wednesday evening in the Mozilla Paris office; it was primarily in-person for locals, but also got remote participation from Montreal (where it was at lunch time).</p>
<p>Attaching a sprint to the end of a conference that everyone attended worked well; trying to run a sprint <em>during</em> a conference that everyone attended did not work so well. Make sure that participants know about the sprint when they make their conference plans, so that they allow extra days for the sprint.</p>
<p>Consider the time zones that virtual participants are in; be sure that you allow enough working time in each time zone, and have some overlap when multiple zones (such as Europe and Americas, or Americas and Asia) are awake. However, it's just reality that no one time is good for everyone everywhere.</p>
<p>For virtual sprints, the dates can be set as little as 2-3 weeks in advance. For in-person sprints, you need to decide further in advance, in order to allow time for people to decide and make travel arrangements.</p>
<h3 id="Promote_the_sprint">Promote the sprint</h3>
<p>You can make the sprint open, and invite the world, but you should have a few key people that you know for sure will participate. Work with them when selecting dates, to ensure that they are available during the chosen dates. If the sprint is not open, then you need only extend invitations; make sure that each invitation is personal, explaining why that person has been specificallly invited.</p>
<p>For public sprints, identify existing groups that have an interest in the topic, for example: local Web developer meetup groups for a local in-person sprint. Send an announcement through whatever channel is appropriate for that group. Be sure to provide a link to a web page with more details, and include a call-to-action for people to sign up for the sprint. <a href="https://www.eventbrite.com/" title="https://www.eventbrite.com/">Eventbrite </a>and <a href="http://lanyrd.com" title="http://lanyrd.com">Lanyrd</a> are two services that support sign-ups. For Mozilla developer events, we have found that about half the people who sign up actually show up.</p>
<p>Use the social media channels that are appropriate to reach your target attendees. We have found that for Web developers, this means Twitter, followed by Google Plus, more than Facebook or LinkedIn. However, popular channels can vary geographically (such as Orkut in Brazil). Reach out to a few well-connected people who have a large following among your target audience, and ask them to re-share your posts.</p>
<h3 id="Logistics_for_in-person_sprints">Logistics for in-person sprints</h3>
<p>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.</p>
<h4 id="Budget_and_funding">Budget and funding</h4>
<p>You need to figure out how much the event is going to cost, and where the money is going to come from.</p>
<p>Costs to consider in your budget include:</p>
<ul>
<li>Travel</li>
<li>Lodging</li>
<li>Food</li>
<li>Meeting space</li>
</ul>
<p>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.</p>
<p>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 <a href="https://reps.mozilla.org/people/#/">Mozilla Rep</a> in your area, work with them to request budget and swag through the Reps program. Otherwise, you can submit a <a href="https://bugzilla.mozilla.org/form.dev-engagement-event">developer events request</a> in Bugzilla.</p>
<dl>
<dt>Venue</dt>
<dd>There are lots of options for meeting space. If you are in a city with a Mozilla office, you can use the community space in that office. Elsewhere, options include meeting rooms in libraries, churches, coffee shops, or businesses where you have contacts. Many cities now have coworking spaces that rent their conference rooms for a reasonable fee.</dd>
<dt>Resources</dt>
<dd>Be sure that your venue has good chairs and tables, and reliable power and Internet access. Sitting all day on a bad chair is not just uncomfortable; it can lead to injury. Make sure that the number of sprinters and their computers and devices does not overwhelm the power supply and available Internet bandwidth. Be generous (but not dangerous) with extension cords, and if necessary, international plug adapters. A projector for shared viewing can be very helpful. Whiteboards and sticky notes are great for brainstorming and planning.</dd>
<dt>Travel</dt>
<dd>Travel is relevant only if the sprinters do not all live close to the sprint venue. The usual strategies for saving on travel apply, and are not specific to doc sprints.</dd>
<dt>Accommodations</dt>
<dd>Where sprinters stay should not be inconveniently far from the meeting venue. It can be cheaper (and possibly more fun) to split the cost of a vacation house or flat, rather than paying for individual hotel rooms. If you have a mix of visitors and (willing) locals, the visitors can stay in the homes of local community members.</dd>
<dt>Food</dt>
<dd>Sprinters need to eat! Make arrangements for food during the sprint, and inform sprinters if certain meals will not be arranged. If the group is staying in a home, you can save money by buying and cooking food rather than going out to eat. Even if food is self-funded, it can reduce hassle to pitch into a common fund for food, rather than splitting every restaurant bill. If your venue allows, have snacks (some healthy and some not) available between meals.</dd>
<dt>Fun</dt>
<dd>Make time for non-writing social activities. These can be informal, like going for a hike together, or more formal, like a tourist excursion. Going out for beer (at the end of the day, of course) is usually a winner. On the other hand, don't plan every hour of every day. Everybody needs some down time, especially introverts.</dd>
</dl>
<h2 id="During_the_sprint">During the sprint</h2>
<h3 id="Planning_the_work">Planning the work</h3>
<p> </p>
<h3 id="Tracking_tasks">Tracking tasks</h3>
<p>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.</p>
<p>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.</p>
<h3 id="Collaborating">Collaborating</h3>
<p>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.</p>
<p>As an organizer, look for common interests among the participants and for ways that they can work together.</p>
<h3 id="Celebrating_accomplishments">Celebrating accomplishments</h3>
<p>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.</p>
<p>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.</p>
|
