這是早期實務上很惱人的一個問題，還好現在有找到解法了。
Redmine有提供「Watcher」的功能。可讓用戶設定一個名單叫Watcher List。只要這個issue的任何欄位，或是有新增note，Watcher List中的所有Watcher，就都會收到來自於Redmine的信件通知。
這個設計是蠻立意良善的，能讓相關的”重要人士”，在第一時間就知道每個issue的開發狀況，是誰負責處理，什麼時候要執行，預計何時能結束，遇到什麼困難，缺少什麼資源，是功能開發還是臭蟲解決…任何一個細節都不放過，我當時覺得這功能太好太完美了，這才是21世紀的軟體專案開發模式啊！霸特～實務狀況就是會和你想得不一樣。😔
當我在Redmine認真的記錄每個issue的研發歷程，調整狀態及時程後，我往往還是會在事後，再收到別人詢問我整理過回答的問題。WTF…😠我不是有寫在Redmine上，你們不是應該都有收到mail嗎？
後來我學乖(實際上是更糟)，當我整理完後，過一陣子，我會再打電話過去跟對方確認。結果更令人惱火的是道高一尺魔高一丈，他們直接在收信軟體設定篩選器，直接將Redmine系統寄來的信，轉存到另一個沒打算打開來看的資料夾(其實就是「垃圾筒」…😒)
「到底是怎麼回事？你們為什麼不看信？」我不解的問。
「我一天要收十幾封來自於Redmine的信，整個信箱都炸了，我當然沒辦法看Redmine的信啊！」他們講得可是理直氣壯。
「一下子是改個日期，一下子是改個狀態，你們研發過程中的那些源碼的重構，還是討論問題，又關我什麼事？…」他們越想越氣，一股腦的就噴發不少不滿。
也許是我消化資訊的能力，是比別人有鐵胃一點。雖然我掃過標題及內文，很快的就能知道這是不是那麼重要的訊息，但我實在不能太理想化的認為，大家都會有足夠的辨識查克拉。其實不要說是Redmine，大家已經被太多訊息轟炸，光是來自於即時通訊軟體的訊息都處理不完了，一想到還要消化那正經八百的信件，當然是毫不猶豫的”不讀不回”。
雖然我自己也算是專案負責人的角色，瞭解整個專案的所有細節本就是責無旁貸，但沒理由要求所有人的關注深度要跟我一樣深。換位思考，每個專案負責人都希望有什麼智慧產品(管他是人工智慧還是工人智慧…😛)，可以幫他篩選他”需要“知道的重要訊息。他不想什麼都不知道，但也不想什麼雞毛蒜皮之類的訊息都要通知他(對，就是這麼貪心不講理…)。所以基本上，別說是Redmine，這是Google也沒辦法攻克的技術問題。所以終究是需要由人來解決這個問題的，只是怎麼解決會對大家都方便舒心的差別。
後來找到的解法，是利用Redmine原生就有實作的「mention」功能處理。
也就是說，我們只將真正必須收到每個變更的負責人，才加入到watcher list中，其他只是”相關”的人，加入到專案中即可。在issue的生命週期中，有重大的事件發生，像是時程，執行者或狀態之類的變更，才使用「@user」的方式，請Redmine系統發信給相關人士，請他們知悉有這件事發生。
以我們自己實務使用的安排是這樣的，我請組員開立任何issue，不用花腦力想要不要通知我，直接把我加到Watcher List中就是了。每個issue要通知誰，我會再mention他們(當然，他們若自己想這麼做會更好)。因為橫豎我每天都是要逐條追蹤，這種要通知誰的雜事我就順手幹完，就不用再消耗我們勞苦功高的軟體人員的注意力了。
改用mention後，組內的評價反應不錯，不少會收到信的用戶也反應這樣好多了，至少有給彼此一個選擇權。真的自己想認真關注的，就加Watcher；只是想知道一個階段性進度的，就等mention。
雖然這並沒有馬上，也不可能改變用戶不會太關心來自於mail的訊息，但至少是個好的開始，若今天我是熟Ruby on Rails的開發者，我想我會自幹一個插件，直接把mention串到LINE或Telegram去，看你們往哪兒躲…🧐
(mention怎麼用，急著想知道的再私訊我。我有空也整理一篇出來分享給大家。)
