我来自编程背景。我现在正在学习分析。我正在学习从基本统计到模型构建的概念，如线性回归、逻辑回归、时间序列分析等，
由于我之前的经验完全是编程，我想对程序员的数据做一些分析。
说，让我们有下面的详细信息（我正在使用 SVN 存储库）
人名、代码签入日期、文件签入、签入次数、分支、签入日期和时间、构建版本、缺陷数量、缺陷日期、有缺陷的文件、构建版本、缺陷修复日期、缺陷修复时间，（请随意添加/删除需要多少变量）
我只需要一个关于可以用这些数据做什么的触发器/起点。我可以用这些数据带来任何见解吗？
或者您能否提供任何链接，其中包含有关已完成类似工作类型的信息。
肯定 - 是的。好问题。我自己也在考虑。
(1) 收集数据。您遇到的第一个问题：收集足够的数据。您提到的所有属性（日期、姓名、签到标题/评论、N 个影响等）都可能有用 - 尽可能多地收集。一旦你有一个大项目、许多开发人员、许多分支、频繁提交并且你已经开始收集所有数据，你就准备好更进一步了。
(2) 提出好的问题。您应该问自己的下一个问题：您要测量、估计甚至预测什么效果。可能的错误的频率？跟踪不准确的“提交者”？有风险的分支？想根据某些指标查看某些用户/错误/提交组吗？
(3) 选择型号。一旦你提出了问题，你应该遵循数据科学中的一般方法——在数据中提取所需的特征，选择合适的模型，训练你的模型并对其进行测试，然后应用它。这个过程太宽泛了，无法在这个线程中讨论，所以请使用这个站点来获得正确的答案。
毫无疑问，你可以。关键是要有一组假设（即假设\您想要评估的场景）并将数据整理在一起以证明\反驳您认为是正确的。
这里有几点需要注意：
为失望做好准备：通常，一旦您投入时间和精力来构建这些模型，分析师往往会偏向于发布结果（发布偏差）。将其视为具有很多死胡同的探索，目标应该是找到没有死胡同的探索。
了解你的数据：如果没有真正了解它，你就无法将你的数据神奇地用于做事。确保您非常了解不同的属性（预测变量和从属变量）。充分了解您的数据将使您能够清理它并考虑适当的模型。并非所有模型都适用于所有数据 - 具有大量分类变量的数据可能需要像降维这样的创造性解决方案才能对其进行建模。
了解“运营”流程：了解公司内部的运作方式将帮助您完善要检验的假设集。例如，在您的上述场景中，了解开发人员如何使用您的变更管理软件以及已完成哪些类型的管理设置将帮助您弄清楚数据为何以这种方式出现。一些开发人员可能只专注于某些比其他模块更成熟的模块，可能只在某些班次上工作，这可能会限制签入的代码行数、发现的错误数量等。
话虽如此，这里有一些您可能想要测试的场景：
开发人员效率：不同开发人员加班处理相同模块如何导致错误增加或减少。更多的代码行会导致更多的错误吗？也许这可能表明程序需要进一步拆分为更小的组件 人们可能在一天中的某些时间比其他时间更有效率 - 一天中的时间会影响错误介绍吗？
模块成熟度：哪些模块的问题最多？它们是由更多的开发人员还是更少的开发人员来工作的？缺陷在修复之前会长期老化吗？
当然，这些问题会根据您的工作而改变。
希望这可以帮助。
这是我正在考虑的两个想法。
根据之前的活动，可以预测未来的错误。网上有很多论文。我记得有一篇关于从 SVN 数据预测错误的论文。（只是谷歌软件错误预测）
错误可能类似于跟踪输出中的罕见事件或异常。可能您可以对错误进行分类并查明导致错误的过程。我目前正在考虑这样的系统（虽然不确定它的成功）。我在这里问了一个问题：https ://stats.stackexchange.com/questions/140232/error-position-in-software-trace-file
由于您也在寻找示例，因此 github 是查看的好地方。
我拿了一个随机存储库并转到右侧的“图表”，打开了贡献频率图。它旁边有几个选项卡，以图形方式显示存储库的其他方面和提交历史 - 提交、代码频率、穿孔卡片等。