[学术会议] 关于系统开展学术会议交流的想法

[will-ww]

Description

和开源社区一样，学术会议是一个很好的实验室成果交流与展示平台，不仅对研究生培养/毕业提供了重要支持（如论文发表），近几年国际顶会所发展出来的各类丰富的 track，也能很好的用来宣传各类包括：工业界成果、工具、数据集、新想法、教学案例等成果，可以好好利用。

考虑实验室在 OpenRank、OpenDigger 等开源方向，以及软件工程、数据科学与工程等学科方向，列举部分会议及相关信息，欢迎大家一起来补充、提出好的建议想法。以下会议信息来源于 CCF。

1、软件工程

• ICSE（A）：10 月份投稿，Research、Industry、Demo、New idea、Education
• ASE（A）：5 月份，Research、Industry、Demo
• ESEC/FSE（A）：5 月份，Research、Industry、Demo、New idea
• ICSME（B）：7 月份，Research、Industry、Demo
• SANER（B）：10 月份，Research、Industry、Demo
• ESEM（B）：5 月份，Research、Industry、New idea、Empirical Studies
• MSR（C）：1 月份，Research、Industry、Demo、Datasets、Competetion
• SCAM（C）：7 月份，Research、Industry、Datasets、Reproducibility
• APSEC（C）：8 月份，Research、Industry、Education

2、数据科学与工程

• ICDE（A）：10 月份，Research、Industry、Demo、Special
• KDD（A）：2 月份，Research、Industry、Datasets、Demo、Competetion
• SIGIR（A）：1 月份，Research、Industry、Datasets、Demo、Reproducibility
• CIKM（B）：6 月份，Research、Industry、Datasets、Demo、Competetion
• DASFAA（B）：12 月份，Research、Industry、Demo

3、互联网与交叉学科

• WWW（A）：10 月份，Research、Industry、Demo、Datasets
• WINE（A）：7 月份，Research、Industry

[will-ww]

基于上述信息，可以鼓励并形成实验室传统：

• 博士生（#>=2）：以 A、B 类会议为主的 Research、Industry、New idea、Datasets 类别成果
• 硕士生（#>=1）：以 A、B、C 类会议为主的 Datasets、Demo、Competetion 类别成果
• 教师：以 A、B、C 类会议为主的 Education、Tutorial 类别成果

专利与软件著作权将作为非推荐类成果，除非有特殊考虑，不作为开源领域研究的主要成果。

[will-ww]

以 ICSE 2024 为例，能够投论文的 track 包括：

• Research Track：传统研究型论文
• Software Engineering in Practice：解决工业界相关的问题与挑战（Due：10-06，10 pages）
• New Ideas：新想法、新思想（Due：9-14，4 pages）
• Demonstrations：演示与工具（Due：10-23，4 pages）
• Software Engineering Education and Training：软件工程教育与培训的论文（Due：10-12，10 pages）
• Software Engineering in Society：解决软件工程在社会与跨学科中的问题（Due：9-28，10 pages）

同时，MSR 24 将会和 ICSE 2024 同时举办，会有不错的参会体验，值得参加~

[will-ww]

另一个值得关注的是 WWW 会议，明年在新加坡举行，定位为互联网跨学科研究的典范。

从 2023 年的 CFP 来看（Due 10 月），也是非常丰富的。

• Research Tracks
  • Crowdsourcing and Human Computation
  • Economics, Monetization, and Online Markets
  • Fairness, Accountability, Transparency, and Ethics on the Web
  • Search
  • Security, Privacy, and Trust
  • Semantics and Knowledge
  • Social Network Analysis and Graph Algorithms
  • Systems and Infrastructure for Web, Mobile Web, and Web of Things
  • User Modeling and Personalization
  • Web and Society
  • Web Mining and Content Analysis
• Special Track
  • Web4Good
  • History of the Web
  • The Creative Web
• Posters and Demos
• Industry

[PureNatural]

自然语言处理的顶会ACL中有一篇论文就是贡献了一个情感分析的数据集。

如果对方面级情感分析有一定了解的同学肯定对这个数据集不陌生，它是2014年发表的，到现在接近十年了还有学者在采用该数据集做一些实验等等，引用量特别大。

该数据集公开在这个网站中，其实数据量并不大，一共几千条，同时该网站针对该数据集也发布了四个子任务，每个任务细展开都可以较多研究。

我想参考一些现有自然语言标准数据集的构建方法，自己也构建一套关于开源评论文本的数据集，暂时还没想好具体方法，近期会尽可能的了解开源的评论文本，其中主要以commit、issue、PR这三类较为典型的评论为主，最后考虑如何去形成标准的数据集。

[will-ww]

该数据集公开在这个网站中，其实数据量并不大，一共几千条，同时该网站针对该数据集也发布了四个子任务，每个任务细展开都可以较多研究。

SemEval-2014 Task 4 是个不错的参考，以系统构建各类 Task 的形式推动数据集与科研问题，可以是个不错的方法~

[PureNatural]

近期搜刮了关于文本标准数据集构成以及开源领域情感分析的相关论文，说一下自己阅读以后产生的一些想法：

关于形成标准数据集：

