@Brendan Long 相信我，当你让人们错误地认识到他们对项目有多少细粒度的控制时，情况可能会变得更糟。
So much of software development is managing clients and their expectations. Giving them write access to your bug database may suggest to them that they are now directing and in control of the project more than they actually are. Add to that the inevitable questions that will follow ("How do I do X/Y/Z?") and it's a massive headache waiting to happen.
I would consider read-only access but only if the client was technical enough and experienced enough with software development to understand how these tools are used. Otherwise I would stick with much lower-tech but much simpler todos-in-a-text-file, which I find myself using more often than not.
@Brendan Long trust me, it can get much worse when you give people a false perception about how much fine-grained control they have on a project.
At my company, we're struggling to get good problem descriptions in tickets from a technical audience (system administrators, technical consultants etc), and more often than not it takes inquiries from our professional helpdesk before an issue is layed out clear enough for a developer to work on.
Thus, from many years of experience, I would clearly advise against letting all your customers open tickets (unless you can narrow them down to a technical audience) because it will not save you any work compared to e-mails.
Read access is a good idea (because people will still feel much more involved) - you just have to make sure that you do not have too many tickets (usually low prio bugs or requests) that remain in the same state for a long time because this will start to frustrate the person who submitted it (better to close such a ticket in a timely manner if you can't or do not want to work on it, this kind of honesty if usually more appreciated than letting a ticket open for years ,-).
I used to communicate with a client via email and phone, and at some point I realized it was just too hard to keep track of things. I set up an account on Unfuddle (similar to Fogbugz but free), with just accounts for the two of us and it was immensely helpful.
When we first started, I did a lot of editing on new tickets, but it was still much better than keeping track of emails, and she figured out how to create tickets in the form I needed pretty quickly (I assume because now she can see how I keep track of what she's saying).
Anyway, if you're just using email now, it's not like it can get worse ;)
My experience (rather small, though) shows that allowing non-technical people to create tickets directly just won't work. You'll finish up editing those tickets yourself and constantly asking for details anyway. If I were you, I'd choose email for feedback and problem reporting.
However, it is a good idea to share existing tickets, read-only. Some people -- even non-technical ones -- are able to learn out of this how to create right tickets. Others would be happy to follow their particular problem while it's being solved.
发布评论
评论（4）
软件开发的大部分工作都是管理客户及其期望。授予他们对错误数据库的写入权限可能会向他们表明，他们现在对项目的指导和控制比实际情况要多。再加上随之而来的不可避免的问题（“我该如何做 X/Y/Z？”），这将是一个令人头疼的问题。
我会考虑只读访问，但前提是客户拥有足够的技术和足够的软件开发经验，能够了解如何使用这些工具。否则，我会坚持使用技术含量低得多但简单得多的文本文件中的待办事项，我发现自己经常使用它。
@Brendan Long 相信我，当你让人们错误地认识到他们对项目有多少细粒度的控制时，情况可能会变得更糟。
So much of software development is managing clients and their expectations. Giving them write access to your bug database may suggest to them that they are now directing and in control of the project more than they actually are. Add to that the inevitable questions that will follow ("How do I do X/Y/Z?") and it's a massive headache waiting to happen.
I would consider read-only access but only if the client was technical enough and experienced enough with software development to understand how these tools are used. Otherwise I would stick with much lower-tech but much simpler todos-in-a-text-file, which I find myself using more often than not.
@Brendan Long trust me, it can get much worse when you give people a false perception about how much fine-grained control they have on a project.
在我的公司，我们正在努力从技术受众（系统管理员、技术顾问等）那里获得良好的问题描述，并且通常需要向我们的专业服务台询问，然后才能将问题摆得足够清晰，以便解决问题。开发人员进行工作。
因此，根据多年的经验，我明确建议不要让所有客户开票（除非您可以将范围缩小到技术受众），因为与电子邮件相比，它不会为您节省任何工作。
读取访问是一个好主意（因为人们仍然会感觉更多地参与其中） - 您只需要确保您没有太多的票证（通常是低优先级错误或请求）长时间保持在同一状态，因为这会让提交它的人感到沮丧（如果你不能或不想处理它，最好及时关闭这样的票证，这种诚实通常比让票证打开多年更受欢迎,-)。
At my company, we're struggling to get good problem descriptions in tickets from a technical audience (system administrators, technical consultants etc), and more often than not it takes inquiries from our professional helpdesk before an issue is layed out clear enough for a developer to work on.
Thus, from many years of experience, I would clearly advise against letting all your customers open tickets (unless you can narrow them down to a technical audience) because it will not save you any work compared to e-mails.
Read access is a good idea (because people will still feel much more involved) - you just have to make sure that you do not have too many tickets (usually low prio bugs or requests) that remain in the same state for a long time because this will start to frustrate the person who submitted it (better to close such a ticket in a timely manner if you can't or do not want to work on it, this kind of honesty if usually more appreciated than letting a ticket open for years ,-).
我曾经通过电子邮件和电话与客户沟通，在某些时候我意识到跟踪事情太难了。我在 Unfuddle 上建立了一个帐户（类似于 Fogbugz，但免费），只有我们两个人的帐户，这非常有帮助。
当我们刚开始时，我对新票证进行了大量编辑，但这仍然比跟踪电子邮件要好得多，而且她很快就弄清楚了如何以我需要的形式创建票证（我想是因为现在她可以看到我如何跟踪她所说的话）。
不管怎样，如果你现在只使用电子邮件，情况不会变得更糟;)
I used to communicate with a client via email and phone, and at some point I realized it was just too hard to keep track of things. I set up an account on Unfuddle (similar to Fogbugz but free), with just accounts for the two of us and it was immensely helpful.
When we first started, I did a lot of editing on new tickets, but it was still much better than keeping track of emails, and she figured out how to create tickets in the form I needed pretty quickly (I assume because now she can see how I keep track of what she's saying).
Anyway, if you're just using email now, it's not like it can get worse ;)
我的经验（虽然相当少）表明，允许非技术人员直接创建票证是行不通的。您将自己编辑这些票证并不断询问详细信息。如果我是您，我会选择通过电子邮件进行反馈和问题报告。
然而，共享现有的只读票证是个好主意。有些人——甚至是非技术人员——能够从中学习如何创建正确的票证。其他人会很乐意在解决他们的特定问题时关注该问题。
My experience (rather small, though) shows that allowing non-technical people to create tickets directly just won't work. You'll finish up editing those tickets yourself and constantly asking for details anyway. If I were you, I'd choose email for feedback and problem reporting.
However, it is a good idea to share existing tickets, read-only. Some people -- even non-technical ones -- are able to learn out of this how to create right tickets. Others would be happy to follow their particular problem while it's being solved.