• 1
• 测试页面

H_W

• 页面归档后，顶部会显示一个让站务添加归档记录的快捷链接，进入后填写表单并保存，该记录就会显示在归档页上方。
• 记录本质是一个新的命名空间的页面，因此自带创建者、创建时间等信息，表单中预设几种归档理由供选择。在其他地方可以用listpage制作这个归档记录的列表。

这个方案的优势是将归档记录作为了独立元素，不依托讨论串、帖子等介质，因此能够自由地引用并保持信息同步。归档页顶部挂快捷链接也使得操作流畅便捷，删完顺手就能加。

关于目前的归档页面列表，本人再三考虑后，认为虽然其在用户使用上的作用是客观存在的，但都不足以单拎出来做文章，为了那些需求反复修改维护也不合适。与其让列表带着各种难办的因素下不去手，不如把最核心的需求单独分出去从头搞。因此目前的想法如下：

• 新增一个归档记录的列表页，定位完全服务编者。与旧列表不同，它是从编者对透明规范的归档制度的需求出发建立的，所有的优化维护也都围绕着这一点。
• 完整的归档列表为了站务工作需要保留，但不再直接挂在顶栏。可以在新的归档记录页添加旧列表的链接，意思是“想看就可以看，但旧列表不会为了普通用户的需求做优化维护”。

H_W

个人的情况如下：因为站里一直把归档列表挂在顶栏，所以我一直把那个页面当作面向用户的功能，也不可否认归档区有不少圣地巡礼的现象，或者从归档页找题材重写，这些肯定都是从顶栏入口进去查的。

虽然这一点重要性不高，不让用户看归档页也不影响站点运行，但因为上述客观事实，个人一直把归档列表视作站点生态的一部分，所以更倾向用户体验的角度来看待。前段时间淮海浪士提出站里归档操作不规范后，我就会倾向从用户角度思考归档区有没有别的问题，能不能一起解决了，过程也确实可能想太多，顾及了实际不存在的需求。正好碰到迁站能让归档重新来过，所以顺着淮海浪士的意见提了自己的一系列想法。

H_W似乎更倾向于归档就是个删除操作，并不是面向用户的，列表挂在顶栏是当时顺手。因此我确实对此有误解，但归档列表在用户层面的作用我个人认为是客观存在的，若最后讨论确定该功能不面向用户，直接藏掉不让用户看，我也不反对，只是希望讨论过程中不要完全忽视这一点。在不面向用户的前提下，这个串里我提出的想法肯定也不完全合适了，需要重新考虑。

之前提出的一系列归档制度改革是建立在新站MediaWiki框架下的，迁站暂停后尚无法延续讨论，因此可以考虑在旧站先行做一些变革。目前已知有以下问题：

• Wikidot不存在MediaWiki那种自带留档的删除操作，这里要么是转移到其他命名空间，要么就彻底删除无留档。
• 即使设定归档放在其他命名空间，底栏的“删除按钮”也是绑定deleted命名空间，修改不了，可能导致站务误操作。
• 既然没有删除操作，也不存在MediaWiki自带的“删除原因”功能，想要实现这点会更加麻烦。
• deleted命名空间已经是屎山了，又因为默认的删除绑定这个空间，想做文章就很难不对这里搞大动作。

目前有一个比较简单的方案：开新板块，将词条归档的信息记录为一条条帖子，规定帖文使用固定格式，然后归档页面改用FrontForum 模块，将该板块的帖子整理成列表形式展出。这样在不新增命名空间的前提下，也能实现归档词条单独列表以及展示归档者和归档原因。唯一的问题是Front Forum模块没有自带翻页，得用[[html]]手搓翻页功能（懒得喷了）。。。

首先制度是肯定要改的，并且直接适用到新站，老站没必要做文章了。目前的归档区是一个随意堆放的垃圾桶，没有任何条理可言，我认为新站的归档制度至少要做到几点：

1. 词条的归档应单独分区，而不是跟废弃的管理页、组件页等堆在一起
2. 清晰地记录下词条是出于什么原因、被哪位站务归档的
3. 站务进行归档操作必须有条例可依，必须有明确的告知
4. 有明确的成员申诉渠道

对于其中的细节可以进一步讨论。例如第2条的归档原因，个人觉得可以简单划分为几种特定情况，不需写得过于详细。相应的，对词条修订的建议等过程要素需要在其他地方（如词条讨论区）写清楚。

但是这些修订通知是否要单开板块，我保留意见。这可能并不能有效提升反馈的及时性，一方面词条内容是动态的，与静态的、一次性的通知不太适配，另一方面通知和讨论在离词条很远的地方也很不便捷。虽然新站词条有独立的评论和讨论区，但那种页面讨论与老站用户的习惯相差甚远，效率可能还不如评论区。

此外，归档本身的含义可能也需要商榷。虽然之前H_W提出的不破坏元叙事¹使得站点几乎不会删除词条，但总归是会遇到必须直接干掉的情况，站点至今都缺乏这方面的明确条例。