我在阅读了SemEval-2014 Task 4、SemEval-2015 Task 12、SemEval-2016 Task 5、SemEval-2017 Task 4以及ImageNet之后认为形成标准数据集且需要形成论文进行发表的主要工作包含以下几点：

1.首先是获取数据，对数据进行标注。
论文中其实没有使用特别复杂的方法，确定自己想要的数据后选择数据源进行爬取，然后进行标注即可，在标注的过程中需要确定标注的流程，例如在SemEval-2014 Task 4中，选择一名研究生和一名语言学家进行标注，如果两者之间产生分歧，则需要第三名专家进行确定。这一点有点儿类似我之前做过的对项目类型进行标注.当然也可以先使用工具进行标注，再人工进行优化。

2.确定数据集可以完成的任务。
其实这一点是我读了这几篇文章之后才有所了解的，数据本身可以完成什么样的任务需要交代，而且一般都会形成不止一个子任务，当然如果只是作为分析类论文数据集的介绍那完全是够用的，但想要将数据集本身作为一篇论文发表，只有一个任务是支撑不起来一篇文章的，这样对数据集的形成就有一定的要求，不能简单的只是单独二分类问题或者实体识别问题，例如上述SemEval-2017 Task 4论文中，将推特评论文本情感分析分为三个子任务，其中包括二分类任务，三分类任务以及五分类任务。难度可以是层层递进的，但主要方向不能变，必须是情感分析。

3.数据集的评估标准
这一点在上面的论文中也有提到，但基本上都不是从数据的本身出发去验证数据的质量，他们都是将数据公开，让其他感兴趣的团队使用一些情感分析的方法（较多都是已经提出的或者相对传统的方法），使用数据完成训练和验证，最后使用F1或者Acc来衡量自己的方法。其中每一个任务大致有10个团队去使用。当他们的方法最后的F1值大部分都超过某一个基准时，则间接的证明了数据集的合理性。也就是说通过使用该数据集去训练后得到的模型最后的效果如果是不错的，则就可以证明该数据集的质量是相对不错的。这也是论文中工作量相对比较大的一部分。

[PureNatural]

关于开源评论文本的一些启发：

我在大致阅读了以上几篇论文后，对自己未来的工作产生了一些想法：

1.在开源领域对文本进行情感分析是有意义的，多篇论文都提到开发者的个人情感对项目未来的发展以及团队协作会产生影响，同时情感分析也可以称为观点挖掘，通过研究开发者的情感也可以了解开发者对项目某个方面的具体看法和观点。

2.我之前的想法是对整个项目所有的某一类评论做情感分析，但这样做确实太宽泛太大了，这样做也没有特别实际的意义。
现有的论文选择了一些项目具体的方面对评论做了情感分析，例如代码重构，项目的安全架构、核心文档等等，其中一篇文章就证明了在代码重构阶段，开发者的消极情绪占比是很高的。所以我们可以选择某一个落脚点，就是项目的某一个方面做分析，这样就是一个新的点。

3.在2021年ICSE(CCF-A)的顶会Understanding Emotions of Developer Community Towards Software Documentation这篇文章中，将开发者的情感分为了八类（anger, anticipation, disgust, fear, joy, sadness, surprise, trust），这样分类的合理性我觉得是有待商榷的，当然该文章本身的研究点很新，对文档的commit文本进行分析，所以对于方法的使用可能没有太讲究。该文章的THREATS TO VALIDITY这章写的很好（是我的话，可能我自己即使质疑自己的有效性，也不敢写这么全面）。他明确提出如果考虑其他的评论文本数据，类似issue、PR等，肯定分析出的结果会更全面。同时他们使用的情感分析工具也相对简单，使用更好的方法更有利于分析。

[PureNatural]

我们也许可以完成的工作：

基于以上我们应该可以形成两个方向，一个是数据集，一个是基于该数据集的详细分析，也对应两篇论文。（关于情感分类方法的研究可以产出更多）

关于数据集我现在的想法是我们可以从二分类（正、负）、三分类（正、中、负）、多分类（anger, anticipation, disgust, fear, joy, sadness, surprise, trust等，具体后续再定）入手，形成三个子任务，这三个任务也是开源领域有人做过一定研究的，我认为是有意义的。

在数据集获取之后，这两部分任务可以并行的完成，

围绕数据集的论文，则需要基于数据集使用大量现有的方法进行间接验证，如果该数据集有三个子任务，每个任务都有10个方法，则就相当于要完成30个实验，当然这只是个预估。SemEval-2014 Task 4本身具有影响力，所以较多团队会进行支持，我们可能需要自己完成这些实验，所以这部分工作也是不好预估的，难度相对于另一个工作较大。

围绕开源领域评论文本的工作，我现在产生的一个点子就是对上面那片论文出现的一些缺点进行完善，不只是某一个点的完善，是从数据集到分析方法到分析维度，多个方面进行优化，这样应该也可以形成一篇论文，为此我专门搜索了该文章的作者近期发表的论文以及引用该论文的其他论文是否有对其进行优化，确信这部分工作还是空白的，其他研究生们也可以对其中的研究方法进行不断的优化，最后产出论文，但这样做的最大的缺点就是还是没有从一个新的落脚点去出发研究，我想近期我会尽量找出一个新的比较有意思的关于开源领域值得做情感分析的一个方面再进行讨论。