问题标签 [issue-tracking]

正在为具有分布式团队的中型 Web 应用程序开放项目寻找问题跟踪器。我们计划在我们自己的服务器上运行它。新用户提交新问题必须非常容易，并且必须与其他软件很好地集成。

我们的主要要求，按重要性降序排列：

• 开源
• 能够非常新的用户友好的错误提交
  • 提交新问题必须尽可能简单，只需填写一个屏幕（注册后），并且可见的字段很少（例如“摘要”和“描述”会很好）
  • Google Code 就是我们喜欢的那种界面的一个例子；Bugzilla 的 Bugzilla 实例 (https://bugzilla.mozilla.org/enter_bug.cgi) 是我们不喜欢的那种新的错误提交界面的示例
  • 如果默认提交界面不是新用户友好的，那很好，只要使用模板/皮肤可以轻松修改即可。除了用于新用户错误提交的简单视图之外，如果有一个“高级视图”用于错误编辑以及其他字段（例如问题分配给谁），那就太好了
• 有API；或者，支持其他应用程序同时访问其数据库后端（我们希望从其他服务器上运行的其他独立软件查询和修改问题）

其他可取的标准，按重要性降序排列：

• 在日常使用中不会令人沮丧
• 有一个比较大的社区
• 与hg (mercurial)很好地集成
• 可与外部集成：
  • 支持台/请求跟踪软件
  • 项目管理软件
  • 身份验证系统（和/或支持 OpenID 登录）
• 模块化的; 如果我们修改问题跟踪器，我们希望将这些改进作为一个易于其他人安装的模块发布
• 适合拥有某种简单易用的问题重要性投票系统，例如 Google 代码上的星星；我们打算创建或修改这样一个组件以插入我们自己的外部投票系统
• 适合与 SugarCRM 集成

当我说“适合”时，我的意思是我们愿意在必要时自己编写问题跟踪器的扩展，但是，问题跟踪器的架构应该适合这种扩展。

如果我们可以选择集成外部软件而不是使用包含的东西，那么还包括支持台或项目管理功能的问题跟踪器是一个加分项。我们不需要另一个 wiki（我们已经有一个我们喜欢的）。

根据 Google 搜索（见评论），最流行的开源问题跟踪器是 trac、bugzilla、mantis、RT（可能还有 Launchpad）。我也将 Redmine 包括在内，因为我从未见过最近将这些问题跟踪器与 Redmine 进行比较，其中有人对 Redmine 有不好的评价，而在民意调查中，Redmine 有时会击败其他人。随意建议其他人（请记住，标准之一是“相对较大的社区”）。

毫无疑问，那里有多个好的问题跟踪器；上面列出的许多都声称可以与其他软件进行扩展和集成。最有帮助的是使用过多个问题跟踪器的人之间的直接比较。

这些在可扩展性、可集成性和可换肤性方面如何相互比较？

如果您使用过其中的一种以上，您会推荐其中的哪一种，以及您使用过哪些其他的？

其中哪些已经与大量身份验证系统/支持台系统/等集成？

非常欢迎评论解释为什么一个特别流行的开源问题跟踪器（尤其是上面列出的一个）不适合我们的情况；这将节省我的时间。

谢谢！

在 Jira 中，如果 QA 测试人员发现开发人员实现未发布功能的方式存在问题，他们是否应该将其记录为新错误？还是让他们将问题记录为评论并重新打开问题会更好？

如果他们将其作为对现有问题的评论输入，那么在使用时间跟踪功能时，我相信您会对实际实施该问题需要多长时间有更准确的印象。另一方面，如果您创建了新的错误，那么您可以跟踪开发人员出于质量改进目的而正在处理的问题数量中生成了多少错误。

每种方法的优缺点是什么？有没有办法实现我上面概述的两个好处？

我觉得我一定遗漏了一些东西，但是git 问题README 并没有说明如何自行安装。如何安装 git 问题？

我刚刚克隆了 git-issues，所以我使用的是最新的副本。

编辑：

所以我根据下面的答案“安装”了 git，但这就是发生的事情：

所以我不得不将 README.textile 重命名为 README，然后将其放入/usr/local/bin

对不起，但感觉好像发生了什么事。/usr/local/bin不应该有一个 README 文件。我在这里错过了什么吗？

编辑2：

即使在移动 README 文件后，也会git help issues返回No manual entry for git-issues. 我怎样才能让它也能正常工作？（现在我开始觉得自己像个大抱怨者:)）

编辑 3：

