OOPSLA 2020的工件评估已完成。请在中查看结果主席报告.

帮助别人在你论文的贡献上再接再厉！

人工制品评估过程是由社区提供的一项服务，旨在帮助已被接受论文的作者为其论文提供更多实质性的补充，以便未来的研究人员能够更有效地借鉴和比较以前的工作。

通过PACMPL（OOPSLA）第一轮考试的论文作者将被邀请提交支持其论文结论的工件。AEC将阅读该论文并探索该人工制品，以反馈该人工制品对论文的支持程度以及未来研究人员使用该人工制品的容易程度。

此提交是自愿的。成功通过工件评估流程的论文将在论文的第一页上获得批准印章。鼓励论文作者在论文发表后公开这些材料，将其作为“源材料”纳入ACM数字图书馆。

有关更多信息，请参阅“调用工件”选项卡。

为了达到更广泛的审查受众，我们也接受工件审查的自我提名。有关详细信息，请参阅“要求自我提名”选项卡。

人工产品

	职务
	为文本代码添加交互式视觉语法 OOPSLA工件 莱夫·安徒生,迈克尔·巴伦蒂恩,马提亚斯·费莱森 内政部
	构建规范中的故障检测模型 OOPSLA工件 Sotiropoulos臭鼬,斯特凡诺斯·查利亚索斯,迪米特里斯·米特罗普洛斯,Diomidis Spinellis公司 内政部
	上下文代码更改的结构模型 OOPSLA工件 摇晃的布罗迪,乌里·阿隆,埃兰·雅哈 内政部预打印
	对象初始化的类型和效果系统 OOPSLA工件 刘凤云,Ondřej Lhoták,阿格洛斯·比布迪斯,保罗·贾鲁索,马丁·奥德斯基
	CAMP：具有成本意识的多方会话协议 OOPSLA工件 大卫·卡斯特罗·佩雷斯,吉田信子 内政部
	高级类型系统可以使用吗？黑曜石所有权、资产和类型状态的实证研究 OOPSLA工件 迈克尔·科布伦兹,乔纳森·奥尔德里奇,布拉德·迈尔斯,约书亚阳光 内政部
	经认证的高效指令调度及其在联锁VLIW处理器上的应用 OOPSLA工件 西里尔六号,西尔万·博尔梅,大卫·莫尼奥
	CompCertELF：验证了将C程序单独编译为ELF对象文件 OOPSLA工件 王玉亭,徐香泽,皮埃尔·威尔克,钟绍
	功能专业化的上下文调度 OOPSLA工件 奥利维尔·弗吕基格,吉多·查里,明浩义,扬·杰克曼,雅各布·海恩,扬·维泰克 内政部
	用于翻译验证的反例引导相关算法 OOPSLA工件 舒巴尼·古普塔,阿披舍克玫瑰,索拉夫·班萨尔
	从经验上为R设计类型 OOPSLA工件 阿列克西·图尔科特,阿维拉尔·戈尔,菲利普·Kř伊卡瓦,扬·维泰克 内政部
	检测受中断库更改影响的JavaScript程序中的位置 OOPSLA工件 安德斯·默勒,本杰明·巴斯列夫·尼尔森,马丁·托尔达姆·托尔普
	DiffStream：流处理程序的差异输出测试 OOPSLA工件 康斯坦蒂诺斯·卡拉斯,菲利普·尼基奇,卡勒布·斯坦福,拉杰夫·阿鲁尔 内政部
	挖掘折叠：Haskell的合成辅助API发现 OOPSLA工件 迈克尔·B·詹姆斯,郑国,王子腾,希瓦尼·多西,希拉·佩莱格,兰吉特·贾拉,纳迪娅·波里卡波娃
	DOT:具有对象初始化的DOT演算 OOPSLA工件 伊法兹·卡比尔,李玉凤,Ondřej Lhoták 内政部
	你有放甜品的地方吗？CakeML程序的验证空间代价语义 OOPSLA工件 亚历杭德罗·戈梅斯·隆多尼奥,约翰内斯·奥曼·波霍拉,Hira Taqdees Syeda公司,马格努斯·奥·米林,Yong Kiam Tan先生
	作为能力的效果：效果处理者和轻量效果多态性 OOPSLA工件 Jonathan Immanuel Brachthä用户,菲利普·舒斯特,克劳斯·奥斯特曼
	使用提前程序优化消除Java流管道的抽象开销 OOPSLA工件 安德斯·默勒,奥斯卡·哈克卢·维勒堡
	羽量级选手出发 OOPSLA工件 罗伯特·格瑞史莫,雷蒙德·胡,文科克,朱利安·兰格,伊恩·兰斯·泰勒,贝尔纳多·托尼尼奥,菲利普·沃德勒,吉田信子 内政部
	通过查询分区查找数据库系统中的错误 OOPSLA工件 曼努埃尔起重工,苏振东 内政部
	Formulog：基于SMT的静态分析的数据日志 OOPSLA工件 亚伦·本比内克,格林堡,斯蒂芬·庄（Stephen Chong） 内政部
	图形编程的几何类型 OOPSLA工件 迪特里希·盖斯勒,艾琳·尹,阿迪蒂·卡布拉,贺贺拉斯,尹农·桑德斯,阿德里安·桑普森 内政部
	引导链接：无成本的动态链接 OOPSLA工件 肖恩·巴特尔,威尔·迪茨,维克拉姆·S·阿德 内政部
	处理双向控制流 OOPSLA工件 张益洲,吉多·萨尔瓦内奇,安德鲁·迈尔斯
	隐藏继承：一种用于TypeScript性能的内联缓存设计 OOPSLA工件 吴哲峰,孙哲,启公,陈凌云,廖斌（Bin Liao）,金一华
	Igloo：用于分布式系统验证的合理连接的成分细化和分离逻辑 OOPSLA工件 克里斯托夫·斯普伦格,托比亚斯·克伦泽,马可·艾尔斯,费利克斯·A·沃尔夫,彼得·米勒,马丁·克洛查德,大卫盆地 内政部
	基于实例和自然语言的时间规范交互合成 OOPSLA工件 伊凡·加夫兰,伊娃·达鲁洛娃,鲁帕克·马朱姆达尔
	SMT字符串解算器的理论间依赖性分析 OOPSLA工件 闽泰Trinh,朱棣文公爵,Joxan Jaffar公司
	归纳程序综合的实时学习 OOPSLA工件 什拉达·巴克,希拉·佩莱,纳迪娅·波里卡波娃 内政部
	知道何时提问：人工制品 OOPSLA工件 阿詹·鲁沃特（Arjen Rouvoet）,亨德里克·范安特卫彭,卡斯珀·巴赫·鲍尔森,罗伯特·克雷伯斯,埃尔科·维瑟 内政部
	基于学习的受控并发测试 OOPSLA工件 苏瓦姆·穆克吉,德利吉安人,阿皮塔·比斯瓦斯,阿卡什·拉尔 内政部
	学习基于图形的启发式，无需手工创建应用程序特定功能即可进行指针分析 OOPSLA工件 Minseok Jeon公司,Myungho Lee（李明浩）,Hakjoo噢 内政部
	域特定语言的宏 OOPSLA工件 迈克尔·巴兰坦,亚历克西斯·金,马提亚斯·费莱森 内政部
	多方运动协调：从舞蹈到机器人程序 OOPSLA工件 鲁帕克·马朱姆达尔,吉田信子,达米安·祖弗里 内政部
	神经网络的完全并行公平性证明 OOPSLA工件 Caterina城市,玛丽亚·克里斯塔基斯,瓦伦丁·瓦斯特霍尔茨（Valentin Wüstholz）,张福源 内政部
	测量类型表示单位的精确推断 OOPSLA工件 桐桐香,杰夫·罗,沃纳·迪特尔 内政部
	以太坊“内存”的精确静态建模 OOPSLA工件 西菲斯·拉古瓦尔多斯,内维尔·格雷奇,伊利亚斯·萨提利斯,亚尼斯·斯马拉格达基斯 内政部
	具有部分可观测性的程序设计与推理 OOPSLA工件 埃里克·阿特金森,迈克尔·卡宾 内政部
	使用Read-Eval-Synth循环进行编程 OOPSLA工件 希拉·佩莱,罗伊·加贝,沙查尔·伊扎基,埃兰·雅哈 内政部
	用于测试和调试量子程序的基于投影的运行时断言 OOPSLA工件 李古书,李周,俞能坤,丁宇飞,明生英,袁燮
	Regex与计数集自动机的匹配 OOPSLA工件 Lenka Turoňová,卢卡什·霍利克,Ondřej Lengál,奥利·萨里基维,玛格斯·维恩斯,托马什·沃伊纳尔 内政部
	通过Modus Ponens分解为交叉口子类型 OOPSLA工件 科尔·马尔蒂罗西安,汤姆·施里杰弗斯,布鲁诺·C·d·S·奥利维拉,乔治奥斯·卡拉查利亚斯 内政部
	重新访问等渗子类型 OOPSLA工件 周耀达,布鲁诺·C·d·S·奥利维拉,赵金旭 内政部
	离散概率程序的尺度精确推理 OOPSLA工件 史蒂文·霍尔岑,盖·范登·布勒克,托德·米尔斯坦 内政部
	多方协议的静态验证改进 OOPSLA工件 周方一,费雷拉,雷蒙德·胡,鲁米亚纳·内科娃,吉田信子 内政部
	StreamQL：一种用于处理流式时间序列的查询语言 OOPSLA工件 凌坤·孔,康斯坦蒂诺斯·马穆拉斯
	使用双重口译员测试差异隐私 OOPSLA工件 张恒初,埃多·罗斯,安德烈亚斯·海伯伦,本杰明·皮尔斯,亚伦·罗斯 内政部
	阻塞和非阻塞并发软件的锚验证程序 OOPSLA工件 斯蒂芬·弗伦德,科马克·弗拉纳根 内政部
	在Liquid Haskell中使用类型类优化验证复制的数据类型 OOPSLA工件 刘依云,詹姆斯·帕克,帕特里克·雷德蒙德,林赛·库珀,迈克尔·希克斯,尼基·瓦祖

