我知道这不完全是一个编程问题，但它直接影响我们的开发人员和我们分配编写的代码。如果有另一个类似的论坛可以更好地发布这个问题，请告诉我，我会从这里记下这个问题并将其发布到那里。
我们的工作环境是几个开发人员为工厂生产车间创建（20-30%）和维护（大部分）遗留软件，并测试工人用于校准或测试公司销售的设备。我们已经实现了一个非常简单的基于 Google 表单的错误报告页面，但我们已经遇到了规模问题（大约 40:1 他们：我们以及许多我们没有编写的旧有错误的软件）。在我到来之前，该公司曾尝试使用 Bugzilla，但收效甚微，工厂人员显然被它吓倒了，不会使用它。然而，他们似乎喜欢简单的 Google 表单和类似向导的步骤来提交错误或请求功能。目前，我们正在手动将他们的错误/功能请求从 Google 表单电子表格剪切并粘贴到 Trac 中，并使用磁性错误卡在白板上手动跟踪错误/功能请求。我们只使用这个系统几周，它已经显示出它的脆弱性和缺乏可扩展性。
理想情况下，我们有一个 Windows >= XP Web 或桌面客户端，可以提供：
- 简化的错误报告，类似向导的方法似乎效果很好
- 可针对我们的软件包进行定制（例如每个软件包的下拉菜单）
- Bugzilla 或 Trac 集成
- 开发人员和管理层可以使用标准错误跟踪功能
我找到了“让 Bugzilla 变得漂亮 http://bugzillaupdate.wordpress.com/2011/03/31/winner-of-the-make-bugzilla-pretty-contest/“比赛，但来自一个纯粹的软件公司，我们只是直接使用开箱即用的 Bugzilla，我不清楚如何配置和安装这些皮肤。显然我可以弄清楚这一点，但不想走这条路如果它不能解决我们的基本问题，即非技术人员报告错误。
任务编译器 http://www.pluginedge.com/taskcompiler，发现于Bugzilla 维基站点 https://wiki.mozilla.org/Bugzilla:Addons#Desktop_Clients看起来像是一个候选者，因为它与 Bugzilla 和 Trac 都进行了对话，但他们的销售页面处于离线状态，并且该网站自 2012 年以来就没有更新过，我不确定他们的生存能力。
我确信我们不是第一个遇到此类问题的生产设施，我正在寻找建议来帮助解决我们的可扩展性和易用性问题。
我想到的另一个想法是使用 GAS 脚本将我们当前基于 Google 表单的错误报告推送到 Trac 或 Bugzilla 中。
Edit:Bugzilla/Trac 之间的决定似乎是为我们做出的。我正在探索使用 Trac 的选项here https://stackoverflow.com/questions/18024073/create-trac-ticket-from-google-form-gas-script如果你想跟随。
None
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
