【Paper Tips】随记5-期刊投稿阶段说明

写paper时随心记录一些对自己有用的skills与tips。


一、待解决问题

1.1 问题描述

近期有期刊投稿的需求,以人工智能领域经典期刊KBS为例,阐述投稿该期刊的要求与规范。

1.2 解决方法

(1)明确投稿的阶段
(2)KBS期刊投稿周期总结

二、方法详述

2.1 必要说明

暂无

2.2 应用步骤

2.2.1 明确投稿的阶段

(1)Submitted to journal

这个状态一般是在投稿后,期刊确认收到稿件自动回复的。

(2)With editor
  1. 编辑审稿前,助手会确认稿件是否齐全,不齐全的情况下会要求作者立即补充相关材料;
  2. 材料齐全后,会将稿件移交给编辑处理,没有指定编辑的情况下,会默认分给主编,到了这个阶段可能会产生三个分状态:

① 编辑指派。(主编分配给编辑)
② 编辑拒接邀请。(编辑拒绝指派,并重新分配编辑)
③ 编辑决定。(⚠️这个状态就表示,编辑没有找审稿人就自己决定了,大概率直接拒稿

(3)Reviewers invited

这个状态表示编辑这一关已经过了,并且正在找审稿人。
(一些小众方向,可能会导致找寻审稿人时间周期较长。)

(4)Under review

这个状态表示审稿人已找到,并正在审稿。一般而言,这是时间周期最长的阶段。
(时间周期长短取决于审稿人数量,审稿人效率等)

(5)Required reviewers Completed

这个状态表示所有审稿人已完成审稿,并将审稿意见返回至编辑部。
⚠️有时候,编辑浏览审稿意见可能会觉得需要额外审稿,阶段状态可能会变回Under Review

(6)Decision pending

这个状态表示编辑收到审稿人意见后,对稿件进行最后的评价,考虑是给修改拒稿直接接收
一般而言,直接接收可能性较小。
修改分为大修和小修,即Major RevisionMinor Revision

⚠️这个阶段一般会要求返修截至时间,若时间觉得不充裕,可邮件联系延长修改时间。

(7)Revision submitted to journal

修改稿重新提交后,就又会回到审稿人手中或编辑自行评价,重新从Under review阶段开始。

(8)Final disposition

这个就是对稿件的最终决定,分为AcceptReject

2.2.2 KBS期刊投稿周期总结

  • 时间周期总结

根据下述已投稿反馈,平均Accept周期为:4.5 months
结合小木虫论坛得反馈,平均周期在4~5个月左右,算是比较快了。

  • 投稿建议总结

尽量代码开源。这样无形会增加审稿人对你实验结果的可信度。
建议引用投稿期刊的文献。会让人审稿人觉得与期刊符合度较高。

(1)知乎网友分享
  • 第一位投稿;

2019-9-10 Submitted to Journal
2019-9-12 With Editor
2019-9-17 Under Review
2019-11-03 Under Review
2019-12-03 Under Review
2020-1-07 Under review
2020-1-28 Under review
2020-2-4 Under editor evaluation
2020-2-4 Revise (evening)
2020-2-23 Revision Submitted to Journal
2020-2-24 With editor
2020-2-25 Under review
2020-3-30 Under review (2 review comments feedback)
2020-4-4 Required Reviews Completed
2020-4-4 Revise (evening)
2020-4-6 Revision Submitted to Journal
2020-4-6 With editor
2020-4-6 Under review
2020-5-4 Revise
2020-5-7 Revision Submitted to Journal
2020-5-7 With editor
2020-5-7 Under review
2020-6-7 Revise
2020-6-11 Revision Submitted to Journal
2020-6-12 With editor
2020-6-12 Completed-accept

第二位投稿:
(2023年,仅返修一次)

5.28 with editor
6.18 under review
9.9 Required Reviews Completed
9.14 Revise
10.17 re-submit
10.20 under review
11.12 accept

第三位投稿:

2022年7月11日,投稿
2022年7月16日,副编辑处理,
2022年7月31日,2个审稿人完成审稿,
2022年8月3日,编辑 给了修稿意见。(PS:两个审稿人很友好,加起来一共10条意见,均好回复,另外,需要做一个补充消融实验)
2022年8月14 ,修订版本提交
2022年8月16日,总编辑处理
2022年8月22日, 二审 完成(PS:还是发给之前的审稿人)
2022年8月24日 ,两个审稿专家 没什么意见了,只有一位审稿专家 说“英语表达能力需要提升
2022年8月26日, 提交自己修改的手稿
2022年8月27日, 论文接收。

第四位投稿:
(2024年,仅返修一次)

9.17 submit
12.3 r1 Revise (Including Language Editing)
12.19 revise提交
1.4 录用

(2)vx顶刊追踪
  • 第一位投稿:

2022-11-14 投稿2022-11-15 with editor
2022-11-17 with editor
2022-11-19 under review
2022-11-27 required reviews completed
2022-11-30 required reviews completed
2022-12-5 required reviews completed
2022-12-7 decision in process
2022-12-10 major revise 8个审稿人 60多个意见
2023-1-4 with editor2023-1-24 under review
2023-1-26 required reviews completed
2023-1-31 required reviews completed
2023-2-7 required reviews completed(including
2023-2-8conditionallyacceptedlanguage editing)
2023-2-14 提交润色后的稿件,花了七百刀,估计五千多rmb
2023-2-14 with editor2023-2-15 completed -accept

  • 第二位投稿:

2023-07-28 提交审稿(3个审稿人)
2023-08-29 2个审稿人小修
2023-09-11 返修至主编
2023-09-25 有条件接收
2023-09-28 accept

(3)peipusci学术
  • 第一位投稿:

2022.12.10 提交约两天后变成with editor
2023.02.23 rrc
2023.02 25 小修
2023.03.20 修回提交
2023.04.15 rrc
2023.06.20 rrc(中间通过系统发邮件催稿没有任何回信,看到很多人都是rrc之后一直没动,可能是期刊内部问题吧,最后没办法只能给主编发邮件,才处理)
2023.06.23 有条件接收(主要就是润色(可以不用邮件中推荐的爱思唯尔润色机构))
2023.06.26 提交 with editor
2023.07.01 accept (没有rrc状态,直接到accept)

  • 第二位投稿:

2023.06.08 submit
  2023.06.20 under review(4个审稿人)
  2023.07.30 required review completed
  2023.07.31 decision in process
  2023.08.02 revise
  2023.08.08 resubmit
  2023.08.09 under review
  2023.08.16 required review completed
  2023.08.18 required review completed(二次变化)
  2023.08.21 decision in process(二次变化)
  2023.08.21 accept(二次变化)

  • 第三位投稿:

2022. 12. 31 submitted
  2023. 01. 06 under review
  2023. 03. 12 under review
  2023. 04. 13 under review
  2023. 05. 15 under review
  2023. 05. 30 required reviews completed
  2023. 06. 09 revision
  2023. 06. 18 with editor
  2023. 06. 20 under review
  2023. 08.26 revise (including language editing) conditionally accepted
  2023. 08.31 submitted
  2023. 09.01 with editor
  2023. 09.12 accept

(4)小木虫论坛

平均审稿周期5.3个月。

(2025-04-02补充)
最后附上知乎上两位大佬投稿Knowledgebased system(KBS)的总结:
Knowledge Based System从下载LaTeX模板到提交(个人记录)
Knowledge-Based Systems投稿记录

三、疑问

暂无

四、总结

  1. 即时订阅邮箱信息,第一时间知晓论文审阅动态。
  2. 回复审稿人意见需要充分且礼貌。
### 关于010 Editor饥饿错误的原因分析 在讨论010 Editor的饥饿错误之前,需了解其可能涉及的操作系统调度机制以及软件本身的资源管理方式。虽然具体引用未提及010 Editor的相关实现细节,但从操作系统层面来看,类似的饥饿问题通常源于调度算法的设计缺陷或资源分配不均。 #### 1. **饥饿错误的根本原因** 饥饿错误一般发生在进程或线程长时间无法获取所需资源的情况下。对于010 Editor而言,这种现象可能是由于以下原因之一引起的: - 如果010 Editor依赖某种优先级调度策略,则低优先级的任务可能会被高优先级任务持续抢占资源,从而导致长期得不到服务的情况[^1]。 - 另外,在多线程环境中,如果存在锁竞争(Lock Contention),某些线程可能因为未能及时释放共享资源而陷入等待状态,进而引发饥饿问题[^2]。 #### 2. **解决方法** 针对上述潜在原因,以下是几种可行的解决方案: ##### (a) 使用公平调度器 通过引入更先进的调度技术如完全公平调度器(CFS),可以有效缓解此类问题。CFS利用红黑树结构维护调度队列,确保每个可运行实体都能按比例分得CPU时间片。尽管这是针对Linux内核设计的概念,但对于任何基于事件驱动的应用程序来说都有借鉴意义——即重新审视当前使用的任务排队逻辑并考虑采用更加均衡的方式处理请求。 ```python import heapq class TaskScheduler: def __init__(self): self.task_queue = [] def add_task(self, priority, task_id): """Add a new task with given priority.""" heapq.heappush(self.task_queue, (-priority, task_id)) def get_next_task(self): """Retrieve the next highest-priority task.""" if not self.task_queue: return None _, task_id = heapq.heappop(self.task_queue) return task_id ``` 此代码片段展示了一个简单的优先级队列实现,其中`heapq`模块用于保持最小堆性质以便快速检索最高优先级项。然而需要注意的是,实际应用中还需结合具体情况调整算法参数以满足实时性和公平性的双重需求。 ##### (b) 锁优化与死锁预防措施 当检测到由同步原语引起的问题时,应审查现有加解锁流程是否存在不必要的延迟或者循环依赖关系。例如,可以通过减少持有临界区的时间长度来降低冲突概率;同时也可以尝试运用读写锁代替互斥量以允许多个读者并发访问公共资源。 另外值得注意的一点是,即便是在单机环境下开发桌面应用程序也应当遵循良好的编码实践原则,比如提前验证输入合法性、捕获异常情况下的恢复路径等,这些都可以间接帮助规避一些难以预料的技术债务积累所造成的性能瓶颈。 ##### (c) 权限配置核查 考虑到部分功能受限可能导致预期行为失常的现象,有必要确认目标平台上的权限设置是否合理恰当。特别是像Android这样的移动生态系统里,即使是最基础的数据交互也可能牵涉复杂的许可链条[^3]。因此建议检查如下几个方面: - 是否正确声明了必要的API调用权限; - 安装包签名匹配状况如何; - 动态加载组件是否有额外的安全约束条件附加等等。 综上所述,要彻底根除010 Editor中的饥饿错误需要综合考量多个维度的因素,并采取针对性强的有效手段加以应对。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值