要求人工制品

帮助别人在你论文的贡献上再接再厉！

人工制品评估过程是由社区提供的一项服务，旨在帮助已被接受论文的作者为其论文提供更多实质性的补充，以便未来的研究人员能够更有效地借鉴和比较以前的工作。

通过PACMPL（OOPSLA）第一轮考试的论文作者将被邀请提交支持其论文结论的工件。AEC将阅读该论文并探索该人工制品，以反馈该人工制品对论文的支持程度以及未来研究人员使用该人工制品的容易程度。

此提交是自愿的。成功通过人工制品评估流程的论文将收到印在论文第一页上的批准印章。鼓励具有公认人工制品的论文作者在论文发表后将这些材料作为“原始材料”纳入ACM数字图书馆，以供公众使用。

重要日期

• 8月8日：第一阶段接受论文的作者提交了人工制品
• 8月15日至18日：作者可能会对以下即兴指令中发现的问题作出回应
• 9月15日：发出人工制品通知

选择标准

根据论文设定的期望对工件进行评估。要使工件被接受，它必须支持论文中提出的所有主要主张。因此，除了运行工件外，评估人员还将阅读论文，并可能尝试调整提供的输入，或以其他方式稍微概括论文中工件的使用，以测试工件的限制。

工件应为：

• 一致的用纸，
• 作为完成尽可能，
• 另外其文档也很齐全、和
• 易于重复使用，促进进一步研究。