为什么“推送”功能也不起作用？我所做的只是将文件复制到 /usr/local/bin ，然后我还将相同的文件复制到 /usr/lib/git-core 以查看会发生什么。

是否有关于 Python 开发的问题跟踪器选择的讨论摘要？如果没有，您是否有此类讨论的链接？

我在一家公司工作，在那里我开发纯粹供内部使用的系统。只有少数开发人员，但我们使用 redmine 进行问题跟踪和功能请求。但是，唯一可以访问问题跟踪器的人是团队负责人，其他所有人都应该通过他们的团队负责人来提供他们的建议。

这个想法是，这将减少开发人员的工作量，并让管理层对正在开发的功能有更多的控制。现实情况是，我们会收到来自遇到小错误或功能请求的人直接发送给我们的电子邮件。

这是管理用户反馈的明智方法还是已知的不良做法？我还没有看到任何讨论管理内部问题跟踪的文章，所以我想问你。

像许多开源开发人员一样，我发现自己可能与几十个不同项目的问题跟踪器进行交互——有些是为了工作，有些是作为业余爱好者；有些经常，有些很少；有时报告错误，有时贡献补丁，有时关注影响我的其他人的错误报告，有时组织我自己的工作在我自己的项目中。

问题是，这项活动分散在网络上不同项目的不同网络应用程序（github、bitbucket、trac、bugzilla、mantis、jira ......）中，并且没有一个地方可以检查我正在尝试的问题的状态留在上面。

我想要一种仪表板类型的应用程序，我可以在其中浏览、搜索和排序（按更新日期、优先级等）分配给我的所有内容，或者我报告的任何错误，或者我正在关注更新的任何错误 - 涵盖所有项目 - 无需手动将所有这些问题重新输入仪表板：我只想向它提供一个指向其他跟踪器中现有问题的 URL，它会为我跟踪该问题的状态。

你几乎可以只用一个 RSS 提要阅读器就可以到达那里，除了真正有用的应用程序需要了解更多有关相关元数据的信息，以便你可以根据需要进行排序和过滤。

有没有人建造过这样的东西？如果它也提供写入功能，那么至少对于添加评论、标记已解决等常见任务来说是这样的。

我从来没有听说过这样的事情，我一直希望它。如果它不存在，我可能不得不对其进行破解。

我们目前正在使用 flyspray 作为 bugtracker，但它没有很多任务功能，尤其是没有任务的日历视图（只有截止日期任务以及必须完成任务的日期）。

有没有像谷歌日历这样的带有日历的 PHP 错误跟踪器？

你能推荐一个非常简单的问题跟踪小部件吗？UserVoice，对我们来说有点太参与他们的论坛了。我们想要的是只允许人们向我们发送问题或注释并获取 URL 的东西。

我对为什么会发生以下情况感到非常震惊：

这是我的代码：

结果如下：

我不明白为什么 x 会改变。

我的猜测：不知何故，x 是作为函数 add_one 的全局变量。我包括了'new_array = array'，这样如果array 是某种全局变量x，x 就不会改变。然而，当执行 'new_array = array' 时，不知何故 new_array 也变成了全局变量 x。我写了函数 add_one 的另一个版本，它没有给我带来问题：

似乎如果一个局部变量（即一个数组）通过它在函数中的索引进行编辑，那么它相对于作为该函数输入的全局变量变成全局变量？

我不知道发生了什么。任何解释将不胜感激。

我在 git 工作流模型上遇到了以下优秀的博文，该模型适用于发布、开发、功能和错误修复分支： http: //nvie.com/posts/a-successful-git-branching-model/

这听起来像是一个出色的工作流程，我真的很想在生产中尝试它，但有一段话引起了我的注意，让我感到疑惑。

正是在发布分支的开始，即将发布的版本被分配了一个版本号——而不是更早。在那之前，develop 分支反映了“下一个版本”的变化，但在发布分支启动之前，尚不清楚“下一个版本”最终会变成 0.3 还是 1.0。该决定是在发布分支开始时做出的，并由项目的版本号更新规则执行。

我想知道，这种工作方式如何反映在您的票务和错误跟踪系统中？在 JIRA 和 BugZilla 中，我们创建了工单可以属于的“版本”。在切换到发布分支之前，工单在开发分支中属于哪个版本？你的 issuetracker 中是否有每个分支的版本？

那么，您知道您不会在即将发布的版本中而是在之后的版本中实施的功能票呢？我应该为这种票创建一个“即将到来”和“未来”的版本吗？

任何有关此分支工作流程如何反映在工单/问题管理中的见解都值得赞赏！