使用 Trac 票证的严重性属性
我经常在工作团队中以及我自己的大学项目中使用 Trac。在这两种情况下，我从未觉得有必要使用票证的 severity 属性。我觉得通过使用 type 和 priority 属性可以提供我需要的所有信息，并且我想不出与 severity 属性有什么关系这并不多余。有人对 severity 属性有什么好的用例吗？
I use Trac regularly in a team at work, as well as for my own project for the university. In both cases I have never felt the need to use the severity property for a ticket. I feel that by using the type and priority properties gives all the information I need, and I cannot think of anything to do with the severity property that would not be redundant. Does anyone have any good usecases for the severity-property?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，这是一个老问题，但我想我会考虑一个非常不寻常但非常有用的用例。
背景：我实际上使用 Trac 系统来管理我的（现实）生活。例如，我创建诸如“在厨房安装智能灯”、“购买球赛门票”、“注射流感疫苗”等门票。这是因为我很不善于遵守时间表，但为自己制定一份整齐的任务和里程碑清单对我来说很有用。
无论如何，我使用“严重性”字段来指示我对该特定任务的焦虑程度。严重性级别范围从“no_problem”到“needs_concerted_effort”再到
“惊恐发作”。 （我大约有十几个，有些是特殊情况。）每当我有心情解决一些困难的事情时，我都会调出一份具有高优先级和严重性的票证报告；如果我感觉自己被生活打败了，只是想要一些简单的事情来分散我的注意力，我会调出一份高优先级、低严重性问题的报告。
另一个例子：虽然这不是最准确的用法，但在工作中我们使用严重性字段来指示我们预计任务需要多长时间。级别为“分钟”、“小时”、“天”、“周”和“月”。
Ok it's an old question but I guess I'll weigh in with a very unusual, but quite useful, use case.
Background: I actually use a Trac system to manage my (real) life. Like, I create tickets such as, "Install smart lights in kitchen", "Buy tickets to ball game", "Get flu shot", and so on. This is because I'm very bad at keeping to a schedule, but having a tidy list of tasks and milestones that I set out for myself works for me.
Anyway, I use the Severity field to indicate my anxiety level for that particular task. The severity levels range from "no_problem" to "needs_concerted_effort" to
"panic_attack". (I have about a dozen, and some are special cases.) Whenever I'm in a mood to tackle something hard I'll pull up a report of tickets with high priorty and severity; if I'm feeling defeated by life and just want something easy to take my mind off things, I'll pull up a report of high priority, low severity tickets.
Another example: though it's not quite the most accurate usage, at work we use the severity field to indicate how much time we expect the task to take. The levels are "minutes", "hours", "days", "weeks", and "months".
您可以将优先级和严重性视为正交值。
严重性可以表明错误的代价有多大：低严重性可能是“该图标的颜色错误”，高严重性可能是“计算机追捕并杀死用户”。
优先级是解决问题的紧迫程度。使用公司最大竞争对手的企业颜色的图标可能是高优先级，而百万年一次的致命错误可能是低优先级。
然后，您可以根据优先级乘以严重性来处理事情；中等严重性和中等优先级的事物可能比低严重性和高优先级的事物更重要。
或者
您可以让票证所有者控制严重性，让开发人员控制优先级。这为您提供了一种查看视图差异的方法，而无需对单个优先级字段进行编辑战争。但如果天真地这样做，用户就会简单地将严重性设置为他们可以设置的最大值，然后你就失去了该领域的所有用处。 （不，我不会假装有一个有用的、在现实世界中经过测试的解决方案。尽管有很多可能性可以使用。）
但老实说，高/中/的单一优先级字段在我的所有项目中，low 对我来说效果很好。单独的严重性字段似乎增加了复杂性，但带来的好处可以忽略不计。
披露：我是 Trac 开发人员之一
You can treat priority and severity as orthogonal values.
The severity can indicate how costly the bug is: low severity could be "the color of this icon is wrong" and a high severity could be "computer hunts down and kills user".
The priority is how urgent it is to fix the problem. An icon that uses the company's biggest competitor's corporate color may be high priority, whereas a deadly error that can happen once in a million years may be a low priority.
You can then work on things based on the priority times the severity; something that is medium severity and medium priority may be more important than something that is low severity and high priority.
OR
You can give the ticket owner control of the severity, and the developer control of priority. That gives you a way to see where views differ without having edit wars over the single priority field. But done naively, users will simply set the severity to the greatest value they can, and you lose all usefulness in that field. (And no, I don't pretend to have a useful, tested-in-the-real-world solution to that. There are lots of possibilities to play with though.)
But honestly, a single priority field of high/medium/low has worked well enough for me in all of my projects. A separate severity field just seems like additional complexity for negligible benefit.
Discloser: I'm one of the Trac devs