AEC努力站在这些未来研究者的立场上，然后问：这个人工制品对我有多大帮助？请参阅工件评估（徽章）结果的详细信息，以获得关于这些含义的进一步指导。

提交过程

所有通过OOPSLA审查第一阶段的论文都有资格提交工件。

您的提交应包括三部分：

1. 您的工件概述，
2. 指向以下任一项的URL：

• 包含工件的单个文件（推荐），或
• 公共源代码管理存储库的地址

1. 在提交时验证工件版本的散列：或者

• 单个文件的md5散列（使用md5或md5sum命令行工具生成散列），或
• 这个满的提交的散列（例如，来自git重新登录--无bbrev)

URL必须是Google Drive、Dropbox、Github、Bitbucket或（公共）Gitlab URL，以帮助保护审阅者的匿名性。如果你的工件是一个小于15MB的文件，你可以直接上传。

人工制品确实如此不需要匿名；评论员将了解作者身份。

工件概述

概述应包括两部分：

• 入门指南和
• 关于如何评估工件的分步说明（与论文的相关部分有适当的联系）；

这个入门指南应该包含设置说明（例如，包括指向VM播放器软件的指针、其版本、密码（如果需要）等）和工件的基本测试，您希望审阅者能够在30分钟内完成这些测试。审查人员将在初始启动阶段遵循指南中的所有步骤。《入门指南》应该尽可能简单，但它应该强调工件的关键元素。遵循《入门指南》的任何人都应该对您的工件的其余部分没有技术困难。

