Skip to content

Commit 1dc7090

Browse files
HsiehHsieh
authored andcommitted
差最後一句
1 parent 9f291e3 commit 1dc7090

File tree

1 file changed

+46
-46
lines changed

1 file changed

+46
-46
lines changed

_articles/zh-TW/building-community.md

Lines changed: 46 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,8 @@ description: 打造個人們願意使用、貢獻並願意主動宣傳的人氣
55
class: building
66
toc:
77
讓專案朝成功邁進: "讓專案朝成功邁進"
8-
growing-your-community: "讓社群成長茁壯"
9-
resolving-conflicts: "解決衝突"
8+
讓社群成長茁壯: "讓社群成長茁壯"
9+
化解衝突: "化解衝突"
1010
order: 4
1111
image: /assets/images/cards/building.png
1212
---
@@ -112,7 +112,7 @@ image: /assets/images/cards/building.png
112112

113113
社群擁有強大的能量。這種能量可能是正面的也可能是負面的,一切都取決於你如何駕馭它。隨著社群的成長,要想辦法讓之成為建設性的力量,而非具有破壞性的。
114114

115-
### 不要容忍來者不善的人
115+
### **不要容忍來者不善的人**
116116

117117
熱門的專案都不可避免地會吸引到想破壞社群的人。他們可能會從一些不必要的爭論開始,對一些細枝末節糾纏不清,或用語言傷害他人。
118118

