在我工作的地方,我们一直在讨论FogBugz案件中应该包含哪些类型的信息。我在谈论创建新错误时在“打开方式”文本下面的大型自由文本字段,或者当您在现有案例上按“编辑”时。
例如,我们都同意错误的详细描述属于那里,当我们第一次创建错误时,我们通常会将该描述放入其中。但是在以后的编辑中,可以/应该放置哪些类型的信息?
我们并非都同意的最大问题是设计讨论是否属于那里。像这样:
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.
我们都同意A人所说的属于那里,但我们不确定B人和C人之间的对话是否也有意义。
其他公司做什么?对于那里有什么样的信息,是否有任何普遍接受的原则? FogBugz有更好的地方吗?或者是否有一个应该用于它的单独工具?
答案 0 :(得分:1)
对于FogBugz,我喜欢这里的项目:
这样做的好处是可以以最佳方式使用各种“格式”,并提供灵活的批次。如果你需要能够在事物之间来回链接,那么已经有一些插件可以使这很简单,编写自己的插件并不太难(无论是作为bugmonkey脚本还是完整的插件。)