这个分步说明解释如何重现支持论文结论的任何实验或其他活动。为那些对你的工作有浓厚兴趣并正在研究它以改进它或与之比较的读者写下这篇文章。如果你的工件运行了几分钟以上，请指出这一点，注意它预计运行多长时间（大致），并解释如何在较小的输入上运行它。根据可用的硬件，审查人员可以选择在较小的输入或较大的输入上运行。

在适当的情况下，包括对代表预期输出的文件（包括在档案中）的描述和链接（例如，预期由您的工具根据给定输入生成的日志文件）；如果有可以安全忽略的警告，请说明是哪些警告。

工件的文档应包括以下内容：

• 工件支持的论文中的声明列表，以及如何/为什么。
• 报纸上的索赔清单不由工件支持，为什么不支持。

例如：性能声明不能在虚拟机中复制，作者不允许重新发布特定基准等。然后，工件评审员可以围绕这些特定声明进行评审/评估，尽管评审员仍会考虑所提供的证据是否足以支持工件工作的声明。

包装工件

在包装您的工件时，请记住：a）您使其他研究人员能够多容易地访问您的工件，以及b）AEC成员对每个工件进行评估的时间有限。

您的工件可以包含一个安装了所有必要库的可引导虚拟机映像。使用虚拟机提供了一种创建易于复制的环境的方法，它不太容易发生比特腐烂。这也有助于AEC确信错误或其他问题不会对其机器造成伤害。建议这样做。

允许提交必须编译的源代码。更自动化和/或可移植的构建-例如Docker文件或管理所有编译和依赖项的构建工具（例如。，马文,梯度提高了AEC在不同版本的软件包（尤其是不同版本的编程语言）工作时不受阻碍的可能性。

提交经机器检验的人工制品的作者应咨询Marianna Rapoport证明工件：提交和审查指南.

您应该将工件作为单个存档文件提供，并使用命名约定<论文#><后缀>，其中适当的后缀用于给定的存档格式。请使用广泛可用的压缩存档格式，如ZIP（.ZIP）、tar和gzip（.tgz）或tar和bzip2（.tbz2）。请使用打开的文档格式。

基于OOPSLA 2019 AEC，为确保包装质量，我们可以给出的最强烈建议是在一台新机器（或VM）上测试您自己的指示，严格遵循您准备的指示。

虽然公开可用的工件通常更容易审查，并且被认为符合开放科学的最佳利益，但工件不需要公开和/或开源。工件评审员将被指示，工件仅用于工件评估，提交的工件版本可能不会被评审员公开，工件的副本不得保存在评审期之后。有一个额外的徽章专门用于在可靠的位置提供工件（见下文），我们强烈地鼓励已接受工件的作者追求它，但这是一个独立于功能评估的过程，并且不是必需的。

徽章

工件评估委员会对每个工件进行评估，以获得一个或两个徽章：

功能：这是工件的基本“可接受”结果。如果工件支持论文中的所有声明，则可以授予工件功能徽章，如果有很好的理由无法支持，则可能排除一些次要声明。在理想情况下，具有此名称的工件包括所有相关代码、依赖项、输入数据（例如基准），并且工件的文档足以让审阅者重现本文中描述的准确结果。如果工件声称在某些方面（在时间、准确性等方面）优于相关系统，而另一个系统用于为论文生成新的数字（例如，现有工具是在相应出版物未考虑的新基准上运行的），则工件应包括该相关系统的一个版本，以及复制用于比较的数字的说明。如果替代工具在输入子集上崩溃，只需注意此预期行为。

