父议题属于谁与子议题完成多少：GitHub层级资料的两个方向

GitHub子议题把较大的工作拆成较小议题，同时在子项上保留与父议题的关系。官方Adding sub-issues又说明，子议题本身还能包含子议题。[1] 因此，父与子描述的是两项议题之间的位置关系，不是将某个议题永远固定为只能位于最底层。一个子项继续包含更小子项时，它仍可相对上一级为子，相对下一级为父。

文档给出的两个数量限制也各有计数对象：每个父议题最多有一百个子议题，嵌套最多八层。[1] 前者描述同一个父项可以直接联系多少子项，后者描述沿父子关系向下延伸的深度。将一百和八合成一个“任务上限”，会丢失横向数量与纵向层级的区别；原文也没有把这个数量说明当作某个团队已经完成拆分的记录。

子项的来源不只一种。官方分别介绍创建新的子议题，以及将已有议题关联为子项；后一条路径还允许来自其他仓库的议题。[1] 于是，层级联系并不要求所有条目都在同一时刻新建，也不要求它们原先位于同一仓库。跨仓库资料里的编号仍需连同仓库身份理解：相同数字可以出现在不同仓库中，父子关系不能只靠裸编号来识别。这里解释的是文档对象，没有复制或迁移仓库。

浏览层级时，网页提供了相反的两个方向。Browsing sub-issues说，可以从父项浏览各层子议题；查看某个子项时，标题下的页头则提供返回父项的链接。[2] 前一种信息回答一个工作下面有哪些层次，后一种回答当前条目归到哪里。只摘录子项清单，未必保留了读者从某一条回到上一级所需的身份；只保留父链接，又不会自动呈现全部向下展开的子项。

Projects中的字段进一步把归属与进度分开。Parent issue可以用来分组，让条目按已建立的父子层级组织，也能用于只显示某一父项的子议题。Sub-issue progress则说明有多少子议题已经完成。[3] 两个字段面对同一批工作，却分别表达集合归属和集合中的完成情况。某个条目被分到同一父项下，不等于它与其他子项具有相同状态；看见一个进度数字，也不能据此知道每条子项的全部文字。

官方命令行输出示例使这种区别更具体。Build a scoreboard编号123的父议题为Open，下面编号124的布局子项为Closed，编号125的分数保存与编号126的排行榜子项仍为Open，示例进度为1/3、33%。[2] 这个例子同时呈现了父状态、三条子项的状态和一个汇总值。一个子项关闭与父项仍开放在该示例中并存，所以不能仅凭子进度非零，就替资料补写父项已经关闭；这也不是本文检查过某个真实项目的运行结果。

同页对机器可读资料另列parent、subIssues与subIssuesSummary三个字段。[2] 它们分别保留父引用、子项集合与子项摘要，使网页中向上查归属、向下看成员、查看进度的三种资料层次在输出中仍有位置。汇总值适合表达完成比例，却没有取代成员身份和逐项状态；父引用则保留关系方向，不能独自说明下级任务完成了多少。本文采用GitHub.com公开帮助，首发日未知，不执行命令、改变议题或发送通知，也不把Closed标签当作代码测试通过的证明。