FogBugz案件應該包含哪些類型的信息？

我們一直在討論，在哪裏工作，關於什麼類型的信息應該在FogBugz案件的主體中。當您創建新的錯誤，或者當您在現有案例上推編輯時，我正在討論「Opened by」文本下的大型自由文本字段。FogBugz案件應該包含哪些類型的信息？

例如，我們都同意bug的詳細描述屬於那裏，我們通常會在第一次創建bug時加入該描述。但在稍後的編輯中，可以/應該在那裏放置哪些類型的信息？

我們並不都同意的最大問題是設計討論是否屬於那裏。事情是這樣的：

FEATURE 714 
    Opened by 'Person A' 
    We need to provide a user with the ability to quiggle-fy the doodad. 

    Edited by 'Person B' 
    Do you think this will involve changing the crabbadonk interface as well? 

    Edited by 'Person C' 
    No, the crabbadonk is already quiggle-fied.

我們都同意，什麼人甲說屬於那裏，但我們不能確定它是否有意義人B和人C之間的談話是在那裏。

其他公司做什麼？那裏有什麼樣的信息是否有普遍接受的原則？ FogBugz有更好的地方嗎？還是有一個單獨的工具應該用於它？

來源

2012-01-09 rbwhitaker

這將是如果你能重新說出這個問題，一般來說更適用於bug跟蹤軟件，因爲很多人使用的工具不是FogBugz。 – cdeszaq 2012-01-09 17:27:12

我曾考慮過這個問題，但我並不認爲這必然適用於其他錯誤跟蹤軟件。例如，在我以前的工作中，我們使用螳螂。螳螂有一個描述字段，然後記錄下來，我認爲這種東西屬於哪個更明顯。螳螂更多地區分了功能/錯誤描述和關於它的討論。但你可能是對的;還有一個更普遍的問題：「功能設計討論屬於錯誤跟蹤軟件嗎？」 – rbwhitaker 2012-01-09 17:36:04

我更想到Jira，Trac和Bugzilla，它們都有相同的大文本區域用於初始描述或評論。 – cdeszaq 2012-01-09 17:38:51

對於FogBugz的，這裏是我喜歡和我做的項目：

討論應該去討論板上
最終設計應該在維基去
任務落實設計應使案件

這在他們工作最好的方式使用各種「格式」的優勢，並且還提供了很多Ø靈活性。如果你需要能夠在不同事物之間來回連接，那麼已經有插件可以使這一切變得簡單，編寫自己的插件並不是太強悍（無論是作爲bugmonkey腳本還是全插件）。

來源

2012-01-09 17:50:56 cdeszaq

我理論上喜歡這個組織，但我們沒有討論板或wiki（是的，儘管FogBugz提供了一個wiki，但它完全沒有使用）。我也沒有影響力。但是，那麼，您是否遵守了「沒有設計討論進入錯誤/功能跟蹤軟件」的一般規則？ – rbwhitaker 2012-01-09 17:58:59

類別。這取決於手頭問題的範圍和規模。如果這是一件小事情，特別是單個設計師和單個開發者之間的一件事情，那麼我們可能會在案件本身中進行一些迭代，但一旦它不僅僅是一對夫婦或者超過一個特定的細節（例如。如果它可能影響多個特定案例），那麼它會在其他地方處理。 – cdeszaq 2012-01-09 18:28:34

FogBugz案件應該包含哪些類型的信息？

回答

相關問題