偏离这一理想必须有充分的理由。合理偏差的非决定性列表包括：

• 一些基准代码受到许可或知识产权限制，无法合法地与审查人员共享（例如，SPEC等许可的基准套件，或当工具应用于私有代码时）。在这种情况下，应包括所有可用的基准。如果全部的本文中的基准数据属于这种情况，应该提供替代数据：提供一个没有可供评估的有意义输入的工具不足以证明工件有效。
• 一些结果是性能数据，因此确切的数字取决于特定的硬件。在这种情况下，工件应该解释如何识别在其他硬件上的实验何时再现高级结果（例如，某个优化显示了特定的趋势，或者在特定类别的情况下比较两个工具中一个优于另一个）。
• 在某些情况下，重复评估可能需要很长时间。在这种情况下，审核人可能无法复制完整结果

在某些情况下，工件可能需要专用硬件（例如，具有特定新功能的CPU，或特定类别的GPU，或GPU集群）。对于此类情况，作者应联系工件评估Co-Chairs(科林·戈登和安德斯·默勒)在第一轮通知后，尽快制定出如何进行评估。过去几年的一个结果是，一个需要专用硬件的工件用硬件支付了云实例的费用，审核者可以远程访问。

可重复使用的：此徽章只能授予被判定的工件功能性的。当审查人员认为工件包装、记录、设计等特别好时，就会授予可重用徽章，以支持可能基于工件的未来研究。例如，如果其他人似乎比较容易将其直接重用为后续项目的基础，AEC可能会授予可重用徽章。

给出一个或两个功能性和可重用徽章的工件通常被称为认可的.

在对功能性和可重复使用的徽章作出决定后，AEC主席可以向那些可接受的、使其制品持久可用的制品授予额外徽章：

可用：此徽章只能颁发给被判定的工件功能性的。此徽章用于公开提供的已接受工件在存档位置。去年接受了上传的工件评估版本到泽诺多并将AEC椅子发送给DOI（验收后），DOI自动收到此徽章。Github等不足以接收此徽章（请参阅常见问题解答）。

COI公司

AEC成员的利益冲突由主席处理。涉及两个AEC主席之一的利益冲突由另一位AEC主席处理，如果两个主席冲突，则由会议的PC处理。涉及AEC椅子的工件必须被明确接受（它们可能没有边界），并且可能不会被考虑授予杰出工件奖。

常见问题解答

随着时间的推移，此列表将更新有用的问题。

我的工件需要数百GB的RAM/数百个CPU小时/专用GPU等，AEC成员可能会没有访问权限。我们如何提交工件？

如果该工具可以在普通现代机器上运行，但与用于论文评估的硬件，请在您的并举例说明AEC可能能够在更短的时间内进行复制。如果您的系统在没有数百GB或RAM或其他硬件的情况下根本无法工作大多数典型的研究生机器无法满足的要求，请联系AEC主席提前安排。在过去，这包括选项，如作者使用所需硬件为云实例付费，审核人员可以使用匿名的访问（AEC主席充当代理，以便在实例可能关闭时进行通信节省作者的钱）。使用未清除的云实例或类似实例的提交AEC主席将被立即拒绝

如果论文中的一些主张没有得到工件的支持，例如，如果省略了一些基准，或者工件不包括我们在论文中进行实验比较的工具，那么我的工件可以被接受吗？

一般来说是的（如果提供了良好的解释，如上所述），但如果这些声明对论文的总体结果至关重要，则工件将被拒绝。作为一个极端的例子，由一个工作工具组成的工件如果提交时没有基准（例如，如果所有基准都有可能无法重新分发的源），则会被拒绝。

为什么我们需要使用Zenodo作为可用徽章？为什么Github没有？

