open-research
open-research copied to clipboard
X-lab2017
📚 用开源的方法来研究开源的现象。（open source methodology for open source phenomena）
> 好的 我今天尝试把学院学校大家的课程或者相关活动补充一下。这边还需要王老师补充下我们目标会议期刊的一些时间点。 @will-ww 嗯，好主意，这个任务交给我了~ _Originally posted by @will-ww in https://github.com/X-lab2017/open-wonderland/issues/30#issuecomment-1136691240_
随着 OpenResearch 项目的发展，开始陆续实践积累的一些流程和规范，我们可以让更多的同学加入进来进行日常的维护了。 我们可以参照《[开源社区治理与运营框架](https://github.com/X-lab2017/open-research/blob/main/Opendium/BizView.md#%E4%B8%80%E5%BC%80%E6%BA%90%E7%A4%BE%E5%8C%BA%E6%B2%BB%E7%90%86%E4%B8%8E%E8%BF%90%E8%90%A5)》构建一个简单体系~
最近处理github数据进行图模型构建遇见了不少问题： 1. 图数据规模过于巨大，vscode一个月的issue pr协作关系网络就有300多M的网络图模型数据。 2. 构建的图网络结构理应具有相似性质，可以通过相似矩阵或者谱方法进行验证。 目前还没有进行模型训练阶段，但是仅仅通过以上两点问题，我在思考是否有将大规模数据提出成小规模数据，保留其特征的一些方案。我认为可以提炼出一个科学问题。 想法来源于： 1. 复杂网络模型演化 2. 知识蒸馏（Knowledge Distilling）论文 Distilling the Knowledge in a Neural Network 3. 图结构特征 目前先将我的想法列出来，后续对这部分比较感兴趣，也可以用来解决数据集问题。进而有可能对OpenPerf产生指导性作用。
根据 05-18 日中期检查的报告内容，有如下建议： - 开题题目：**面向开源社区协作场景的多智能体协同机制研究**（后续修改优化） - 研究对象：开源项目/社区中的机器人（bot） - 研究视角：DevOps、项目管理、社区治理下的机器人自动化需求场景 - 研究问题：是否能够识别出 GitHub 上的协作机器人（bot）、进而进行角色特征判断、以及异常行为检测等工作 - 研究方法：GitHub 上的全域日志行为数据、利用机器学习、图算法、强化学习等技术进行求解 - 研究结果：能够对 Bot 进行准确分类；能够构建特征对 Bot 的角色进行识别；能够检测 Bot 的异常行为 - 实验设计：制作标准的全域开发者行为数据集（包括）、对 Bot 进行人工标注、对 Bot 的角色进行标注、对...
提出这个问题的场景： 在更加细致的协作网络构建中，交互关系不应仅仅是粗略的仓库或 Issue/PR 上的共现关系，而应该可以更加细致到具体每一次活动的关联关系。这些在行为日志中缺失的关联关系对于网络构建和后续任务其实有较大的意义。 例如在一个较长的 Issue/PR 中，一个新增 comment 具体是回复之前的哪条信息，常见的如： - 对于当前 Issue 本身内容的一种反馈 - 对于之前某个具体评论的回复，但可能是 quote reply，则文本中存在相关性。也可能仅仅是直接回复，此时可能需要通过上下文进行分析，看是否存在回复关系。 对于 PR review 则相对确定，因为对于 PR 的 review 是基于某个特定行（或几行）进行的，此时会导致新起一个 thread，那么多次 review comment 如果关联到一个 review...
提出该问题的场景： 在开发者协作网络构建中，我们经常使用共现关系对协作关系进行描述，但很多场景下，共现关系不一定表征正向的协作亲密度。在某些 Issue 或 PR 中，如果出现开发者之间的分歧，甚至争论。此时他们对彼此的价值评价事实上无法简单用共现的次数来表征。 问题： 对于 Issue/PR 中的评论，是否可以使用 NLP 进行情感分析，最简单的可以划分为正向/负向/无情感类型，即使如此简单的划分也可以在价值网络中对开发者之间的价值转移提供更好的判断依据。配合评论回复的关联分析，可以得出更加完善的价值网络。 数据： 可以考虑使用一些大型开源项目，或经常使用 GitHub reactions 的项目。在对具体评论内容进行情感分析后，也可以使用人工标注或直接使用 reactions 来进行验证。
- **Title**：**Sustainability Forecasting for Apache Incubator Projects** - **Author and affiliation**：UC-Davis, 浙江工业大学 - **Year**：2021 - **Conference or Journal**：[ESEC/FSE](https://2021.esec-fse.org/) - **Ranking**：[CCF A](https://www.ccf.org.cn/Academic_Evaluation/TCSE_SS_PDL/) - **Label**：[C03 项目孵化管理](https://github.com/X-lab2017/open-research/blob/main/Opendium/BizView.md#c03-%E9%A1%B9%E7%9B%AE%E5%AD%B5%E5%8C%96%E7%AE%A1%E7%90%86) - **Link**：[网络连接](https://dl.acm.org/doi/abs/10.1145/3468264.3468563)、[知识库链接](https://xlab2017.yuque.com/msdpvs/dtg7ew/25969959) - **Select reason**：开源基金会孵化场景和实验室研究高度相关、论文也提供了一套高质量的 Apache...
创新是学术论文的系统性要求，而绝大部分创新都是在新的场景和问题下，对旧事物的重新组合与发挥，即绝大多数的论文是一种微创新。 选题就是选择适合的研究指向，三个关键词：选择、适合、研究指向。 - **选择**：一篇规范的学术论文有四个基本要素：研究视角、研究对象、研究方法、研究结果。选择就是在这个四个要素框架下进行组合。 - **适合**：学术论文是对个人经验和思想的学术表达，结合自己实际的研究工作与情景，综合自己的兴趣与能力的合适选取。 - **研究指向**：选题阶段不追求精确性，而是把我整体结构要素的合理性，形成一个明确的问题目标，步骤可以包括”头脑风暴、文献定位、类比完善、可行性验证“，完成“从构思到研究指向再到研究选题“的过程。 下面是一个预开题的模板框架，帮助大家进行思考与迭代。 **1. 题目** 一个具体明确的题目是成功的一半 **2 研究视角** 视角的选取是创新的主要来源，由于研究问题的特殊性，产生不同视角下的问题抽象。这块最能体现研究者的功力与水平，但同时对研究者要求最高，需要丰富的经验与广博的学识。对于工程领域而言，视角的选取与工程技术的熟悉程度，以及工程实践的深度密切相关。 **3. 研究对象** 明确研究对象是选题中最核心的一个任务，也是后续其他任务的基础。广义来说，研究对象可以包括：人、物、事、理、模式。而对于工程技术来说，常见的包括：软件、服务、数据、算法、功能、流程等方面。 **4. 研究方法** 绝大多数的工程技术类研究主要是采用工程构建与量化分析的研究方法。为了解决某个具体的问题，提出一种方法或方案，通过实际系统的构建验证方法的有效性，其中找到恰当的评价手段来进行实验分析尤其重要。 **5. 研究结果** 对于大部分工程技术类题目来说，主要是实验结果，少数也可以是案例分析。重点是实验的设计、数据的获取与分析、以及结论分析等主要方面。 **6. 参考阅读** 相关领域的大量文献阅读必不可少，可以是正式的学术论文，也可以是参考书籍、文档、开源项目、技术博客、标准规范等。硕士开题一般不少于20篇深度阅读论文，博士则不少于40篇。 **选题6步法：** - 确定研究对象...
I wish to recommend a paper: Paper Title:Measuring the Popularity of Job Skills in Recruitment Market: A Multi-Criteria Approach Publish Year: 2018 Conference or Journal:AAAI Ranking:CCF A Classification or Keyword:...
https://github.com/X-lab2017/open-research/tree/main/OpenReading 论文分享流程逐渐完善。接下来，这两天我们把最后的分享笔记的发布跑通，大家看看怎么来比较合适？ - 统一为markdown文件（这个基本可以定） - 是否全文进入GitHub仓库，以及如何进入 - 如何从仓库，同步到不同媒体平台（公众号、微博、知乎等） 看大家觉得如何做，更合适~