4

我知道这不完全是一个编程问题,但它直接影响我们的开发人员和我们被分配编写的代码。如果有另一个类似 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 的选项

4

0 回答 0