商业存储库是不可靠的，因为不能保证评估的工件会无限期保持可用。与流行的观点相反，可以重写git提交公共存储库中的历史记录（请参阅有关git rebase和git推送的“--force”选项的文档，并注意git标记是可变的）。用户可以删除公共存储库或其帐户。除了大学删除随着时间的推移，部门URL、托管公司有时也会简单地删除数据：告别谷歌代码(2015),Bitbucket中的日落Mercurial支持(2019).

审查人员在我们的工件的文档或脚本中确定了要修复的内容，我们希望发布固定版本。我们不能提交可用性徽章的改进版本吗？

不，但你可以得到你想要的一部分。为了可用性，我们希望评价的版本到可用。但Zenodo允许对工件进行修改。当你这样做时，每个版本都会收到自己的DOI后，将创建一个登录页面，列出所有版本，当有人访问*评估*版本的页面，Zenodo将通知他们更新的版本是可用。有关详细信息：https://help.zenodo.org/版本控制

我可以在不提交工件的情况下获得可用徽章吗？我还在提供这个东西！

不。可用性徽章表示工件以支持报纸的主张而闻名可用在存档位置。使未评估的工件可用仍然是好的，但不在范围之内AEC将考虑的范围。

我可以为未被判定为功能性的工件获得可用徽章吗？我仍在做这件事！

否。可用性徽章保证可用的工件是已知支持论文的声称.一个工件的可用性，审核员试图使用它来复制论文的结果和失败具有不确定性价值。

联系人

请联系科林·戈登和安德斯·默勒如果你有任何问题。

今年，OOPSLA 2020艺术品评估委员会主席正在为艺术品评估委员会（AEC）寻求提名。如果您是一名高级博士生或博士后，具有与提交给OOPSLA的工件类型相关的专业知识，请阅读此消息的其余部分并申请：https://forms.gle/QHS5cn8uuJjzUcaA9

如果你不是，但认识可能感兴趣的人，请让他们知道这一点。

一般来说，“高级”博士生的门槛是SIGPLAN会议或相关会议（例如ICSE、FSE、ASE、ISSTA、ECOOP、ESOP等）上的一篇论文的作者，尽管这应该被解释为一个粗略的指导原则，而不是对你在哪里发表的严格要求。有工件评估经验（作为提交者或评审者）优先考虑，但也不是必需的。

AEC的工作将在OOPSLA第一阶段通知（2020年7月1日）和第二阶段修订到期日（2020年8月14日）之间进行。

有关工件审查的更多信息，请参阅2020年工件呼吁：https://2020.splashcon.org/track/splash-2020-Artifacts#调用-用于人工制品

如果您有任何问题，请随时联系2020年AEC主席(科林·戈登和安德斯·默勒).

结果概述

对于总共87篇有条件接受的OOPSLA论文，作者表示有意提交人工制品。我们收到了67份初次提交的文件，其中一份在提交后不久被撤回，剩下66件作品供审查（109份有条件接受的OOPSLA文件中的61%）。其中：

• 17人被视为无功能。这只是一个迹象，表明AEC无法复制所有相关索赔，以满足其要求，以及不相应文件的起诉书。
• 49人以某种方式被接受（74%接受），细分为：
  • 30个可重用（也意味着功能），因此61%的可接受工件被发现是可重用的
  • 19功能

这些百分比与2019年相似。然而，提交的总数量从去年的44份（增加了50%）大幅增加，这导致了最后一刻的争夺，将评审员队伍从30名博士生和博士后增加到50名，他们撰写了200篇评审。

杰出作品

• 基于学习的受控并发测试
• 通过查询分区查找数据库系统中的错误
• 使用Read-Eval-Synth循环进行编程
• 高级类型系统可以使用吗？黑曜石所有权、资产和类型状态的实证研究
• 使用双重口译员测试差异隐私
• ιDOT:具有对象初始化的DOT微积分

杰出工件评审员

• Caroline Lemieux（加州大学伯克利分校
• 阿维拉尔·戈尔（东北）
• Kaan Genc（俄亥俄州）
• Maaz Bin Safer Ahmad（华盛顿大学）
• Aina Linn Georges（奥胡斯大学）

未来工件评估建议

