我知道这不完全是一个编程问题，但它直接影响我们的开发人员和我们被分配编写的代码。如果有另一个类似 SO 的论坛可以更好地发布，请告诉我，我会从这里把问题记下来并在那里发布。
我们的工作环境是几个开发人员为工厂生产车间和测试工人创建（20-30%）和维护（大部分）遗留软件，用于校准或测试公司销售的设备。我们已经实现了一个非常简单的基于 Google 表单的错误报告页面，但我们已经遇到了规模问题（他们：我们大约 40:1 以及许多我们没有编写的老式错误软件）。在我来之前，公司已经尝试使用 Bugzilla，但收效甚微，工厂人员显然被它吓倒了，不会使用它。但是，他们似乎喜欢简单的 Google 表单和类似向导的步骤来提交错误或请求功能。我们目前正在手动将他们的错误/功能请求从 Google 表单电子表格中剪切并粘贴到 Trac 中，并使用磁性错误卡在白板上手动跟踪错误/功能请求。我们进入这个系统只有几周的时间，它已经显示出它的脆弱性和缺乏可扩展性。
理想情况下，我们应该有一个 Windows >= XP Web 或桌面客户端，它可以提供：
- 简化的错误报告，类似向导的方法似乎运作良好
- 可针对我们的软件包进行定制（例如每个软件包的下拉菜单）
- Bugzilla 或 Trac 集成
- 开发人员和管理层可以使用的标准错误跟踪功能
我找到了“ Make Bugzilla Pretty ”竞赛的获胜者，但是来自一个纯软件公司，我们只是直接使用开箱即用的 Bugzilla，我不清楚如何配置和安装这些皮肤。显然，我可以解决这个问题，但如果它不能解决我们的基本问题，即非技术人员报告错误，我不想走这条路。
在Bugzilla wiki 站点上找到的TaskCompiler似乎是一个候选者，因为它可以与 Bugzilla 和 Trac 对话，但是他们的销售页面处于离线状态，并且该站点自 2012 年以来没有更新，我不确定它们的可行性。
我确信我们不是第一个遇到此类问题的生产设施，我正在寻找建议来帮助解决我们的可扩展性和易用性问题。
我想到的另一个想法是使用 GAS 脚本将我们当前基于 Google 表单的错误报告推送到 Trac 或 Bugzilla。
编辑： Bugzilla/Trac 之间的决定似乎是为我们做出的。如果您想继续，我正在探索使用 Trac 的选项。