我是個急性子，所以沒怎麼成功給社群提過pr，除非那個專案是我自己的，或者社群讓我有直接merge的許可權。好比之前吐槽完sdl開發太慢後，自己直接fork了乙份，然後在上面加功能。
pr是開源社群的基石，正真實踐了開源的益處：「人人貢獻，人人受益」。
乙個pr提出後的歷程還是比較長的。如果很多人關注和討論，可能促使你的pr早日受到專案維護者的關注，盡快合併進去。大家會不停地給意見，你根據意見不斷的調整，在這個期間，可能還有新的**合入，這個時候你可能需要反覆修正衝突。
在專案codebase還不大的情況下，一切看起來很美好。但是專案一旦到大到一定程度後，合併pr的代價就會變得極為的高昂。因為專案大到一定程度，質量要求會變得很高，否則是沒辦法繼續下去的。如果不控制好質量，很可能就需要重構才能讓專案繼續走下去。而pr天生**複雜，質量參差不齊，光review的成本就已經很高了，更別說反覆的交流修改碰撞帶來的時間代價，很多情況甚至review的人相當於重寫了一遍。第二個是，新的pr極容易造成regression,以前修好的問題又出現了，或者出現新的問題。所以這個時候合併乙個新的pr基本已經很困難了，或者說遠遠已經超過了專門維護人員的成本。
通常pr無非是：
bug 修復
新特性新增
原有功能增強
最終社群會區別對待（感謝smilegator提供的資訊）：
bug fix 會有限確認並且merge
新特性會首先確定risk和impact,而不是這個feature本身的價值
好而且大的feature 一般還是會offline 去討論的，並且會提出design doc
所以我們看到，此時你提的pr，價值已經很小了，頂多是給個示例。這或許也是乙個困境，我們總是希望人人都能夠貢獻，然而接受這種貢獻的成本在到某個階段就變得高昂了，這可能違反了我們的直覺。這和開源一樣，最終還是需要商業的回饋，方能開花結果。
哦，對了，所以維護自己重度使用的私有版本的開源專案，會變成乙個必然的選擇。
矩陣的困惑
include stdafx.h include include include include pragma comment lib,cv.lib pragma comment lib,cvcam.lib pragma comment lib,cxcore.lib pragma comment l...
新手的困惑
作為一名學習c 的新手，在學習的過程中遇到了很多的困惑。第一是沒有合適的教材，買了一堆的教材，最後發現很多都沒用，都是些標題黨寫的，看著挺吸引人的，實際上不一定適合你 第二是有問題的時候不知道需要能問誰，描述問題不準確網上找答案也不一定有結果，這樣就需要學習者平時多總結。第三是沒有實踐的機會，只是看...
開始的困惑
我是大專畢業的，可能連大專都不能算。但是我現在所選擇的職業是程式設計師。我看了很多人寫的書或者文章，我發現，他們都在說，程式設計師生涯是怎麼怎麼的艱辛，怎麼怎麼的不如意。我開始懷疑了。雖然成功人士的經驗給了我些許的安慰，但是，我心裡還是惴惴不安的。我很需要有人來提醒我一下，我現在做的事情是對的，我所...