工件评估包括两个阶段：调试安装和依赖性问题的kick-the-tires阶段，以及全面审查阶段。作者有4天的时间来应对在kick-the-tires阶段遇到的问题。kick-the-tires阶段的常见问题包括：

• 翻转平台支架。一些声称只需要类UNIX系统的工件在macOS下严重失败，尤其是那些需要32位编译器的工件，这些编译器在较新的macOS版本中不再存在。我们建议未来的工件将其声称的支持范围缩小。通常，这可以由提供Dockerfile的作者修复。
• 缺少依赖项，或依赖项文档不完善。

与去年一样，提前避免此类问题的最有效方法是在新机器、VM或Docker容器上独立运行指令。

在全面审查阶段发现的常见问题包括：

• 与新基准上的现有工具进行比较，但不包括复制其他工具的执行。在对工件的调用中明确提到了这一点。
• 没有解释如何解释结果。几个工件成功运行，并生成了作为论文基础的输出，但没有任何方法供审阅者比较这些输出与论文的一致性。示例包括生成一个警告列表，但不记录哪些是真的，哪些是假阳性，以及生成大量数字表，这些数字表在论文中以图形方式呈现，但没有提供生成类似可视化的方法。

今年，与过去几年一样，工件审查的时间表被故意限定为OOPSLA第1阶段通知和OOPSLA提交论文第2阶段之间的时间段。这种安排起源于一个实验，目的是看看工件评估作为第2阶段决策的有用输入是否可行（纯粹就时间轴而言）。（需要明确的是：这是一项对时间可行性的研究，迄今为止，工件评估结果还没有被纳入第二阶段的决策中。）过去几年表明，这是可行的，但有成本。在实践中，它只需要6周的时间对工件进行端到端的审查。

我们认为，将第2阶段的最后期限与工件评估分离是值得的，以便有更多的时间进行工件审查。额外的时间可以让作者有更多的时间准备工件（而不是当前给定的一周），可以减轻审阅者的工作量，并允许与作者进行额外的一轮迭代，这在某些情况下是有用的。考虑到目前工件提交仅限于一次尝试（与论文提交不同），可能值得考虑一种不同的评审模型，该模型具有更多轮的反馈，并为作者提供机会，以纠正或改进他们的工件，以解决后期评审中遇到的问题。

明年更具体的建议包括：

• 审查表应从接受/拒绝术语改为具有两个数字分数，表示功能和单独可重用性方面的倾向，并具有适当清晰的分数文本。
• 授予可重用徽章的指导方针应该更加明确，无论是对作者还是评审员来说。让可重用性标准保持开放是有价值的，因为可重用性对于机器检查的证明、概念验证的编译器和动态分析工具来说通常意味着非常不同的东西。然而，目前使用的ACM标准是如此开放，以至于作者很难知道目标是什么。
• 为了更好地与一般ACM指南和其他SIGPLAN会议保持一致，我们应该允许工件接收可用徽章，而无需满足功能需求。这还有一个额外的好处，那就是仍然奖励那些可能“接近”实现功能指定的工件。这可以通过AEC放宽对可用徽章的要求（但仍要求AEC查看文物），或者允许会议出版独立于AEC处理文物的可用性（在这种情况下，论文可以携带可用徽章，而不会被AEC看到）来进行。
• 我们应该为计算密集型工件的计算基础设施寻求资金。今年和去年，提交的工件需要特定的GPU、小集群、一台机器上数百GB的RAM或几十个内核。这导致每年都会有一场争夺战，以识别哪些工件具有这些重要需求，并尝试将其重新平衡，以供具有访问可能适用系统的现有权限的审查人员使用。今年和去年，一些工件作者自费租用云系统供审查人员使用。然而，这种偏见的审查有利于那个些为此提供资金的人（很容易产生高达数千美元的账单）。虽然我们仍然应该允许并鼓励作者拥有此类资源的工件这样做，但我们也应该为云计算筹集资金，AEC可以根据需要根据到达的工件自行建立云计算。可以通过各种供应商的研究学分计划申请，但将其作为未来版本OOPSLA赞助请求的一部分也可能有用。