@@ -133,7 +133,7 @@ image: /assets/images/cards/building.png
133133
當發現社群中有負面的行為時,要即時、公開的指出來。要用堅定的語氣解釋他們的行為為什麼是不可接受的。如果問題持續發生,你有必要[請他們離開](https://github.com/cnbo/open-source-guide/blob/gh-pages/_articles/code-of-conduct.md#enforcing-your-code-of-conduct)。你的[行為準則](https://github.com/cnbo/open-source-guide/blob/gh-pages/_articles/code-of-conduct.md)是為這些情境準備的建設性指南。
134134

135135

136-
### 知道貢獻者在哪裡
136+
### **知道貢獻者在哪裡**
137137

138138
隨著專案的成長,好的說明文件會變得愈加重要。不固定貢獻者或路人不可能一下子就對專案非常熟悉,一份好的文建,能讓他們很快地找到他們需要的資訊。
139139

@@ -175,114 +175,114 @@ image: /assets/images/cards/building.png
175175

176176
* **給每個貢獻者提交的權限。** @felixge 發現這樣會使大家[越來越樂意發表他們的補丁](http://felixge.de/2013/03/11/the-pull-request-hack.html),甚至找到人手來協助維護他已很久沒處裡的專案。
177177

178-
* 如果專案是放在 GitHub 上,那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**,加入至少一個備份管理員。組織能讓專案與來自外界的貢獻,彼此協作的工作變得更加容易。
178+
* 如果專案是放在 GitHub 上,那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**,加入至少一個備份管理員。組織能讓社群與來自外界的貢獻,彼此協作的工作變得更加容易。
179179

180180
事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233.pdf)去做大部分的工作。隨著社群變得越來越大,就會有更多的人參與進來。
181181

182182
雖然並不是一直都有人在回答問題,但是你可以去試著增加一些機會,讓他人有能夠參與的機會,越是儘早開始,越是能夠獲得幫助。
183183

184184
<aside markdown="1" class="pquote">
185185
<img src="https://avatars0.githubusercontent.com/u/39992?v=3&s=400" class="pquote-avatar" alt="avatar">
186-
你們最大的興趣是招募喜歡你們專案以及能夠做你們不能做的事的貢獻者。你喜歡編碼,但不喜歡回答issues?那麼讓社群中能做這件事的人去做
186+
對社群最有利的做法是招募喜歡你們專案的人,而且他還能夠做你們做不到的事情。你是否喜歡寫程式,但不喜歡回覆 issue ? 那麼就讓社群裡能做這件事的人去做
187187
<p markdown="1" class="pquote-credit">
188-
@gr2m, ["打造受歡迎的社群"](http://hood.ie/blog/welcoming-communities.html)
188+
@gr2m, ["打造溫暖的社群"](http://hood.ie/blog/welcoming-communities.html)
189189
</p>
190190
</aside>
191191

192-
## 解決衝突
192+
## **化解衝突**
193193

194-
在專案的早期,做決定是件蠻容易的事。幾乎是想做什麼就可以做什麼
194+
在專案的一開始,做決定是蠻容易的事。想做什麼,就放手去做吧
195195

196-
隨著專案的越加流行,會有更多的人對社群的決策開始感興趣。即使社群沒有大量的貢獻者,如果專案擁有很多用戶,就會發現大家的重點在決策上或者增加他們的issues
196+
隨著專案變得熱門,會有更多人對社群的決策感興趣。如果專案有很多使用者,你會發現大家都很關心決策,或者踴躍的提交他們的 issue ,即使社群沒有很多貢獻者
197197

198-
在大多數情況下,如果你們培養了一個友好,頗受尊重的社群並公開記錄你的過程,社群應該能夠找到解決方案。但也有時候會遇到難以解決麻煩
198+
大多數情況下,如果你們經營了一個友善、受尊重的社群並紀錄社群歷程公開給大家知道,社群應該能自己找到解決方案。但有時也會遇到難以處理的麻煩
199199

200-
### 建立友好的氛圍
200+
### **建立友好的氛圍**
201201

202-
當社群正在討論一個很難的issue時,氣氛會很激烈。人們可能會為此變得憤怒或者沮喪,甚至會遭到直接的人身攻擊
202+
當社群正熱烈討論一個困難的 issue 時,火氣可能會不小。人們可能會為此憤怒或者沮喪,甚至會做出直接的人身攻擊
203203

204-
作為一名維護者的工作是不要讓這種情況出現。即使這些你對話題有很強烈的觀點,也要儘量站在一個主持者或者推動者的位置,而不是參與爭吵以及推動自己的觀點。如果有人不友好或者壟斷話題,那麼[立即採取行動](https://ocselected.github.io/open-source-guide/building-community/)以保持有禮貌和豐富的討論
204+
身為一名維護者的工作就是別讓這種情況惡化。即使這些你對該話題有自己強烈的看法,也要盡量擔任一個仲裁者或推動者的角色,而非跳下去參與爭論以及推動自己的觀點。如果有人態度不好或者嘗試壟斷話題,那麼請[立即採取行動](https://ocselected.github.io/open-source-guide/building-community/)讓討論保持它應有的禮節,讓討論是有意義的
205205

206206
<aside markdown="1" class="pquote">
207207
<img src="https://avatars2.githubusercontent.com/u/119893?v=3&s=400" class="pquote-avatar" alt="avatar">
208-
作為一名維護者,尊重你們的貢獻者非常重要。他們經常處理一些你們描述親切的事情
208+
作為一名維護者,尊重你們的貢獻者是一件重要的事。他們經常會感情用事的去看待你的意見
209209

210210
<p markdown="1" class="pquote-credit">
211211
@kennethreitz, ["保持和善,要麼滾蛋"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)
212212
</p>
213213
</aside>
214214

215-
一些人希望得到指導。撰寫一個優勢的示例。當然仍然可以表達失望、不高興或者憂慮,但得心平氣和。
215+
一些人希望得到指導。試著當一個好典範。當然你仍然可以表達失望、不高興或者憂慮,但得心平氣和。
216216

217-
保持你們的酷並不容易,但是展示領導力能促進社群健康的發展。互聯網感謝你們
217+
保持不慍不火並不容易,但是展現領導力能促進社群健康的發展。網路世界感謝你們的付出
218218

219-
### 將你們的README視為最高法則
219+
### **視 README 為最高原則**
220220

221-
README [不僅僅是一組指令](../starting-a-project/#writing-a-readme)。它也是一個談論目標、產品願景和路線的地方
222-
如果人們過分專注於討論特定功能的優點,它可能有助於重新審視您的README,並談論專案的更高的願景。關注README也會使對話變得個人化,所以可以進行建設性的討論
221+
README [不僅僅是指導手冊](../starting-a-project/#writing-a-readme)。它也是一個談論目標、願景和路線的地方
222+
如果人們放太多精力在討論特定功能的優點,這時重新審視 README 並討論遠景也許會比較有幫助。關注 README 也能讓大家就事論事的去討論,讓對話變得有建設性的
223223

224-
### 專注過程,而不是結果
224+
### **專注過程,而不是結果**
225225

226-
一些專案用投票的方式做重要決定。雖然看上去是明智的,投票強調的是得到一個“答案”,而不是傾聽以及解決每個人的顧慮
226+
一些專案用投票的方式做重要決定。雖然乍看之下覺得這樣是合理的作法,但投票強調的是得到一個「答案」,而不是傾聽以及理解每個人的顧慮
227227

228-
投票會變成政治,社群成員在做感興趣的事或者表決一個明確的方法時會感到壓力。不是每個人都參與了投票,可能在你們的社群中[保持沉默的人佔了多數](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users)或者用戶不知道投票這件事正在發生
228+
投票會變成政治,不論是在往後互助的過程中,或是投票時,社群成員都會備感壓力。而且不是每個人會參與投票,可能你們的社群[保持沉默的人佔多數](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users)或甚至使用者根本不知道投票這件事正在發生
229229

230-
有時候,投票是必要的手段。盡你們所能強調["尋求共識"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)而不是共識本身
230+
有時投票是必要的手段。盡你們所能的強調["尋求共識"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)而不是要擁有共識本身
231231

232-
在尋求共識的過程中,社群成員討論主要問題,直到他們感到他們的意見已經得到充分的表達。當僅遺留下一些無關緊要的問題時,社群需要向前邁進。“尋求共識”不能確保社群能得到一個完美的答案。而是側重聆聽和討論。
232+
尋求共識的過程中,社群成員討論關心在乎的事,直到他們覺得意見已經獲得充分的表達。當僅剩下一些次要的議題時,社群就往前邁進。「尋求共識」不能確保社群能得到一個完美的解答。而是側重聆聽和討論。
233233

234234
<aside markdown="1" class="pquote">
235235
<img src="https://avatars3.githubusercontent.com/u/1038121?v=3&s=460" class="pquote-avatar" alt="avatar">
236-
Atom Issues不存在投票系統的部分原因是因為Atom團隊在所有情況下都不會遵循投票系統。有時我們必須選擇我們認為是對的事,即使它不流行。(。。。)我能通過社群的反饋知道我能夠提供什麼以及做什麼樣的工作
236+
Atom 專案的 Issues 沒有投票機制,因為 Atom 團隊在不會遵循投票的結果。有時我們必須選擇我們認為是對的事,即使它不是主流看法。(。。。)我能做的是傾聽社群的意見,這也是我能保證提供的服務
237237

238238
<p markdown="1" class="pquote-credit">
239-
@lee-dohm on [Atom 決策流程](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
239+
@lee-dohm [Atom 決策流程](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)
240240
</p>
241241
</aside>
242242

243-
即使不確定是否採用尋求共識的方式,作為維護者,讓大家知道他們正在受到關注。讓其他人知道,以及承諾解決他們的問題,這在很大程度上減少了敏感情況的發生。然後,就去堅決的執行
243+
即使不全然採用尋求共識的方式,身為一名維護者,讓人們知道你願意傾聽意見是一件很重要的事。讓其他人知道意見有被聽見,並且承諾解決他們的問題,這很大程度上減少了棘手情況的發生。接著言出必行的去採取行動
244244

245-
**不要為了獲得決議而急於做出決定。在做一個決議之前請確保每個人已經知道以及所有的資訊以及公開。**
245+
不要為了得到解決方案而急於做出決定。在有所行動前請確保每個人已經知情,保持所有的資訊公開。
246246

247-
### 將對話的重點聚焦於行動
247+
### **將對話重點聚焦於行動**
248248

249-
討論很重要,但是富有成效和沒有效果的對話是有很大區別的
249+
討論很重要,但是有成效和沒有效果的對話是有很大區別的
250250

251-
鼓勵討論,只要它正積極地朝著解決問題的方向進行著。如果對話已經無法再進行下去,只有很少的人在參與或者大家正在討論無關緊要的問題,這時候就該結束對話了
251+
鼓勵討論,只要它正積極地朝著解決問題的方向前進。如果你很清楚地發現對話已經漸漸停滯下來、偏離主題,溝通開始對人對不對事或在小細節上鑽牛角尖,那就是時候該結束對話了
252252

253-
允許這些對話進行下去不僅對解決問題沒有幫助,而且不利於社群的健康發展。它釋放了這樣一個信號,表示允許或甚至鼓勵這種類型的對話,它可能阻止人們提高或者解決未來的問題
253+
允許上述的這些對話進行下去,不僅無法解決問題,還不利於社群的健康發展。這樣讓大家認為這類的對話是被允許甚至是被鼓勵的,它可能阻礙了人們往後提問的意願或者在解決之後的問題上產生困擾
254254

255-
當你們或者其他人每提出一個觀點時,請自問:“這如何使我們更接近一個決議?”
255+
當你或其他人每次提出想法時,問問自己:「這發言如何使我們更接近一個解決辦法?」
256256

257-
如果對話開始有解散的徵兆,問團隊:“我們下一步該做什麼?”才能重新對話
257+
如果對話開始有發散的徵兆,問問團隊:「我們下一步該做什麼?」才能重新聚焦討論
258258

259-
如果一個對話沒有清晰的方向,沒有明確的措施可以採取,或者合適的措施已經被使用,那麼關掉issue並解釋為什麼關掉它
259+
如果一個對話沒有清楚的方向,也會沒有明確的辦法可以執行,又或者合適的解決辦法已經被採納,那麼就結束 issue 並解釋為什麼結束它
260260

261261
<aside markdown="1" class="pquote">
262262
<img src="https://avatars1.githubusercontent.com/u/401111?v=3&s=400" class="pquote-avatar" alt="avatar">
263-
指導一件事朝著正確的方向發展是一門藝術。它對阻止人們浪費時間或者要求他們發表有建設性的看法沒有作用。(。。。)反而,你們必須為接下來的進展給出條件:給大家一個路線,跟隨一個可以得到你們想要的結果的途徑,這樣就不像是些無用的口頭行為
263+
如何循循善誘的將討論串引導到有益的方向,是一門藝術。直接要求人們不要發沒有建設性的文,要大家別浪費彼此的時間,這樣做是沒有效的。(。。。)反而,你必須設立一些限制條件,給大家一個方向,讓大家的意見最終導向成你所期待的結果,這樣就不像是無用的口頭訓斥
264264

265265
<p markdown="1" class="pquote-credit">
266-
@kfogel, [_打造開源軟件_](http://producingoss.com/en/producingoss.html#common-pitfalls)
266+
@kfogel, [_打造開源軟體_](http://producingoss.com/en/producingoss.html#common-pitfalls)
267267
</p>
268268
</aside>
269269

270-
### 挑戰你們的智慧
270+
### 謹言慎行
271271

272-
上下文很重要。考慮誰參與討論,以及他們如何代表社群的其他人
272+
了解來龍去脈很重要。想想誰正在參與討論,以及這些人如何代表社群的其他人
273273

274-
社群中的每個人都為這個問題而煩惱,或者參與討論了嗎?或者只是一部分人感到困惑嗎?不要僅關心活躍的聲音,也請不要忘記考慮社群中保持沉默的人
274+
社群的每個人都是否參與了討論?大家是否對這個議題感到困擾?還是有人在搗亂?記得不僅要關心有發言的人,也要記得為社群中保持沉默的人考量
275275

276-
如果這個問題不代表社群的更廣泛的需求,你們可能要承認只是少數人的擔心。如果這是一個反覆出現的issue,沒有一個清晰的解決方案,那麼指向他們以前討論的話題
276+
如果這個議題不代表社群普遍的需求,你們可能要理解這只是少數人的疑慮。如果這是一個反覆出現的 issue ,而且直到現在還是沒有一個明確的解決辦法,那麼指引他們去看看以前討論的內容,並結束這個討論串
277277

278278
### 找出社群中的決策者
279279

280-
通過一個態度端正和目標清晰的對話,很多困難都是可以解決的。即使在富有成效的對話中,對於如何進行的意見也可能存在差異。在這些情況下,確定一個人或一組人,可以作為決策者
280+
保持態度良善,維持目標清晰的對話,很多困難都可以被解決。但即便在富有建設性的對話中,還是可能會對該如何執行有不同的意見。在這樣的情況下,你要找找看是否有一個人或一組人,可以擔任決策者
281281

282-
決策者可以是專案的主要維護者,或者是大家投票選出的一個小團體。理想情況下,在使用GOVERNANCE文件之前,其實已經確定了決策者和與之相關的事宜
282+
負責做出決策的人可能是專案的主要維護者,或者是大家投票選出的一個團體。理想情況下,事前要先確定決策者是誰和與之相關的事宜,寫在 GOVERNANCE 文件以便不時之需
283283

284-
使用決策者應該是你們最後才能採取的手段。分離issues是一個你們社群成長和學習的機會。利用這些機會並精誠合作,儘量找出問題的解決方案
284+
使用決策者應該是你們最後才能採取的手段。區分這些 issues 是一個社群成長和學習的機會。利用這些機會協作,儘量找出問題的解決辦法
285285

286286
## 社群是開源的❤️
287287

288-
健康,蓬勃的社群每週都會為開源付出大量辛勤的勞動。許多貢獻者指出其他人在開源工作或不在開源工作的原因。通過學習如何建設性地利用這股力量,你們會幫助他人有一個難忘的開源體驗
288+
健康,蓬勃的社群每週都會為開源注入大量的動力。許多貢獻者指出其他人在開源工作或不在開源工作的原因。通過學習如何建設性地利用這股力量,你會在協助的過程中讓他人有一個難忘的開源體驗

0 commit comments

Comments
 (0)