议题Issue

定义

议题是会议或讨论中的一项具体内容，它通常涉及一个决策点或需要讨论的主题。

属性

• 议题ID：唯一标识每个议题的编号。
• 标题：简洁地描述议题的主要内容。
• 描述：提供议题的详细背景和相关信息。
• 优先级：指示议题的重要程度。
• 相关决策：列出与议题相关的决策编号或名称。
• 状态：议题当前的处理状态（例如：待讨论、正在讨论、已决议、已推迟等）。

行为

• 创建议题：新建一个议题记录。
• 编辑议题：修改现有议题的信息。
• 删除议题：从列表中移除一个议题。
• 分配议题：将议题指派给特定的人员或团队。
• 标记议题为重要或紧急：根据议题的性质进行标记。
• 跟踪议题的状态变化：监控议题状态随时间的变化。

议程Agenda

定义

议程是会议或讨论的顺序安排，它包含了所有待处理的议题。

属性

• 议程ID：唯一标识每个议程的编号。
• 名称：简洁地描述议程的主题或目的。
• 描述：提供议程的详细背景和相关信息。
• 创建日期：议程设定的初始日期。
• 截止日期：议题讨论的最后期限。
• 议题列表：包含在议程中的所有议题。

行为

• 创建议程：新建一个议程记录。
• 添加议题到议程：将议题包含进议程中。
• 删除议题：从议程中移除一个议题。
• 调整议题顺序：改变议题在议程中的排列顺序。
• 设置议程的状态：设定议程的当前状态（例如：草稿、发布、已撤销等）。

议事规则ParliamentaryProcedure

定义

议事规则是指导会议或讨论流程的一组规则，它确保讨论和决策过程的合法性和效率。

属性

• 规则ID：唯一标识每条规则的编号。
• 名称：简洁地描述规则的主要内容。
• 描述：提供规则的详细说明和适用场景。
• 适用范围：规则适用的会议类型或组织层级。
• 执行顺序：规则在议事过程中的执行顺序。

行为

• 创建规则：新建一条议事规则。
• 编辑规则：修改现有规则的内容。
• 删除规则：从规则集中移除一条规则。
• 启用或禁用规则：根据需要激活或暂停某条规则的执行。
• 更新规则以反映政策或流程的变化：随着政策和流程的更新，对规则进行相应的调整。

会议Meeting

关联：

• 日程
• 议程
• 汇报

等等

• 起草中
• 审议中
• 投票中
• 已结束，或者 已通过/未通过

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

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

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

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

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

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

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

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

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

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

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

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

议事子领域：议题、议程、议事规则。

会议子领域主要参考联合国等正式会议的形式建模。主要的建模方向是对会议的组织要素进行正式的建模，以方便组织更有结构、有条理的会议，不做市面上常见的音视频SaaS或者PaaS平台、而是要和他们打通。

计划包括的领域模型包括：

• 会议 Metting
• 议事规则Institution（或者RulesOfProcedure）、议程Agenda、议题Issue（或者AgendaItem）。

议题的创建者是系统维护的，而实际负责撰写议题的人是另一个人，那么我们可以将这个实际负责人定义为“作者”（Author）或“起草者”（Drafter）。

上述定义只考虑了提案的撰写。如果考虑一个议题的讨论和总结也需要同一个人从头负责到尾，则可能需要定义负责人（Owner），以及多个参与草案撰写的参与者（Members）。

PS：由于项目管理领域的“事项”也有类似的Owner和Members的定义，因此也可以考虑把这组字段上升为标准字段，未来在文档管理、数字资产管理等领域也可以使用。