议事子领域

[Guo-Zhang]

复杂的议事流程大量地依赖平台进行协作，而现有的企业服务平台都很难支撑这么复杂的流程，因此需要设计一个专用平台。

我们主要采用领域驱动设计的方式对业务需求进行精准的建模。首先要定义一个领域，我把这个子领域定义为“议事”，相比于一般的“讨论”，它更加正式和结构化，有相对固定明确的流程，需要经过辩论和投票来决定。

接下来是定义领域模型。主要的几个领域模型是“议题”、“议程”和“议事规则”，这是管理议事需要考虑的三个层次。

“议题”是最基本的单元，围绕一个主题来提案和审议。由于我们主要的生产资源都托管在GitHub，所以主要使用GitHub Issue作为记录提案的工具。GitHub Issue的主要缺点，一方面是不方便看到每个人的立场观点的陈述，另一方面是不方便关键投票，我们暂时采取发到特定企业微信群并使用群投票功能来实现。因此，初步的考虑是我们自己的议题会包括一个类似于知乎问答的讨论区用来陈述观点，同时关联一次对这个议题的投票。

目前还有几个缺陷。首先是没有定义“状态”，这要取决于对业务流程的概括结果，初步的可能是“起草中”、“审议中”、“投票中”、“已结束”等等。其次是“投票”也还没有定义，主要是权衡投票是议题的一部分还是一个完全独立的模型。要不要增加附件字段或者外链管理字段也没有确定，主要是需要考量整个系统层面的设计。

议程可以简单地看作是给议题排序过的列表。根据我们目前的实践，议程主要是和委员会或者部门或者项目组（我们统称为“员工组”）相关，在一个时间段内一个员工组维护一个议程，大家有时间就上去发言讨论，因此和会议上的议程很不一样的一点是，这个议程是一个动态变化的议程。这也意味着对应的议事规则要进行针对性的优化和调整。

主要是没有想明白除了议题列表以外还需要什么字段。是否关联员工组还有点点犹豫，因为也不是不会出现临时会议或者临时小组需要有议程管理的情况，而我们定义的“员工组”是一个相对稳定的组。这些难以处理的细节也会对整体架构设计有一定影响。

议事规则就是规定议程和议题相关的议事流程。由于我们的基本假设是“异步”地议事而非“同步”地议事，现有的议事规则不一定可以参考，还需要根据实际情况做出必要的调整。

我查阅了一些联合国等外交机构公开的议事规则，大部分都是一条一条的。这里有两种方法，一种是每个“议会”都对应一个长文本，那么就只需要标题和内容两个主要字段就可以了。另外一种是分解成一条一条存储起来，这样的好处是方便具体修改某一条或者增删某一条的时候留详细记录，也方便具体某条规则和系统里的触发器关联起来，方便对一些操作进行自动触发。更理想的情况是写好规则文本以后，用AI生成一个系统触发器来自动执行，这样订立规则以后可以自动执行规则，大大地提高效率。

还缺少很多概念没有定义，包括但不限于：

• ​“议会”需要一个对应的概念，比如“议事成员组”。还需要定义议会的上下级关系，类似于人大常委会和专门委员会，以下级委员会向上级委员会汇报的实践。
• “议员”需要一个对应的概念，比如“议事成员”。具体还需要区分“主席”、“常委”、“委员”、“候补委员”、“书记/秘书”等角色。

下一步的计划是讨论和完善这套设计。