在mantis中的 問題狀態一共有以下幾種
10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved,90:closed
10:新建,20:反饋,30:公認,40:已確認,50:已分派,80:已解決,90:已關閉
問題完成度有以下幾種：
10:open,20:fixed,30:reopened,40:unable to reproduce,50:not fixable,60:duplicate,
70:no change required,80:suspended,90:won\'t fix
10:未處理,20:已修正,30:重新開啟,40:無法重現,50:無法修復,60:重複問題,70:不是問題,
80:暫停,90:不做修改
可以在管理裡面看到預設流程下的各種狀態和完成度，一些基本的應該是這樣吧：
角色有以下幾種
報告人修改人
測試人審核人
流程1報告-審核-修改-測試-關閉
乙個問題來了以後，經過審核人審核，提出修改意見，然後指派給修改人員，
修改人員修改完成後指派測試人員，或者由審核人指派測試人員，測試完畢後關閉
如果有問題仍然存在，問題狀態為反饋，完成度為 ，重新開啟
過程問題狀態完成度
新報告問題新建未修改
審核後已確認，已分派未修改
修改後已解決已修正，無法重現，重複問題，不是問題，暫停，不修改
測試後已關閉，反饋已修正，無法重現，重複問題，不是問題，暫停，不修改，重新開啟
流程2報告-審核-測試-關閉
當審核認為不需要修改的時候可以直接將問題分派給測試人員，由測試人員測試，
如果有問題仍然存在，問題狀態為反饋，完成度為 ，重新開啟
過程問題狀態完成度
新報告問題新建未修改
審核後已確認，已分派未修改，無法重現，重複問題，不是問題，暫停，不修改
測試後已關閉，反饋已修正，無法重現，重複問題，不是問題，暫停，不修改 ，重新開啟
但是其中的公認是什麼意思呢？在什麼時候使用？
如果沒有到最後也沒有什麼好的理解，我準備把這個狀態更改為 「設計」
也就是說，乙個問題需要重新更改設計，這個動作修改人是不能完成的，也就是所要增加乙個角色「設計人員」
流程3報告-審核-設計-審核-修改-測試-關閉
過程問題狀態完成度
新報告問題新建未修改
審核後設計，已分派未修改
設計後已確認未修改
審核後已確認，已分派未修改
修改後已解決已修正
測試後已關閉，反饋已修正，重新開啟
一、new(新建) 狀態說明：
1. 測試人員發現bug，填寫好bug report後通過「1」submit bug，此時bug的狀態為new； 2. 處於new狀態的bug，team leader認為是bug且需要修復的，通過「2」將bug分派給
相應的開發人員，此時bug的狀態為assigned(分配狀態)；
3. 處於new狀態的bug，team leader認為測試人員的bug描述不清或者有疑問，通過「3」
將bug反饋給測試人員，並在note裡註明原因，此時bug的狀態為confirmed（回饋狀態）；
4. 處於new狀態的bug，team leader認為需要延後修復、需跟客戶確認、不能修復的bug，
通過「4」將bug的狀態更改為acknowledged（等待狀態）。
二、assigned(已分派) 狀態說明：
5. 處於assigned狀態的bug，開發人員將其修復後，通過「5」將bug的狀態更改為resolved； 6. 處於assigned狀態的bug，開發人員認為測試人員的bug描述不清或者有疑問，通過「6」
將bug反饋給測試人員，並在note裡註明原因，此時bug的狀態為confirmed； 7. 處於assigned狀態的bug，開發人員認為需要延後修復、需跟客戶確認、不能修復的bug，
通過「7」將bug的狀態更改為acknowledged。
三、resolved(已解決) 狀態說明：
8. 處於resolved狀態的bug，測試人員進行回歸測試確認bug已經被修復後，通過「8」
將bug關閉，此時bug的狀態為closed；
9. 處於resolved狀態的bug，測試人員進行回歸測試發現bug沒有修復或者由此引發了其
他的bug，通過「9」將bug反饋給開發人員，並在note裡註明原因，此時bug的狀態為feedback。
四、closed(已關閉) 狀態說明：
10. 處於closed狀態的bug，若測試人員在測試過程中還發現該問題，可以通過「10」 將
bug反饋給開發人員，並在note裡註明原因，此時bug的狀態為feedback。
五、feedback(打回) 狀態說明：
11. 處於feedback狀態的bug，開發人員將其修復後，通過「11」將bug的狀態更改為resolved； 12. 處於feedback狀態的bug，開發人員認為測試人員的bug描述不清或者有疑問，通過「12」
將bug反饋給測試人員，並在note裡註明原因，此時bug的狀態為confirmed； 13. 處於feedback狀態的bug，team leader或者開發人員認為該bug需要重新分派，通過「13」
將bug重新分派給相應的開發人員，此時bug的狀態為assigned；
14. 處於feedback狀態的bug，開發人員認為需要延後修復、需要跟客戶確認、不能修復的
bug，通過「14」將bug的狀態更改為acknowledged。
六、confirmed(已確認) 狀態說明：
15. 處於confirmed狀態的bug，測試人員對於開發人員的疑問作出回應，通過「15」將bug
的狀態更改為feedback，並在note裡註明原因；
16. 處於confirmed狀態的bug，測試人員認為該bug有爭議，需上一級領導確認的，通過
「16」將bug的狀態更改為acknowledged；
17. 處於confirmed狀態的bug，測試人員認為該bug不需要修復，通過「17」將bug關閉，
此時bug的狀態為closed。
七、acknowledged(公認) 狀態說明：
18. 處於acknowledged狀態的bug，team leader或者測試人員認為該bug必須修復，通過「18」
重新將bug分派給相應的開發人員，此時bug的狀態為assigned；
19. 處於acknowledged狀態的bug，team leader或者開發人員發現該bug已經修復了，通過
「19」 將bug的狀態更改為resolved；
20. 處於acknowledged狀態的bug，測試人員認為該bug不需要修復，通過「20」將bug
關閉，此時bug的狀態為closed
Mantis使用說明
rel file list href file c 5cdocume 7e1 5cadmini 7e1 5clocals 7e1 5ctemp 5cmsohtml1 5c01 5cclip filelist.xml 型別，選擇時間型。在這個版本中，時間型被顯示為 8 我們可以修改 lang 語言檔案...
Mantis中的狀態
在 mantis中的 問題狀態一共有以下幾種 10 new,20 feedback,30 acknowledged,40 confirmed,50 assigned,80 resolved,90 closed 10 新建,20 反饋,30 公認,40 已確認,50 已分派,80 已解決,90 已關閉...
Mantis安裝說明文件
在錯誤追蹤系統中，mantis絕對是個輕量級的工具，無論安裝還是配置或使用，正如它自己的目標中所宣稱的。但是，對乙個中小型的專案來言，功能夠用。mantis是乙個基於php mysql web的開源的錯誤追蹤系統，以下安裝教程假設系統已經安裝好了apache php mysql的執行系統，如何安裝這...