（1）我決定什麼時候開始這個專案
我從開源社群聽到最大的抱怨之一是，人們既期望維護人員夜以繼日地工作。同時人們又對為了修復bug和極端情況下 而長時間的無薪工作行為感到羞愧。這容易造成工作倦怠並且傷害到整個團隊的積極性。
從第一天開始，我決定只在我想要的時候做這個專案。如果有人需要新增一些東西到專案裡可以組隊自己新增或付錢給我（Yelluw）來新增。我不反對個性需求。我反對的是所有開源工作都是免費的（如啤酒）。通過限制什麼時候在專案工作，我減少壓力的量。任何外來者的無理期望都是被這個規則簡單處理掉的。
（2）休息
休息很重要。當你在一個專案上工作時，更是如此。我知道這對有些人來說是很難，但是工作過多會降低產量和質量。休息讓我考慮實施並提出更好的解決方案。這也可以讓我的思緒自由發散地去想想其他的程式碼。過分集中於一個程式碼往往是很累人的。
我的經驗法則是，每兩個星期的工作，我休息時間不少於連續三天。休息期間不寫程式碼。
（3）提早設定期望
從一開始就設定期望，人們就不能讓你做你不想做的事情。對我來說，期望很簡單：
- 我不會提供支援。
- 我只會修復提出來的重要的錯誤程式碼（他們影響我或我的付費客戶）。
- 我不會接受貢獻。
- 我不會接受捐款。
（4）從一開始就寫文件
這很簡單，但是有效。我寫專案文件，來減少問題的數量和支援的要求。這一課是多年前學的。沒有寫文件的程式碼意味著其他開發者會在工作期間打擾我問我，我認為是愚蠢的問題。原來他們不是愚蠢的問題。我才是愚蠢的那一個–沒有記錄程式碼使實施變得簡單。現在我從一開始就記錄，並確保得到反饋的檔案。
（5）迅速關閉問題
如果我不打算處理這些問題，就沒有意義了。眼不見心不煩。
（6）不接受大家的捐款
並不是每個人都適合這個專案。我們可能無法合作。人們往往認為專案維護者都張開雙臂迎接他們的貢獻。不，一點也不。由我來決定你的貢獻是否符合一般的專案路線圖。不新增任何額外的工作開銷。正確記錄。這似乎太苛刻了嗎？是的，這是嚴酷的。但它對我有用。我不想花我的時間處理BS。我就想寫程式碼，然後得到報酬而已。
（7）不接受每個人的反饋
原來有大量的不良反饋。人們傾向於給予反饋但又不需要花時間去理解專案的背景。然而，每個專案都有它開發的上下文。沒有它的反饋（建議）是垃圾。曾經有人告訴我，我應該解決這個問題，因為它使專案無法使用（雖然我自己在生產中就使用它）。有些意見就像混蛋。你會經常會遇到一些。學會恰當地處理它們吧。
（8）定義成功
這就是一些人失去動力的所在。擁有一個人們認為成功的專案需要花費大量的時間和精力。我不在乎人們是否認為這個專案是成功的，因為我定義了成功意味著什麼。這個專案成功嗎？對！它已經節省了我的時間和精力。但這不是巧合，該專案的成功是從一開始就定義為：如果我能減少我為客戶在網站上工作的時間，這個專案將是成功的。成功不是建立在一些虛榮的基礎上，就像它變得多麼受歡迎一樣。它是基於它對我日常生活的影響。成功的定義是什麼，你永遠不要讓任何人說服你。
（9）我玩得很開心
我認為編碼是有趣的（在大多數情況下）。有樂趣意味著我喜歡工作。即使我不太喜歡這樣做的想法。
（10）收穫
我們都會犯錯。我發出的第一個版本有一個大錯誤！但我發現它並從錯誤中學習。學習也意味著我不會為錯誤而感到羞愧。不，這意味著我會把錯誤當作生命的方式來指明我下一步需要學的東西。
結論
開源專案的工作是非常有意義的，它也是非常緊張。我知道這裡有些事情看起來有點過分，但我很重視我的健康。我希望你看完這些方法後會讓你重新思考你的工作，你的開源專案，你如何維護。我們都是熱愛科技的人。下次見！
評論(0)