我們使用問題跟蹤器來跟蹤軟件問題：錯誤，新功能，增強功能等。通常，解決問題的代碼更改需要更新文檔;例如用戶手冊，安裝手冊，測試程序等。一般來說，文檔是由不同的人員組成的 - 技術作者，QA團隊完成的，但實施人員在解析文檔時提供所需更改的簡要說明會很有幫助問題固定。使用問題跟蹤器進行文檔更新？
我想要一個輕量級的方法來鼓勵這個工作流程，我認爲它可以在問題跟蹤器中完成。我能想到的幾個選項來做到這一點：
當開發者解決的bug，克隆作爲新的錯誤對一個「文檔」組件總結所需的文檔的變化。
在「已解決」和「已關閉」之間的工作流程中添加「待處理文檔」狀態。
爲問題添加自定義布爾值字段，例如，一個「需要文檔更新」標誌。
向包含建議的更新摘要的問題添加自定義文本字段。
每個選項都有優點和缺點;例如＃1會導致很多問題的產生，文檔更新只是工作流程中的又一步驟（＃2）。另一方面，不是所有問題都將有一個文檔更新並需要通過工作流程。
有什麼方法可以有效地跟蹤這些文檔更新？
我將輸入文檔的新更改請求，以指定需要更新的內容，並將其鏈接到原始更改請求。這使得文檔組可以清楚地瞭解他們需要做什麼，並避免了不必要地糾結這兩個組的工作流程。我們還將具有多個更改的請求拆分爲具有多個子項的父項，以允許我們更好地分配作業。這也有助於我們的測試團隊，因爲當管道發生重大變化時，會得到穩定的小變化流，而不會產生巨大的變化負擔。
爲您的問題添加一個標誌，指定需要文檔更新。讓技術作家訪問您的問題跟蹤系統，以便他們可以查看所有已標記的問題。如果他們不明白標記問題中提供的說明中需要更新哪些文檔，他們可以與負責解決問題的人員進行交談。
這是一個流程變更，您需要讓每個人都使用問題跟蹤系統瞭解這些問題，以便正確完成。
我認爲您的自定義字段方法應該可以正常工作，但我們傾向於使用子問題作爲運行我們的文檔工作流程的一種方式。本質上，它是這樣對我們來說，
當開發人員處理的問題，並確定新的文檔需要對這一問題進行書面的或現有的文檔需要更新（或甚至不能確定），他修復核心問題並創建與當前問題相關的子問題以完成文檔，並附有相關說明並將其分配給某人進行文檔編制。
負責文件的負責人解決了子問題，並通知了父母問題的受讓人他已完成。
開發人員或PM驗證一切正常並最終解決主要問題。
顯然，這只是另一種做事方式，有很多優點和缺點。以前，我們只是讓開發人員實施這個問題，對它進行評論（說「我已經解決了這個問題......」，將它重新分配給一位說「需要文檔」的作者。 docs and close issue。