如何看待某託管在 GitHub 的前端開源項目關閉 Issue 欄目的行為？

01-28

=================
看了下答題區，確實有表述不清的地方，誤導了一些答主，已經更正，題主在學習某備受推崇的前端技術的時候發現存在缺陷（這裡就不點名了）。準備給其提issue的時候發現其issue欄目關閉，相關社區也活躍度不夠。實在無奈

不關閉一直開著會有利息嗎……

---

題主修改了問題，原來說的是 repo 關閉 issue 功能。那你可以了解一下該項目官方的參與渠道，因為 GitHub 上的項目也可能只是一個鏡像。有的項目是要求通過 mailing list 參與討論的。

開源已經表達了對世界的友善。

代碼已經免費給你用，你還想永無止境地獲得技術支持？

你可以選擇不用，別人也可以選擇不開。

你要別人開 Issues 那麼你能付出什麼？

匿名用戶 (提問者)24 分鐘前
開源就意味著責任，互聯網技術發展到現在這個階段，不缺開源技術，也不愁沒人為知識付費。不想支持為什麼要開源。誤導？？還是想秀一下優越。古話說的好一顆老鼠屎壞一鍋粥

「開源就意味著責任「，這責任多大啊？就算付費軟體的責任都是有限的 --【2014】微軟今起停止對XP技術支持：影響2億國內用戶

秀優越感怎麼就成老鼠屎了？別人秀別人的你有損失嗎？

如果選擇一個社區不活躍、結構不穩定的開源項目投入到生產中，那就是你們技術選型的問題。

如果市面都找不到合適的開源項目，那就需要你們的研發團隊招更牛的人了。屆時項目完成，記得開源啊！

別學有一些老年人：坐公交車，年輕人不讓座就打罵別人。把自己當成了道德的神。

你又為世界貢獻了什麼？

很顯然，這是作者的自由。

雖然10和集鵠大叔都說了不少了，但我還是想說說。題主首先應該要清晰一個概念：開源 != 交易。商業軟體都有停止服務的時間，何況開源軟體了。不是你使用了，就必須要求開源者給你提供任何無償或者有償的服務，你使用開源軟體是你的自由，那開源者選擇開或者關 issue ，甚至是否維護該項目，是否接受 PR 都是開源者的自由。近期就有一個 PR 提給某個開源軟體，但作者明確表示和自己的設計理念背離，任憑下面的群眾呼聲不斷，但作者就是不接受這個 PR，你能說他有錯？你要覺得他有錯，自己fork一份，寫成自己覺得對的，不是很好？

好了，感覺說了太多的廢話，總結起來就是：你要不喜歡自己 fork 或者換一個就好，賴知乎發帖，除了發泄情緒，讓人覺得你很 low 外，對你目前所面臨的問題，毫無幫助。

關閉 issue 一般的原因有：問題解決/不需要解決。

還有一種非常常見的就是：issue 表述不清。

就像這個知乎問答一樣，應該先被關閉。

更新：如果是關閉 issue 入口的話，有幾種情況：

- 有可能是作者只是想找個地方放放代碼，你無視就好了。

- 有可能停止維護

- 仔細看 README，像 EGG 就是關閉所有插件的 issue 入口，統一在主倉庫那邊 issue 反饋。

開源項目的初心是奉獻，意味著讓更多的人參與進來，共同去做好一件事情。有意見你可以提出來，接不接受是作者的自由，不要說開源就意味著責任，連微軟這樣的商業化公司，尚且會宣布不再對XP進行維護，對一個非盈利性質的項目，作者有什麼義務為你提供永久免費的技術支持，不滿意你可以fork一份自己來，打著開源的旗號道德綁架，這跟要求別人給你讓座是一樣的，請分清【情分】和【責任】這兩個詞。

我來提名一個吧，Weex 在 GitHub 上的鏡像倉庫就沒開 issue 欄目。不過 Weex 不是個前端技術，應該不是題主想點名的那個。目前 Weex 支持的前端框架 Vue 和 Rax 的代碼都在各自的倉庫里，而且也都開了 issue。

Weex 是一個正在 ASF（Apache 軟體基金會）里孵化的項目，代碼和 issue 都是在 Apache 的平台里管理（代碼倉庫在這裡，issue 在 JIRA 上，討論問題來郵件列表）。現在大家在 GitHub 上看到的 apache/incubator-weex 只是個鏡像，孵化畢業之後鏡像倉庫就會變成 apache/weex，apache/incubator-weex 應該會被直接刪掉。GitHub 上的 issue 數和 star 數壓根不是衡量 Weex 活不活躍的標準。

另外 Weex 在 GitHub 上的那個鏡像倉庫目前只有 ASF 和機器人（asfgit）有許可權，Weex 的 committer 和普通 GitHub 用戶在 apache/incubator-weex 上的操作許可權是一樣的。Weex 的 committer 都是把代碼提交到 Apache 的倉庫，然後機器人自動同步到 GitHub，機器人把 PR 標記成 merged 還是 closed 就說不準了，與是否 rebase、是否 squash 有關。想要打開 GitHub 鏡像倉庫的 issue 也不是不可能，但是要有充分的理由，而且和 JIRA 只能保留一個。

最後再多提一點，我覺得無論放在哪，issue 都不該是個問問題的地方，問技術問題去 StackOverflow。把 issue 當貼吧用不僅消磨維護者的耐心，也會讓真正想找到 issue 的人反感。

沒啥大不了吧

大概就是, 放這裡只管開源代碼, 不保修, 來這裡提建議我也不會看的..乾脆關掉issue

要麼多半就是鏡像類的repo, 不需要github里的社交屬性吧?

這很正常啊，有許多著名的項目只是把 Github 當作是一個 git 伺服器用的，它們往往有自己的 Bug Trace ，不開 issue 挺正常的啊，它們往往連 PR 都不開的。

另外，很多人不遵守 issue 規則亂開 issue 的事情已經是個普遍現象了，特別是在現在開源越來越深入人心的情況下。一些直面用戶的項目，往往是有好幾百 issue 沒一個 PR 。

所以這不是一件多麼不可思議的事，畢竟反饋 Bug 最好的方法就是丟個 PR 給作者啊，在互聯網上解決問題最好的方法不是好好的提問，而是丟個愚蠢的答案，所以各位千萬不要懼怕發 PR。

看看知乎這伸手黨的嘴臉，1024上就不會這麼醜陋。

倉庫主人開心的話刪了都可以

要干點啥為什麼不自己去clone一份代碼呢

不知道題主的意思是指關閉單個issue還是直接關閉issue功能。

如果是關閉issue功能，多半是項目停止維護。

例如

fex-team/ueditorgithub.com

我來說說和其他回答完全相反的觀點吧。

我有過類似經歷，我曾經向sonar(一個開源代碼質量管理平台)社區提交了部分補丁，主要的目的是能讓這個工具管理前端項目的代碼質量。sonar及其大部分官方插件關閉了issue欄目，並在文檔中鏈接的ticket管理工具中關閉了註冊渠道。外部開發者只能通過郵件列表交流。

沒有issue功能意味著項目的開放性被大大削弱，PR的方便即時性也大打折扣。issue功能的關閉，可以有效阻止伸手黨，但這也會造成髒水和孩子一同被潑出去了的後果。

你這個「如題」？題目也表述不清啊。

github是開源技術？

關閉一個issue條目？

還是關閉issue功能？

建議題目描述修改，或者關閉問題。