<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # 避免常見的陷阱 ### 不要發表無目的的文章 在線項目中一個常見的陷阱是認為你需要回復所有的東西。你不必如此。首先,一般會有太多你無法同時跟蹤的線索,至少是經過它開始的幾個月后。其次,即使你已經決定參與,人們說的大多數話都無需回應。開發論壇都會不同程度的由下列三類信息占據: 1. 提出重要事物的信息 1. 提出對他人曾經說過的話表示支持或反對的信息 1. 總結信息 上述信息并不是*必定*需要一個回應,特別是當你根據到目前為止的線索,很確定其他人會說出以前你說過的話時。 (如果你擔心別人也使用這個策略,而落入等待-等待的循環,不必如此;幾乎總會有*某人*愿意跳出來解決問題。) 回復應該由明確的目的激發。首先要問自己,是否知道所期望的完成的任務?其次,是否如果沒有你的話,這個事情就無法完成。 在線索中發出你的聲音的有兩個理由,包括a) 當你在提議中發現了一個瑕疵,你懷疑你是唯一看到它的人,另外b) 你發現他人之間錯誤交流,并且知道你可以通過澄清文章修正它。通常在郵件中僅僅表明對某人工作的感謝或者只是說“我也是!”,因為讀者可以立刻確認此類文章無需任何回應或進一步的動作,所以當讀者達到郵件的最后一行,一個干凈的結束符合他的心理需求。但是即使到了此時,說話之前也要再三考慮;一定要讓別人覺得你說的太多而不是太少。(在忙碌的郵件列表中工作的更多想法的第二部分請看[Appendix?C, *為什么我要關注車棚的顏色?*](# "Appendix?C.?為什么我要關注車棚的顏色?")) ### 多產VS非多產的線索 在忙碌的郵件列表中,你有兩個誡命。第一,很明顯,要指出哪些需要關注,哪些需要忽略。第二,要避免*產生*噪音的方式:不僅僅是你希望自己的文章保持較高的信噪比,你也希望這些信息可以刺激*其他*人也保持同樣的信噪比,或者干脆不發表文章。 為了展示這是如何發生的,考慮一下事情發生的上下文。非多產的線索的特征是什么? - 發生的爭論是在重復,仿佛發布者認為沒有人聽說過。 - 隨著賭注的縮小,夸大和連累的升級。 - 大部分評論來自做過很少事情或沒做過事情的人,而能幫助完成事情的人則保持沉默。 - 大多數想法的討論都沒有作出明確的提議。 (當然,任何有趣的想法都是從不清晰的遠見開始;重要的問題是之后的方向。討論是否將遠見變得更具體,或者分裂為更小的遠見,副遠見和本體論的爭論?) 不要因為某個線索開始不夠多產而認為它是浪費時間。它可能是一個重要的主題,正因為他非常棘手所以難以做出進展。 將線索引向有用而不是蠻干是一項藝術,僅僅是告訴人們不要浪費時間,或者告訴他們在沒有形成建設性的內容前不要說話并沒有用。你或許可以在私下這樣想一想,但是如果你大聲的說出來就會成為一種冒犯。相反,你必須促成進一步進展的條件—給人們一條路,一條可以將結果導向期望的路,而無需發出指揮命令。這樣的基調將會大為不同。例如,這樣很不好: > *這個討論已經跑的漫無邊際了。我們可以暫停這個主題,直到某人能夠提交一個補丁實現這些建議嗎?沒有理由繼續反復說同一件事情。代碼比單詞更有力,伙計們。* 然而這樣很好: > *線索浮現出了多個提議,但都沒有完成所有的細節,至少還不足以形成表決。然而現在我們也說不出新東西了;只是在反復重復以前說過的東西。此時,為了進一步的討論,最好提供提議的完整規格或補丁。然后我們至少有明確的動作可以做(即對規格達成一致,或應用和測試補丁)。* 第二種方法與第一種方法完全相反。第二種方法不會讓你與他人發生聯系,也不要指責他們將討論帶入了螺旋。無論你在之前是否參與到線索的討論,都要說是“我們”,因為即使你一直在線索中保持沉默,線索的結果也有你的份。它描述了為什么線索到了烏有之地,這樣做并沒有輕蔑或判決的含義—它只是不帶感情的對事實的描述。最重要的,它提供了一個行動的正面課程,這樣人們就不會感覺到討論被關閉了(對于他們可以被誘惑去造反的限制),而會感到獲得了一個方法可以將對話帶入更有建設性的水平。這是人們自然會期望遇到的標準。 你不會一直希望讓線程進入更有建設性的水平—有時,你只是希望它趕快離開。文章的目的只是從中選擇一個,放棄另一個。如果你能斷定線索離題太遠,而且沒有能實際上*去*完成你所建議的步驟,那么你的文章會有效的終止線索,而且不需要這樣做。當然,沒有關閉線索的安全方法,即使有,你也不會希望去使用。但是詢問參與者在作出可見的進展和停止討論之間做出選擇則是完美可防衛的,如果可以圓滑完成的話。然而,還是要小心永久的平息線索。一些純理論的討論可能會十分多產,取決于主題,而且如果過快的要求解決也會扼殺創造過程,也會讓你看起來不夠耐心。 不要期望線索會立刻停止。在你的文章之后,還是會有些文章,一方面因為郵件是排隊傳遞的,另一方面是因為人們想說最后一句話。不必為此擔心,你不用再說一遍。只需要讓它逐漸消失或不消失,這取決于具體的情況。你不可能有完全的控制;另一方面,你可以期望在大量線索的統計上有顯著的效果。 ### 主題越軟,辯論越長 盡管討論會在任何主題上緩慢前進,但是隨著主題技術難度的降低,緩慢前進的可能性就越高。畢竟,技術難度越大,能夠理解的參與者也就越少。這些參與者更有可能是最有經驗的開發者,他們已經參加過無數次這樣的討論,知道如何才能與每個人達成共識。 因此,如果技術問題易于理解或容易得出自己的意見,或者是諸如組織、公開性和資金的軟主題,就很難達成共識。人們可以永遠參與到這種辯論中,因為這事沒有門檻,沒有決定(甚至在之后)正確或錯誤的明確方法,而且因為等待其他討論者結束是一個成功的策略。 對于長期的主題,討論的數量與主題的復雜度成反比的原理,被非正式的稱為*Bikeshed效用*。這里是Poul-Henning Kamp為BSD開發者作出解釋的著名文章: > 這是一個很長的故事,或者說是一個老故事,但它實際上很短。C. Northcote Parkinson在20世紀60年代初編寫了一本叫做“Parkinson定律”的書,包含了許多管理動態性的真知灼見。 > [...] > 這些例子中包括自行車棚,另一個更重要的組件是核電站,我猜這描述了本書的年齡。 > Parkinson展示了如何進入董事會,并得到建造花費幾百萬,甚至幾十億美元核電站的許可,但如果你希望建造自行車棚,則會陷入無休止的討論。 > Parkinson解釋了這是因為核電站太大、太貴和太復雜了,人們無法掌握,所以不會去嘗試,轉而會假設某人會在需要時檢查所有的細節。Richard P. Feynmann在他的書中提供了一些關于洛斯阿拉莫斯(美國新墨西哥州中北部一個無法人地位的社區,位于圣菲市西北。1942年被選作核研究基地,生產了第一批原子彈。從1947年至1962年原子能委員會統治著這個城鎮。)的有趣而且非常到位的例子。 > 另一方面是自行車棚。所人都可以在周末建一個車棚,而且還有時間看電視上的比賽。所以無論準備的多好,無論你的提議是多么的有道理,人們會抓住機會展示他在做自己的工作,他正在關注,他就在*這里*。 > 在丹麥,我稱之為“配置你的指紋”。它關于自尊和聲望,關于能夠指向某事并說“這里!我那樣*做*的。”這是政客的典型特征,但是現在很多人都會這樣。想想濕水泥中的足跡。 (他的完整文章也十分值得閱讀。請看[Appendix?C, *為什么我要關注車棚的顏色?*](# "Appendix?C.?為什么我要關注車棚的顏色?"),以及[http://bikeshed.com](http://bikeshed.com)。) 任何參加過團隊決策的人都會知道Kamp所說的東西。然而,通常還是不可能說服*每個人*避免噴刷自行車棚。最好你能指出這是一個必然存在的現象,并在你發現它時,說服高級開發者—這些文章擁有最高權重的人—盡早丟下他們的刷子,或至少不要添加噪音。自行車棚噴涂的聚會永遠不會完全消失,但是你可以通過在項目文化中傳播這個現象的知識讓這種事變得時間更短,頻率更低。 ### 避免圣戰 一場*圣戰*是一場爭論,經常但不會一直是相對的小問題,一般不會通過辯論得到解決,但是有人會充滿熱情的繼續辯論,期望他們一方會獲勝。圣戰并不與自行車棚完全一樣。人們粉刷車棚通常是突然跳出來的意見(因為他們可以),但是他們不必強烈的感覺必須如此,并且以后會表達其他的意見,互相矛盾的意見,以展示他們理解問題的所有方面。而另一方面,在圣戰中,理解對方則是示弱的表現。在圣戰中,每個人認為有一個唯一正確的答案;他們只是不認可是什么。 圣戰一旦開始,通常就不可能讓每個人都滿意。在正在進行的圣戰中指出這點并沒有好處。每個人都已經知道。不幸的是,但是對于通過連續的討論*能否*解決爭論這一問題,是圣戰并不認可的一個常見特性。從外部看來,很明顯沒有一方可以改變另一方的意見。而從內部看,則認為另一方太過蠢笨,也沒有想清楚,但是經過足夠的恫嚇則能回心轉意。現在,我*沒有*說在圣戰中永遠沒有正確的一方。有時確實有—在我參加的圣戰中,真理當然永遠屬于我這一邊。但是沒有關系,因為沒有算法可以令人信服的描述某一方是正確的。 人們試圖解決圣戰的一個常見的,但是不能令人滿意的方法是說“我們的討論已經浪費了過多的時間和精力!我們能不能把它忘掉?”這樣有兩個問題。首先,時間和精力已經投入,不可能收回了—現在唯一的問題是還有*更多的*力量嗎?如果某人感覺更多的討論會結束這個問題,那么繼續就還有意義(從他們的角度看)。 另一個要求這件事必須丟棄的問題是這通常等同于允許某一方打破現狀,通過無為宣布勝利。在某些情況下,現狀無論如何是不能接受的,每個人都認為需要作出決定,必須有所行動。為每個人丟棄這個主題通常比任何人放棄論點更壞。但是因為這種兩難可以平等的應用到所有人,所以仍有可能永久結束辯論。 那么你應當如何處理圣戰? 第一個回答是,做好準備避免其發生。看起來并不是完全沒有希望: 你可以預期到一些標準的圣戰:可能關于編程語言、許可證(見[Chapter?9, *許可證,版權和專利*](# "Chapter?9.?許可證,版權和專利")的[the section called “GPL和許可證兼容性”](# "GPL和許可證兼容性"))、回復處理(見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “偉大的Reply-to辯論”](# "偉大的Reply-to辯論"))和一些其他主題。每個項目可能都有自己的圣戰,長期開發者會很快熟悉。停止圣戰,或者減少其危害的技巧在大多數地方都是相同的。即使你肯定你屬于正確的一方,可以試著尋找*一些*方法展示自己對對方的同感,并理解另一方的論點。通常問題是在圣戰中的每一方都盡可能高的建筑自己的墻,而使其他見解看起來是完全的愚蠢,放棄或改變思想的行動在心理學上變得不可忍受:這樣做不僅僅是承認錯誤,而是*必然*并且會一直錯下去。將這種承認變得可口的方法是展示你的不確定性—精確的展示你理解他們的辯論,發現他們至少很敏感,即使最終并不是令人信服。作出為回應姿態留出空間的姿態,通常情況會得到改善。也許你不會得到期望的技術結果,但是你可以避免對于項目士氣的非必要相關損害。 當圣戰不可避免時,盡早決定你要關注多少,并樂意公開放棄。當你這樣做,你可以說你正在退出,這場圣戰毫無價值,而不要展示出挖苦,并且*不要*利用這個機會對對方的辯論做最后一次攻擊。只有優雅的去做才能有效的放棄。 編程語言的圣戰有些特殊,因為雖然其本身的高技術性,然而很多人感覺自己有資格參與其中,因此結果可能取決于項目編碼編寫較好的部分的語言。最好的解決方案是盡早選定語言,由初始的有影響的開發者引入,根據你最舒服的語言,而不是因為其優于其他語言而使用。*不要*將對話退化為經典的編程語言比較(通常是當某人因為某些原因提出Perl。);那是死話題,你應該明確的拒絕涉及。 關于圣戰的更多歷史背景,可以看[http://catb.org/~esr/jargon/html/H/holy-wars.html](http://catb.org/~esr/jargon/html/H/holy-wars.html),Danny Cohen的論文普及了這個術語,[http://www.ietf.org/rfc/ien/ien137.txt](http://www.ietf.org/rfc/ien/ien137.txt)。 ### “吵鬧的少數派”效應 在所有的郵件列表討論中,都有一些少數派不斷用大量冗長的郵件血洗列表,給人存在大量異議的印象。有些像filibuster(一種議會程序,阻撓議案的通過),但是這種廣泛異議的幻想更加強大,因為它分割了任意數量的不連續文章,大多數人無法跟蹤何人在什么時間說了什么。他們會產生主題存在嚴重爭議的直覺印象,并等著小題大做的平息。 中和這種效應的最好方法是明確指出并提供證據證明這種異議的數量與認可的數量相比是微不足道的。為了增大這種差距,你或許會希望私下調查大多數時候會保持沉默,但是你懷疑是認可大多數的人。不要說這些持異議者是故意夸大這種印象。他們一般不會是故意,即使故意,指出來也沒有策略上的好處。你只需要指出雙方實際數字的比較,人們就會認識到他們對于形勢的直覺與現實不符。 這個建議并不是只能應用到具備明確支持和反對位置的問題。它可以應用到所有小題大做的問題上,但是如果大多數人認為討論的問題不是一個問題時,則不是這么清楚。如果經過一段時間,你認為這個問題并不值得行動,并且看到它無法獲得更多的吸引力(即使有了大量的郵件),你可以公開評論其沒有吸引力。如果“吵鬧的少數派”正在工作,你的文章就會像一縷清風。大多數人對于這個討論的印象都會有一些陰郁:“好象是發生了一些大事,因為有很多文章,但是我看不出有什么進展。”通過解釋討論的形式使其顯得比實際上更加吵鬧,你給其新的面貌,人們可以重新修訂自己對于發生問題的理解。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看