我已经使用TRAC来跟踪软件开发的错误/问题，但对于典型的桌面用户来说似乎有点复杂。 是否有更好的（开放源码）使用起来比TRAC更简单， 针对的是最终用户 （而不是开发人员），也许是通过常见的场景来使用它们？
非软件： I在我们以前使用的工作场所，我们使用了OTRS（ http://otrs.org/ ）它是针对非开发环境（没有固定的构build，在构build中find等等..）。 我们设置它来validation我们的Windows AD。
我喜欢OTRS的是它可以整合到电子邮件和networking。 因此，用户可以通过电子邮件发送问题，打开票据，然后login到Web界面并将其回复到他们的电子邮件。 如果用户想要通过1/2的方式使用networking界面，他们可以…以及他们来回发送的所有内容都以笔记forms存储。 它对你和用户都是无缝的。
您也可以有“预先确定的答复”，这样您就可以通过电子邮件发送给用户，或者在票据中放入便条，而无需再次input所有内容。
OTRS还有一个常见问题解答部分，您可以在其中提供“如何解决”部分。 它也可以注册某些单词，并将它们自动放入不同的队列中。
软件：对于软件错误跟踪，（我现在的地方），我们使用螳螂BT。 我会说它非常容易使用和设置，我们对OpenLDAP服务器进行身份validation。
维基百科有问题跟踪系统的比较
在我目前的工作中，我们使用Redmine 。 我不知道这是否“简单”，但它对我们很好。
BugZilla似乎是一个stream行的select。
Bugzilla / Redmine的替代品是Mantis Bug Tracker 。
如果你的开发者正在使用Eclipse，你应该关注与Mylin的良好集成， Mylin是一个美妙的eclipse插件，可以直接从Eclipse访问你的错误，并将源代码链接到它们。
我知道Bugzilla和Jira（非常好，但不是开源）目前支持。
综述是相当不错的，并且可以通过一些Python知识来轻松地修改。
看看JIRA，对于服务台来说真的很好
我目前正在使用一家与“Bog Peak”进行问题跟踪的公司的产品。 我喜欢。 但不是开源的，所以它不能回答你的问题。
我没有什么可以从个人经验中推荐的，但我可以反对两个早期的build议：Bugzilla是非技术用户的噩梦 ，螳螂是一堆可用性失败。 根本不是一个粉丝。
我听说过关于Trac和Lighthouse的好消息 。 （尽pipeLighthouse并不具备开放资源的条件，但它确实提供了免费的select。）
如果你还没有放弃Trac的方法，你可能想看看http://trac-hacks.org/wiki/SimpleTicketPlugin隐藏一些现有的领域。 另请注意，如果您从多个字段中删除所有选项，它们将从UI中消失。
而且，使用Trac 0.11，我们有可configuration的工作stream程。 虽然大多数情况下用于将新状态添加到从“新build”到“closures”的票据path中，但可以将工作stream程减less到只有这两个状态。
跟踪者最多的问题之一就是他们一见钟情就把客户拉走了。 我强烈推荐Snowy Evening，因为它和其他function一样强大，但对于我的客户也非常容易使用：