我意识到这不完全是一个编程问题，但它直接影响我们的开发人员和我们分配编写的代码。 如果还有另外一个类似SO的论坛，可以更好地发布，请告诉我，我将从这里提出问题并发布到那里。
我们的工作环境是几个开发人员为工厂生产场地和testing工作人员创build（20-30％）和维护（大部分份额）传统软件，以校准或testing公司销售的设备。 我们已经实现了一个非常简单的基于Google表单的错误报告页面，但是我们已经遇到了一些规模问题（大约40：1：我们和许多我们没有写的老旧的bug软件）。 在我到达之前，公司已经尝试过使用Bugzilla，但是工厂人员显然被它吓倒了，并且不会使用它。 但是，他们似乎喜欢简单的Google表单和类似向导的步骤来提交错误或请求function。 目前，我们正在从Google表单电子表格中手工剪切并粘贴错误/function请求到Trac中，并使用磁性错误卡手动跟踪白板上的错误/function请求。 这个系统只有几个星期的时间，它已经显示出它的脆弱性和缺乏可扩展性。
理想情况下，我们有一个Windows> = XP的Web或桌面客户端，可以提供：
我发现了“ Make Bugzilla Pretty ”比赛的优胜者，但是来自纯粹的软件公司，我们刚刚使用了直接的Bugzilla，我不清楚如何configuration和安装这些皮肤。 显然我可以搞清楚，但是如果不能解决我们的基本问题，那就是非技术性人员报告错误，就不想走这条路。
在Bugzilla维基网站上find的TaskCompiler看起来像是一个候选人，因为它与Bugzilla＆Trac都在谈论，但是他们的销售页面是离线的，自2012年以来该网站并没有更新，我不确定它们的可行性。
我敢肯定，我们不是第一个遇到这样的问题的生产设施，我正在寻求帮助解决我们的可扩展性和易用性问题的build议。
我想到的另一个想法是一个GAS脚本，将我们目前基于Google表单的错误报告推送到Trac或Bugzilla。
编辑： Bugzilla / Trac之间的决定似乎是为我们做的。 我正在探索在这里使用Trac的选项，如果你想跟随。
我没有Bugzilla / Trac的解决方案，但我可以建议一个替代方案：asitrack。
它专注于可用性，并为经理，开发人员和测试人员提供专用的用户界面。 安装起来非常简单，您可以通过将服务器和客户端安装在同一台计算机上进行快速测试。
启动它时，测试人员将看到一个简单的树形控件，其中包含项目，版本和问题。 在顶部有一个“创建问题”按钮和预定义的问题过滤器。 点击“创建发行”按钮，asitrack添加一个新的树项目，并在右侧显示一个编辑表单。