摘要

  • 2008 年 9 月的访问权限 FAQ 保留了一个例子：同楼层另一实验室的研究人员，把共享空间的通知加进本组会议页。
  • 网站向公众开放阅读，向会员广泛开放编辑；账户、修改记录和礼节规则承担日常管理工作。

隔壁的一位研究人员有件事想让大家知道，于是直接写进了会议页。OpenWetWare 的历史访问权限 FAQ记下过这个例子：同一楼层、另一个实验室的研究人员，把一条关于共享空间的通知放进本组开会的页面。组里平时就在 wiki 上登记议题，负责人开会时照着页面安排讨论。走廊里的消息，就这样进了议程。

文档作者觉得，这件小事恰好解释了自己的权限选择。组会页面很容易被划成“仅本实验室可编辑”。偏偏有用的信息来自组外，而且对方知道该把它放在哪里。按实验室划一道编辑边界，也可能顺手把这条贡献挡在外面。

加入社区，拿到的不止自家门牌

OpenWetWare 在 2005 年起步于 MIT 的 Endy 和 Knight 两个实验室的研究生。最后编辑于 2007 年 5 月的总 FAQ把它描述成研究人员为自己工作搭建的资源，随后其他实验室和个人也加入使用。文档尤其鼓励新人记下实际工作中容易漏掉的小细节；做熟了的人，有时已经想不起这些地方曾经会绊人。

到 2008 年 9 月留存的权限说明里，规则写得相当干脆：所有人可读，会员可编辑，基本没有逐页改变这一安排的选项。会员进入的是整个协作社区，编辑范围也就超出了自己的实验室主页。

作者看重跨组贡献，也担心一层层权限把平台变成各实验室分别租用的网页空间。他们承认，很难事先列准谁应该参与某份文档。隔壁补通知的例子，就是那份说明给出的实际理由。

编辑键旁边，还有记录和规矩

编辑要先登录账户。FAQ 说，相关领域的学生和研究人员提供基本信息后可以申请加入；账户和页面历史记录，让贡献能够追溯到参与者。作者还直说，处理破坏和垃圾信息的人手有限。网站把技术入口设在社区成员资格上。

入口之内，也靠礼节划线。比如，文档提到社区会请大家不要随意改别人的个人页面。软件给出的编辑范围很宽，使用它时仍有约定。遇到不受欢迎的修改，总得有人看见、判断，再处理。

私下整理的东西则另找地方。说明记载，一些研究人员在自己的电脑上使用私人 wiki，另一些组保留内部网站。方便安装的 OpenWetWare 独立发行版，以及日后把内容转回公共站点的办法，当时还是等待资源的计划。

需要引用固定内容时，可以指向某次保存的历史版本；需要开会时，就继续使用会变动的议程。同一套网站，文件的用途不同，照看的方式也不同。

这套安排最有说服力的地方，是那条从隔壁送来的通知。实验室已经共用走廊，网页也给走廊另一头的人留了一支笔。