Internet Engineering Task Force (IETF)                         R. Sparks
Request for Comments: 7735                                        Oracle
Category: Informational                                       T. Kivinen
ISSN: 2070-1721                                            INSIDE Secure
                                                            January 2016
        
Internet Engineering Task Force (IETF)                         R. Sparks
Request for Comments: 7735                                        Oracle
Category: Informational                                       T. Kivinen
ISSN: 2070-1721                                            INSIDE Secure
                                                            January 2016
        

Tracking Reviews of Documents

文件的跟踪审查

Abstract

摘要

Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.

几个审查小组确保在互联网草案成为RFC的过程中对其进行特定类型的审查。这些团队用于分配和跟踪审查的工具将受益于与Datatracker的更紧密集成。本文档讨论了在不中断当前工作流程的情况下改进这些工具的要求。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7735.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7735.

Copyright Notice

版权公告

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview of Current Workflows . . . . . . . . . . . . . . . .   3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Secretariat Focused . . . . . . . . . . . . . . . . . . .   5
     3.2.  Review-Team Secretary Focused . . . . . . . . . . . . . .   5
     3.3.  Reviewer Focused  . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Review Requester and Consumer Focused . . . . . . . . . .  10
     3.5.  Statistics Focused  . . . . . . . . . . . . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  A Starting Point for Django Models Supporting the
                Review Tool  . . . . . . . . . . . . . . . . . . . .  14
   Appendix B.  Suggested Features Deferred for Future Work  . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview of Current Workflows . . . . . . . . . . . . . . . .   3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Secretariat Focused . . . . . . . . . . . . . . . . . . .   5
     3.2.  Review-Team Secretary Focused . . . . . . . . . . . . . .   5
     3.3.  Reviewer Focused  . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Review Requester and Consumer Focused . . . . . . . . . .  10
     3.5.  Statistics Focused  . . . . . . . . . . . . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  A Starting Point for Django Models Supporting the
                Review Tool  . . . . . . . . . . . . . . . . . . . .  14
   Appendix B.  Suggested Features Deferred for Future Work  . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
        
1. Introduction
1. 介绍

As Internet-Drafts are processed, reviews are requested from several review teams. For example, the General Area Review Team (Gen-ART) and the Security Directorate (SecDir) perform reviews of documents that are in IETF Last Call. Gen-ART always performs a follow-up review when the document is scheduled for an IESG Telechat. SecDir usually performs a follow-up review, but the SecDir secretary may choose not to request that follow-up if any issues identified at Last Call are addressed and there are otherwise no major changes to the document. These teams also perform earlier reviews of documents on demand. There are several other teams that perform similar services, often focusing on specific areas of expertise.

在处理互联网草稿时,需要几个审查小组进行审查。例如,一般区域审查小组(Gen ART)和安全理事会(SecDir)对IETF上次调用中的文件进行审查。Gen ART总是在文件计划进行IESG Telechat时进行后续审查。SecDir通常会进行后续审查,但如果在最后一次电话会议上发现的任何问题得到解决,并且文件没有重大变更,SecDir秘书可以选择不要求进行后续审查。这些团队还根据需要对文档进行早期审查。还有其他几个团队提供类似的服务,通常专注于特定的专业领域。

The secretaries of these teams manage a pool of volunteer reviewers. Documents are assigned to reviewers, taking various factors into account. For instance, a reviewer will not be assigned a document for which he is an author or shepherd. Reviewers are given a deadline, usually driven by the end of Last Call or an IESG Telechat date. The reviewer sends each completed review to the team's mailing list and to any other lists that are relevant for the document being reviewed. Often, a thread ensues on one or more of those lists to resolve any issues found in the review.

这些小组的秘书们管理着一批志愿评审员。考虑到各种因素,将文件分配给审阅者。例如,不会为审阅者分配其作为作者或监护人的文档。审稿人有一个截止日期,通常由最后一次通话结束或IESG Telechat日期决定。审阅者将每个完成的审阅发送到团队的邮件列表以及与正在审阅的文档相关的任何其他列表。通常,一个线程会出现在一个或多个列表上,以解决审查中发现的任何问题。

The secretaries and reviewers from several teams are using a tool developed and maintained by Tero Kivinen. Much of its design predates the modern Datatracker. The application currently keeps its own data store and learns about documents needing review by inspecting Datatracker and tools.ietf.org pages. Most of those pages are easy to parse, but the Last Call pages, in particular, require

来自多个团队的秘书和评审员正在使用Tero Kivinen开发和维护的工具。它的大部分设计早于现代数据跟踪器。该应用程序目前保留自己的数据存储,并通过检查Datatracker和tools.ietf.org页面了解需要审查的文档。大多数页面都很容易解析,但最后一个调用页面尤其需要

some effort. Tighter integration with the Datatracker would simplify the logic used to identify documents that are ready for review, make it simpler for the Datatracker to associate reviews with documents, and allow users to reuse their Datatracker credentials. It would also make it easier to detect other potential review-triggering events, such as a document entering Working Group (WG) Last Call or when an RFC's standard level is being changed without revising the RFC. Tero currently believes this integration is best achieved by a new implementation of the tool. This document captures requirements for that reimplementation, with a focus on the workflows that the new implementation must take care not to disrupt. It also discusses new features, including changes suggested for the existing tool at its issue tracker [art-trac].

一些努力。与Datatracker更紧密的集成将简化用于识别准备好审阅的文档的逻辑,使Datatracker更容易将审阅与文档关联起来,并允许用户重用其Datatracker凭据。它还可以更容易地检测到其他潜在的审查触发事件,例如文件进入工作组(WG)最后一次调用,或者在不修改RFC的情况下更改RFC的标准级别。Tero目前认为,这种集成最好通过新的工具实现。本文档捕获了重新实施的需求,重点是新实施必须注意的工作流程,以避免中断。它还讨论了新功能,包括在其问题跟踪[art trac]上为现有工具建议的更改。

For more information about the various review teams, see the following references.

有关各种审查小组的更多信息,请参阅以下参考资料。

          +-------------------------------+---------------------+
          | General Area Review Team      | [Gen-ART] [RFC6385] |
          | Security Directorate          | [SecDir]            |
          | Applications Area Directorate | [AppsDir]           |
          | Operations Area Directorate   | [OPS-dir]           |
          | Routing Area Directorate      | [RTG-dir]           |
          | MIB Doctors                   | [MIBdoctors]        |
          | YANG Doctors                  | [YANGdoctors]       |
          +-------------------------------+---------------------+
        
          +-------------------------------+---------------------+
          | General Area Review Team      | [Gen-ART] [RFC6385] |
          | Security Directorate          | [SecDir]            |
          | Applications Area Directorate | [AppsDir]           |
          | Operations Area Directorate   | [OPS-dir]           |
          | Routing Area Directorate      | [RTG-dir]           |
          | MIB Doctors                   | [MIBdoctors]        |
          | YANG Doctors                  | [YANGdoctors]       |
          +-------------------------------+---------------------+
        
2. Overview of Current Workflows
2. 当前工作流概述

This section gives a high-level overview of how the review team secretaries and reviewers use the existing tool. It is not intended to be comprehensive documentation of how review teams operate. Please see the references for those details.

本节从高层次概述了审查小组秘书和审查员如何使用现有工具。本文件并不打算全面记录审查小组的运作方式。有关这些详细信息,请参阅参考资料。

For many teams, the team's secretary periodically (typically once a week) checks the tool for documents it has identified as ready for review. The tool compiles a list from Last Call announcements and IESG Telechat agendas. The secretary creates a set of assignments from this list and enters them into the reviewer pool, choosing the reviewers in roughly a round-robin order. That order can be perturbed by several factors. Reviewers have different levels of availability. Some are willing to review multiple documents a month. Others may only be willing to review a document every other month. The assignment process takes exceptional conditions such as reviewer vacations into account. Furthermore, secretaries are careful not to assign a document to a reviewer that is an author, shepherd, responsible WG chair, or has some other already existing association with the document. The preference is to get a reviewer with a fresh

对于许多团队,团队秘书会定期(通常一周一次)检查该工具是否有其确定为可供审查的文档。该工具根据上次通话通知和IESG Telechat议程编辑列表。秘书从该列表中创建一组任务,并将其输入审阅者池,大致按循环顺序选择审阅者。这个顺序可能会受到几个因素的干扰。审阅者具有不同的可用性级别。有些人愿意每月审查多份文件。其他人可能只愿意每隔一个月审查一次文档。分配过程考虑了特殊情况,如审核人休假。此外,秘书应注意不要将文件分配给作为作者、shepherd、负责工作组主席或与文件有其他关联的审阅者。首选的方法是让一位评审员有一份新的

perspective. The secretary may discover reasons to change assignments while going through the list of documents. In order to not cause a reviewer to make a false start on a review, the secretaries complete the full list of assignments before sending notifications to anyone. This assignment process can take several minutes and it is possible for new Last Calls to be issued while the secretary is making assignments. The secretary typically checks to see if new documents are ready for review just before issuing the assignments and updates the assignments if necessary.

态度秘书在查看文件清单时可能会发现更改任务的原因。为了避免评审员在评审中错误地开始,秘书在向任何人发送通知之前完成全部任务列表。此分配过程可能需要几分钟,并且在秘书进行分配时,可以发出新的最后呼叫。秘书通常在发布作业前检查新文件是否准备好供审查,并在必要时更新作业。

Some teams operate in more of a review-on-demand model. The Routing Area Directorate (RTG-dir), for example, primarily initiates reviews at the request of a Routing AD. They may also start an early review at the request of a WG chair. In either case, the reviewers are chosen manually from the pool of available reviewers driven by context rather than using a round-robin ordering.

有些团队更多地采用按需审查模式。例如,路由区域董事会(RTG dir)主要应路由广告的要求启动审查。他们也可以应工作组主席的要求启动早期审查。在这两种情况下,都是从上下文驱动的可用审阅者池中手动选择审阅者,而不是使用循环排序。

The issued assignments are either sent to the review team's email list or are emailed directly to the assigned reviewer. The assignments are reflected in the tool. For those teams handling different types of reviews (Last Call vs. Telechat, for example), the secretary typically processes the documents for each type of review separately, and potentially with different assignment criteria. In Gen-ART, for example, the Last Call reviewer for a document will almost always get the follow-up Telechat review assignment. Similarly, SecDir assigns any re-reviews of a document to the same reviewer. Other teams may choose to assign a different reviewer.

发布的作业将发送到审核团队的电子邮件列表,或直接通过电子邮件发送给指定的审核人。指定将反映在工具中。对于处理不同类型审查的团队(例如,最后一次电话与Telechat),秘书通常单独处理每种审查类型的文件,并且可能具有不同的分配标准。例如,在Gen ART中,文档的最后一次呼叫审阅者几乎总是会得到后续的Telechat审阅任务。同样,SecDir将对文档的任何重新审阅分配给同一审阅者。其他团队可能会选择指定不同的审阅者。

Reviewers discover their assignments through email or by looking at their queue in the tool. The secretaries for some teams (such as the OPS-dir and RTG-dir) insulate their team members from using the tool directly. These reviewers only work through the review team's email list or through direct email. On teams that have the reviewers use the tool directly, most reviewers only check the tool when they see they have an assignment via the team's email list. A reviewer has the opportunity to reject the assignment for any reason. While the tool provides a way to reject assignments, reviewers typically use email to coordinate rejections with the team secretary. The secretary will find another volunteer for any rejected assignments. The reviewer can indicate that the assignment is accepted in the tool before starting the review, but this feature is rarely used.

审阅者通过电子邮件或查看工具中的队列来发现他们的作业。某些团队的秘书(如OPS dir和RTG dir)将其团队成员与直接使用该工具隔离开来。这些审阅者只能通过审阅团队的电子邮件列表或直接电子邮件进行工作。在有审阅者直接使用该工具的团队中,大多数审阅者只有在通过团队的电子邮件列表看到他们有任务时才检查该工具。评审员有机会以任何理由拒绝作业。虽然该工具提供了一种拒绝任务的方法,但评审员通常使用电子邮件与团队秘书协调拒绝。秘书将为任何被拒绝的任务寻找另一名志愿者。在开始审阅之前,审阅者可以在工具中指示已接受分配,但很少使用此功能。

The reviewer sends a completed review to the team's email list or secretary, as well as any other lists relevant to the review, and usually the draft's primary email alias. For instance, many Last Call reviews are also sent to the IETF general list. The teams typically have a template format for the review. Those templates usually start with a summary of the conclusion of the review.

审阅者将完成的审阅发送给团队的电子邮件列表或秘书,以及与审阅相关的任何其他列表,通常是草稿的主要电子邮件别名。例如,许多最后的通话评论也被发送到IETF总列表。团队通常有一个评审模板格式。这些模板通常以审查结论的摘要开始。

Typical summaries are "ready for publication" or "on the right track but has open issues". The reviewer (or in the case of teams that insulate their reviewers, the secretary) uses the tool to indicate that the review is complete, provides the summary, and has an opportunity to provide a link to the review in the archives. Note, however, that having to wait for the document to appear in the archive to know the link to paste into the tool is a significant enough impedance that this link is often not provided by the reviewer. The SecDir secretary manually collects these links from the team's email list and adds them to the tool.

典型的摘要是“准备出版”或“在正确的轨道上,但有未解决的问题”。审核人(或在隔离审核人的团队中,秘书)使用该工具表示审核已完成,提供摘要,并有机会在档案中提供审核链接。但是,请注意,必须等待文档出现在存档中,才能知道要粘贴到工具中的链接,这是一个非常重要的阻抗,因此审阅者通常不提供此链接。SecDir秘书从团队的电子邮件列表中手动收集这些链接,并将其添加到工具中。

Occasionally, a document is revised between when a review assignment is made and when the reviewer starts the review. Different teams can have different policies about whether the reviewer should review the assigned version or the current version.

有时,在进行审核任务和审核人开始审核之间,会对文档进行修改。不同的团队可以有不同的策略来决定审阅者是应该审阅指定的版本还是当前版本。

3. Requirements
3. 要求
3.1. Secretariat Focused
3.1. 以秘书处为重点

o The Secretariat must be able to configure secretaries and reviewers for review teams (by managing Role records).

o 秘书处必须能够为审查小组配置秘书和审查员(通过管理角色记录)。

o The Secretariat must be able to perform any secretary action on behalf of a review team secretary (and thus, must be able to perform any reviewer action on behalf of the reviewer).

o 秘书处必须能够代表审查组秘书执行任何秘书行动(因此,必须能够代表审查员执行任何审查员行动)。

3.2. Review-Team Secretary Focused
3.2. 审查小组秘书重点

o A secretary must be able to see what documents are ready for a review of a given type (such as a Last Call review).

o 秘书必须能够看到哪些文件已准备好进行给定类型的审查(如最后一次电话审查)。

o A secretary must be able to assign reviews for documents that may not have been automatically identified as ready for a review of a given type. (In addition to being the primary assignment method for teams that only initiate reviews on demand, this allows the secretary to work around errors and handle special cases, including early review requests.)

o 秘书必须能够为可能未被自动识别为准备对给定类型进行审查的文件分配审查。(除了作为仅在需要时启动审查的团队的主要分配方法外,这还允许秘书处理错误并处理特殊情况,包括早期审查请求。)

o A secretary must be able to work on and issue a set of assignments as an atomic unit. No assignment should be issued until the secretary declares the set of assignments complete.

o 秘书必须能够作为一个原子单元处理和发布一系列任务。在秘书宣布任务完成之前,不得发布任何任务。

o The tool must support teams that have multiple secretaries. The tool should warn secretaries that are simultaneously working on assignments and protect against conflicting assignments being made.

o 该工具必须支持具有多个秘书的团队。该工具应警告同时处理任务的秘书,并防止发生冲突的任务。

o It must be easy for the secretary to discover that more documents have become ready for review while working on an assignment set.

o 秘书在处理任务集时,必须很容易发现更多的文件已准备好供审查。

o The tool should make preparing the assignment email to the team's email list easy. For instance, the tool could prepare the message, give the secretary an opportunity to edit it, and handle sending it to the team's email list.

o 该工具应使准备团队电子邮件列表中的任务电子邮件变得容易。例如,该工具可以准备消息,给秘书一个编辑消息的机会,并处理将消息发送到团队的电子邮件列表。

o It must be possible for a secretary to indicate that the review team will not provide a review for a document (or a given version of a document). This indication should be taken into account when presenting the documents that are ready for a review of a given type. This will also make it possible to show on a document's page that no review is expected from this team.

o 秘书必须能够表明审查小组不会对文件(或给定版本的文件)进行审查。在提交准备对给定类型进行审查的文件时,应考虑此指示。这还可以在文档页面上显示此团队不需要审查。

o A secretary must be able to easily see who the next available reviewers are, in order.

o 秘书必须能够很容易地看出谁是下一个可用的审稿人。

o A secretary must be able to edit a reviewer's availability, both in terms of frequency, not-available-until-date, and skip-next-n-assignments. (See the description of these settings in Section 3.3.)

o 秘书必须能够编辑审阅者的可用性,包括频率、日期前不可用以及跳过下一步n-任务。(参见第3.3节中对这些设置的说明。)

o The tool should make it easy for the secretary to see any team members that have requested to review a given document when it becomes available for review.

o 该工具应能使秘书在文件可供审查时,轻松看到任何要求审查给定文件的团队成员。

o The tool should make it easy for the secretary to identify that a reviewer is already involved with a document. The current tool allows the secretary to provide a regular expression to match against the document name. If the expression matches, the document is not available for assignment to this reviewer. For example, Tero will not be assigned documents matching '^draft-(kivinen|ietf-tcpinc)-.*$'. The tool should also take any roles, such as document shepherd, that the Datatracker knows about into consideration.

o 该工具应使秘书能够轻松确定审查人员已参与文件审查。当前工具允许秘书提供一个正则表达式来匹配文档名。如果表达式匹配,则文档无法分配给此审阅者。例如,不会为Tero分配与“^draft-(kivinen | ietf tcpinc)-.*$”匹配的文档。该工具还应该考虑Datatracker知道的任何角色,例如DocumentShepherd。

o The tool should make it easy for the secretary to see key features of a document ready for assignment, such as its length, its authors, the group and area it is associated with, its title and abstract, its states (such as IESG or WG states), and any other personnel (such as the shepherd and reviewers already assigned from other teams) involved in the draft.

o 该工具应使秘书容易看到准备分配的文件的关键特征,如文件长度、作者、与之相关的组和区域、标题和摘要、状态(如IESG或WG状态)以及任何其他人员(如已从其他团队分配的shepherd和审阅者)参与起草。

o The tool must make it easy for the secretary to detect and process re-review requests on the same version of a document (such as when a document has an additional Last Call only to deal with new IPR information).

o 该工具必须使部长能够方便地检测和处理同一版本文件的复审请求(例如,当一份文件有额外的最后一次调用,仅用于处理新的知识产权信息时)。

o Common operations to groups of documents should be easy for the secretary to process as a group with a minimum amount of interaction with the tool. For instance, it should be possible to process all of the documents described by the immediately preceding bullet with one action. Similarly, for teams that assign re-reviews to the same reviewer, issuing all re-review requests should be a simple action.

o 文件组的常见操作应便于秘书作为一个组进行处理,且与工具的交互量最少。例如,应该可以通过一个操作处理前一个项目符号描述的所有文档。同样,对于将重新审核分配给同一审核人的团队,发出所有重新审核请求应该是一个简单的操作。

o A secretary must be able to see which reviewers have outstanding assignments.

o 秘书必须能够看到哪些审稿人有未完成的任务。

o The tool must make it easy for the secretary to see the result of previous reviews from this team for a given document. In SecDir, for example, if the request is for a revision that has only minor differences and the previous review result was "Ready", a new assignment will not be made. If the given document replaces one or more other prior documents, the tool must make it easy for the secretary to see the results of previous reviews of the replaced documents.

o 该工具必须使秘书能够方便地查看该团队以前对给定文档的审查结果。例如,在SecDir中,如果请求的修订只有微小的差异,且先前的审查结果为“就绪”,则不会进行新的分配。如果给定文件替换了一个或多个以前的文件,则该工具必须使部长能够轻松查看以前对替换文件的审查结果。

o The tool must make it easy for the secretary to see the result of previous reviews from this team for all documents across configurable, recent periods of time (such as the last 12 months). A secretary of the RTG-dir, for example, would use this result to aid in the manual selection of the next reviewer.

o 该工具必须使秘书能够方便地查看该团队在最近一段时间(如过去12个月)内对所有文件的先前审查结果。例如,RTG dir的秘书将使用此结果来帮助手动选择下一位审核人。

o The tools must make it easy for the secretary to see the recent performance of a reviewer while making an assignment (see Section 3.5). This allows the secretary to detect overburdened or unresponsive volunteers earlier in the process.

o 这些工具必须使秘书在分配任务时能够方便地查看审阅者最近的表现(见第3.5节)。这使秘书能够在过程的早期发现负担过重或反应迟钝的志愿者。

o A secretary must be able to configure the tool to remind them to follow up when actions are due. (For instance, a secretary could receive email when a review is about to become overdue.)

o 秘书必须能够配置工具,提醒他们在行动到期时跟进。(例如,当审查即将过期时,秘书可能会收到电子邮件。)

o A secretary must be able to assign multiple reviewers to a given draft at any time. In particular, a secretary must be able to assign an additional reviewer when an original reviewer indicates their review is likely to be only partially complete.

o 秘书必须能够在任何时候为给定的草稿指派多个审阅者。特别是,当原始审核人表示他们的审核可能仅部分完成时,秘书必须能够指派额外的审核人。

o A secretary must be able to withdraw a review assignment.

o 秘书必须能够撤回审查任务。

o A secretary must be able to perform any reviewer action on behalf of the reviewer.

o 秘书必须能够代表审核人执行任何审核人操作。

o A secretary must be able to configure the review team's set of reviewers (by managing Role records for the team).

o 秘书必须能够配置审核团队的审核人员集(通过管理团队的角色记录)。

o Information about a reviewer must not be lost when a reviewer is removed from a team. (Frequently, reviewers come back to teams later.)

o 从团队中删除审阅者时,有关审阅者的信息不得丢失。(通常,评审人员稍后会回到团队。)

o A secretary must be able to delegate secretary capabilities in the tool (similar to how a working group chair can assign a Delegate). This allows review teams to self-manage secretary vacations.

o 秘书必须能够在工具中委派秘书能力(类似于工作组主席委派代表的方式)。这允许审核团队自行管理秘书休假。

3.3. Reviewer Focused
3.3. 以评论员为中心

o A reviewer must be able to indicate availability, both in frequency of reviews and as "not available until this date". The current tool speaks of frequency in these terms:

o 审核人必须能够指出可用性,包括审核频率和“在此日期之前不可用”。当前工具使用以下术语来描述频率:

- Assign at maximum one new review per week

- 每周最多分配一次新审核

- Assign at maximum one new review per fortnight

- 每两周最多分配一次新审核

- Assign at maximum one new review per month

- 每月最多分配一次新审核

- Assign at maximum one new review per two months

- 每两个月最多分配一次新审核

- Assign at maximum one new review per quarter

- 每季度最多分配一次新审核

o Reviewers must be able to indicate hiatus periods. Each period may be either "soft" or "hard".

o 评审员必须能够指出中断期。每个周期可以是“软”或“硬”。

- A hiatus must have a start date. It may have an end date or it may be indefinite.

- 中断必须有开始日期。它可能有一个结束日期,也可能是不确定的。

- During a hiatus, the reviewer will not be included in the normal review rotation. When a provided end date is reached, the reviewer will automatically be included in the rotation in their usual order.

- 在休息期间,评审员将不包括在正常的评审轮换中。当达到规定的结束日期时,审核人将自动按其通常顺序加入轮换。

- During a "soft" hiatus, the reviewer must not be assigned new reviews but is expected to complete existing assignments and do follow-up reviews.

- 在“软”中断期间,不得向审核人分配新的审核,但应完成现有的任务并进行后续审核。

- During a "hard" hiatus, the reviewer must not be assigned any new reviews and the secretary must be prompted to reassign any outstanding or follow-up reviews.

- 在“硬”中断期间,不得向审核人分配任何新的审核,且必须提示秘书重新分配任何未完成或后续审核。

o Reviewers must be able to indicate that they should be skipped the next "n" times they would normally have received an assignment.

o 评审员必须能够指出,在下一次“n”次他们通常会收到作业时,他们应该被跳过。

o Reviewers must be able to indicate that they are transitioning to inactive and provide a date for the end of the transition period. During this transition time, the reviewer must not be assigned new reviews but is expected to complete outstanding assignments and follow-up reviews. At the end of the transition period, the secretary must be prompted to reassign any outstanding or follow-up reviews. (This allows review-team members that are taking on AD responsibility to transition gracefully to an inactive state for the team.)

o 审核人必须能够指出他们正在过渡到非活动状态,并提供过渡期结束的日期。在此过渡期间,不得向审核人分配新的审核,但应完成未完成的任务和后续审核。在过渡期结束时,必须提示秘书重新分配任何未完成或后续审查。(这允许承担AD责任的审核团队成员优雅地过渡到团队的非活动状态。)

o Both the reviewer and the secretary will be notified by email of any modifications to a reviewer's availability.

o 审核人和秘书都将收到对审核人可用性的任何修改的电子邮件通知。

o A reviewer must be able to easily discover new review assignments. (The tool might send email directly to an assigned reviewer in addition to sending the set of assignments to the team's email list. The tool might also use the Django Message framework to let a reviewer that's logged into the Datatracker know a new review assignment has been made.)

o 审阅者必须能够轻松发现新的审阅任务。(除了将一组工作分配发送到团队的电子邮件列表之外,该工具还可以直接向指定的审阅者发送电子邮件。该工具还可以使用Django消息框架让登录到Datatracker的审阅者知道已进行了新的审阅分配。)

o Reviewers must be able to see their current set of outstanding assignments, completed assignments, and rejected assignments. The presentation of those sets should either be separate or, if combined, the sets should be visually distinct.

o 审阅者必须能够查看其当前未完成的作业集、已完成的作业集和已拒绝的作业集。这些集合的呈现应该是单独的,或者,如果组合在一起,集合应该在视觉上是不同的。

o A reviewer should be able to request to review a particular document. The draft may be in any state: available and unassigned; already assigned to another reviewer; or not yet available.

o 审阅者应该能够请求审阅特定文档。汇票可以处于任何状态:可用和未分配;已分配给其他审阅者;或者还没有。

o A reviewer must be able to reject a review assignment, optionally providing the secretary with an explanation for the rejection. The tool will notify the secretary of the rejection by email.

o 审查员必须能够拒绝审查任务,并可选择向秘书提供拒绝的解释。该工具将通过电子邮件通知秘书拒绝。

o A reviewer must be able to indicate that they have accepted and are working on an assignment.

o 审核人必须能够表明他们已接受并正在处理作业。

o A reviewer must be able to indicate that a review is only partially completed and ask the secretary to assign an additional reviewer. The tool will notify the secretary of this condition by email.

o 审核人必须能够指出审核仅部分完成,并要求秘书指定一名额外的审核人。该工具将通过电子邮件通知秘书该情况。

o It should be possible for a reviewer to reject or accept a review either by using the tool's web interface or by replying to the review assignment email.

o 评审员可以通过使用工具的web界面或回复评审分配电子邮件来拒绝或接受评审。

o It must be easy for a reviewer to see when each assigned review is due.

o 审核人必须很容易看到每次指定的审核何时到期。

o A reviewer must be able to configure the tool to remind them when actions are due. (For instance, a reviewer could receive email when a review is about to become overdue).

o 审阅者必须能够配置工具,以便在操作到期时提醒他们。(例如,当审核即将过期时,审核人可能会收到电子邮件)。

o A reviewer must be able to indicate that a review is complete, capturing where the review is in the archives and the high-level, review-result summary.

o 评审员必须能够指出评审已完成,并记录评审在档案中的位置和高级评审结果摘要。

o It must be possible for a reviewer to clearly indicate which version of a document was reviewed. Documents are sometimes revised between when a review was assigned and when it is due. The tool should note the current version of the document and highlight when the review is not for the current version.

o 审阅者必须能够清楚地指出已审阅的文档版本。文件有时会在指定审查和到期审查之间进行修订。该工具应注意文档的当前版本,并在审查不针对当前版本时突出显示。

o It must be easy for a reviewer to submit a completed review.

o 审核人提交完整的审核必须很容易。

- The current workflow, where the reviewer sends email to the team's email list (possibly copying other lists) and then indicates where to find that review, must continue to be supported. The tool should make it easier to capture the link to review in the team's email list archives (perhaps by suggesting links based on a search into the archives).

- 必须继续支持当前工作流,即审阅者将电子邮件发送到团队的电子邮件列表(可能复制其他列表),然后指示在何处查找该审阅。该工具应该可以更容易地在团队的电子邮件列表存档中捕获要查看的链接(可能是通过建议基于对存档搜索的链接)。

- The tool should allow the reviewer to enter the review into the tool via a web form (either as directly provided text or through a file-upload mechanism). The tool will ensure the review is posted to the appropriate lists and will construct the links to those posts in the archives.

- 该工具应允许审阅者通过web表单(作为直接提供的文本或通过文件上载机制)将审阅输入该工具。该工具将确保审查被张贴到适当的名单上,并将构建到档案中这些帖子的链接。

- The tool could also allow the reviewer to submit the review to the tool by email (perhaps by replying to the assignment). The tool would then ensure the review is posted to the appropriate lists.

- 该工具还允许审阅者通过电子邮件(可能通过回复作业)将审阅提交给该工具。然后,该工具将确保将审查发布到适当的列表中。

3.4. Review Requester and Consumer Focused
3.4. 以请求者和消费者为中心进行审查

o It should be easy for an AD or group chair to request any type of review, but particularly an early review, from a review team.

o 广告或小组主席可以很容易地要求审查团队进行任何类型的审查,尤其是早期审查。

o It should be possible for that person to withdraw a review request.

o 该人员应该可以撤回审查请求。

o It must be easy to find all reviews of a document when looking at the document's main page in the Datatracker. The reference to the review must make it easy to see any responses to the review on the email lists it was sent to. If a document "replaces" one or more other documents, reviews of the replaced documents should be included in the results.

o 在Datatracker中查看文档的主页时,必须很容易找到文档的所有评论。对评论的引用必须使其在发送到的电子邮件列表上容易看到对评论的任何回复。如果一份文件“替换”了一份或多份其他文件,则应在结果中包括对替换文件的审查。

o It must be easy to find all reviews of a document when looking at search result pages and other lists of documents, such as the documents on an IESG Telechat agenda.

o 在查看搜索结果页面和其他文档列表(如IESG Telechat议程上的文档)时,必须很容易找到文档的所有评论。

3.5. Statistics Focused
3.5. 以统计为重点

o It must be easy to see the following across all teams, a given team, or a given reviewer, and independently across all time or across configurable recent periods of time:

o 在所有团队、给定团队或给定审阅者之间,以及在所有时间段或在可配置的最近时间段内,必须很容易看到以下内容:

- how many reviews have been completed

- 已经完成了多少次审查

- how many reviews are in progress

- 有多少审查正在进行

- how many in progress reviews are late

- 有多少正在进行的审查迟到了

- how many completed reviews were late

- 有多少已完成的审查迟到了

- how many reviews were not completed at all

- 有多少审查根本没有完成

- average time to complete reviews (from assignment to completion)

- 完成审查的平均时间(从任务到完成)

o It must be easy to see the following for all teams, for a given team, or for a given reviewer, across all time or across configurable recent periods:

o 对于所有团队、给定团队或给定审阅者,在所有时间段或最近的时间段内,必须容易看到以下内容:

- total counts of reviews in each review state (done, rejected, etc.)

- 每个审核状态下的审核总数(完成、拒绝等)

- total counts of completed reviews by result (ready, ready with nits, etc.)

- 按结果列出的已完成审查总数(就绪、就绪、具有NIT等)

o The above statistics should also be calculated reflecting the size of the documents being reviewed (such as using the number of pages or words in the documents).

o 还应计算上述统计数据,以反映所审查文件的大小(例如使用文件中的页数或字数)。

o Where applicable, statistics should take reviewer hiatus periods into account.

o 在适用的情况下,统计数据应考虑审核人的中断期。

o Access to the above statistics must be easy to configure. Access will be initially limited as follows:

o 访问上述统计信息必须易于配置。最初的访问限制如下:

- The Secretariat and ADs can see any statistic.

- 秘书处和ADs可以看到任何统计数据。

- A team secretary can see any statistics for that team.

- 团队秘书可以查看该团队的任何统计数据。

- A reviewer can see any team aggregate statistics or their own reviewer-specific statistics.

- 审阅者可以查看任何团队聚合统计信息或他们自己的审阅者特定统计信息。

o Where possible, the above statistics should be visible as a time-series graph.

o 在可能的情况下,上述统计数据应以时间序列图的形式显示。

o The implementation should anticipate future enhancements that would allow ADs to indicate their position was informed by a given review. Such enhancements would allow reporting correlations between reviews and documents that receive one or more "discusses". However, implementing these enhancements is not part of the current project.

o 实施应预见到未来的增强,这将允许ADs表明他们的立场是由给定的审查通知的。这种改进将允许报告审查和收到一个或多个“讨论”的文件之间的相关性。但是,实现这些增强不是当前项目的一部分。

4. Security Considerations
4. 安全考虑

This document discusses requirements for tools that assist review teams. These requirements do not affect the security of the Internet in any significant fashion. The tools themselves have authentication and authorization considerations (team secretaries will be able to do different things than reviewers).

本文件讨论了协助评审小组的工具的要求。这些要求不会以任何显著方式影响互联网的安全。这些工具本身有身份验证和授权方面的考虑(团队秘书将能够做与审阅者不同的事情)。

5. Informative References
5. 资料性引用

[AppsDir] IETF, "Applications Area Directorate Review Process", <http://trac.tools.ietf.org/area/app/trac/wiki/ AppsDirReview>.

[AppsDir]IETF,“应用领域董事会审查流程”<http://trac.tools.ietf.org/area/app/trac/wiki/ AppsView>。

[art-trac] IETF, "Area Review Team Tool: {1} Active Tickets", <https://wiki.tools.ietf.org/tools/art/trac/report/1>.

[art trac]IETF,“区域审查小组工具:{1}个活动票证”<https://wiki.tools.ietf.org/tools/art/trac/report/1>.

[Gen-ART] IETF, "General Area: General Area Review Team (GEN-ART) Guidelines", <http://trac.tools.ietf.org/area/gen/trac/wiki>.

[Gen-ART]IETF,“一般领域:一般领域审查小组(Gen-ART)指南”<http://trac.tools.ietf.org/area/gen/trac/wiki>.

[MIBdoctors] IETF, "MIB Doctors", <http://www.ietf.org/iesg/directorate/mib-doctors.html>.

[MIB医生]IETF,“MIB医生”<http://www.ietf.org/iesg/directorate/mib-doctors.html>.

[OPS-dir] IETF, "OPS Directorate (OPS-DIR)", <https://svn.tools.ietf.org/area/ops/trac/wiki/ Directorates>.

[OPS-dir]IETF,“OPS-dir”<https://svn.tools.ietf.org/area/ops/trac/wiki/ 董事会>。

[RFC6385] Barnes, M., Doria, A., Alvestrand, H., and B. Carpenter, "General Area Review Team (Gen-ART) Experiences", RFC 6385, DOI 10.17487/RFC6385, October 2011, <http://www.rfc-editor.org/info/rfc6385>.

[RFC6385]Barnes,M.,Doria,A.,Alvestrand,H.,和B.Carpenter,“一般区域审查团队(Gen ART)经验”,RFC 6385,DOI 10.17487/RFC6385,2011年10月<http://www.rfc-editor.org/info/rfc6385>.

[RTG-dir] IETF, "Routing Area Directorate Wiki Page", <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>.

[RTG dir]IETF,“路由区域董事会Wiki页面”<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>.

[SecDir] IETF, "Security Directorate", <http://trac.tools.ietf.org/area/sec/trac/wiki/ SecurityDirectorate>.

[SecDir]IETF,“安全理事会”<http://trac.tools.ietf.org/area/sec/trac/wiki/ 安全理事会>。

[YANGdoctors] IETF, "YANG Doctors", <http://www.ietf.org/iesg/directorate/yang-doctors.html>.

[阳医]IETF,“阳医”<http://www.ietf.org/iesg/directorate/yang-doctors.html>.

Appendix A. A Starting Point for Django Models Supporting the Review Tool

附录A.支持审查工具的Django模型的起点

from django.db import models from ietf.doc.models import Document from ietf.person.models import Email from ietf.group.models import Group, Role

从django.db从ietf.doc.models导入模型从ietf.person.models导入文档从ietf.group.models导入电子邮件导入组,角色

from ietf.name.models import NameModel

从ietf.name.models导入NameModel

class ReviewRequestStateName(NameModel): """ Requested, Accepted, Rejected, Withdrawn, Overtaken By Events, No Response , Completed """

类ReviewRequestStateName(NameModel):“请求、接受、拒绝、撤回、被事件超越、无响应、已完成”

class ReviewTypeName(NameModel): """ Early Review, Last Call, Telechat """

类ReviewTypeName(NameModel):“早期回顾、最后一次呼叫、Telechat”

class ReviewResultName(NameModel): """Almost ready, Has issues, Has nits, Not Ready, On the right track, Ready, Ready with issues, Ready with nits, Serious Issues"""

类ReviewResultName(NameModel):“几乎准备就绪,有问题,有NIT,未准备就绪,在正确的轨道上,准备就绪,有问题,有NIT,严重问题”

 class Reviewer(models.Model):
     """
     These records associate reviewers with review teams and keep track
     of admin data associated with the reviewer in the particular team.
     There will be one record for each combination of reviewer and team.
     """
     role        = models.ForeignKey(Role)
     frequency   = models.IntegerField(help_text=
                                   "Can review every N days")
     available   = models.DateTimeField(blank=True,null=True, help_text=
                         "When will this reviewer be available again")
     filter_re   = models.CharField(blank=True)
     skip_next   = models.IntegerField(help_text=
                          "Skip the next N review assignments")
        
 class Reviewer(models.Model):
     """
     These records associate reviewers with review teams and keep track
     of admin data associated with the reviewer in the particular team.
     There will be one record for each combination of reviewer and team.
     """
     role        = models.ForeignKey(Role)
     frequency   = models.IntegerField(help_text=
                                   "Can review every N days")
     available   = models.DateTimeField(blank=True,null=True, help_text=
                         "When will this reviewer be available again")
     filter_re   = models.CharField(blank=True)
     skip_next   = models.IntegerField(help_text=
                          "Skip the next N review assignments")
        

class ReviewResultSet(models.Model): """ This table provides a way to point out a set of ReviewResultName entries that are valid for a given team in order to be able to limit the result choices that can be set for a given review as a function of which team it is related to. """ team = models.ForeignKey(Group) valid = models.ManyToManyField(ReviewResultName)

类ReviewResultSet(models.Model):“此表提供了一种方法,可以指出一组对给定团队有效的ReviewResultName条目,以便能够限制可以为给定审阅设置的结果选择,将其作为与之相关的团队的函数。”“team=models.ForeignKey(Group)valid=models.ManyToManyField”(ReviewResultName)

 class ReviewRequest(models.Model):
     """
     There should be one ReviewRequest entered for each combination of
     document, rev, and reviewer.
     """
     # Fields filled in on the initial record creation:
     time          = models.DateTimeField(auto_now_add=True)
     type          = models.ReviewTypeName()
     doc           = models.ForeignKey(Document,
                            related_name='review_request_set')
     team          = models.ForeignKey(Group)
     deadline      = models.DateTimeField()
     requested_rev = models.CharField(verbose_name="requested_revision",
                             max_length=16, blank=True)
     state         = models.ForeignKey(ReviewRequestStateName)
     # Fields filled in as reviewer is assigned, and as the review
     # is uploaded
     reviewer      = models.ForeignKey(Reviewer, null=True, blank=True)
     review        = models.OneToOneField(Document, null=True,
                                                    blank=True)
     reviewed_rev  = models.CharField(verbose_name="reviewed_revision",
                                      max_length=16, blank=True)
     result        = models.ForeignKey(ReviewResultName)
        
 class ReviewRequest(models.Model):
     """
     There should be one ReviewRequest entered for each combination of
     document, rev, and reviewer.
     """
     # Fields filled in on the initial record creation:
     time          = models.DateTimeField(auto_now_add=True)
     type          = models.ReviewTypeName()
     doc           = models.ForeignKey(Document,
                            related_name='review_request_set')
     team          = models.ForeignKey(Group)
     deadline      = models.DateTimeField()
     requested_rev = models.CharField(verbose_name="requested_revision",
                             max_length=16, blank=True)
     state         = models.ForeignKey(ReviewRequestStateName)
     # Fields filled in as reviewer is assigned, and as the review
     # is uploaded
     reviewer      = models.ForeignKey(Reviewer, null=True, blank=True)
     review        = models.OneToOneField(Document, null=True,
                                                    blank=True)
     reviewed_rev  = models.CharField(verbose_name="reviewed_revision",
                                      max_length=16, blank=True)
     result        = models.ForeignKey(ReviewResultName)
        
Appendix B. Suggested Features Deferred for Future Work
附录B.推迟到未来工作的建议特征

Brian Carpenter suggested a set of author/editor-focused requirements that were deferred for another iteration of improvement. These include providing a way for the editors to acknowledge receipt of the review, potentially tracking the email conversation between the reviewer and document editor, and indicating which review topics the editor believes a new revision addresses.

Brian Carpenter提出了一组以作者/编辑为中心的需求,这些需求被推迟到下一次改进迭代中。其中包括为编辑提供一种确认收到评论的方式,潜在地跟踪评论人和文档编辑之间的电子邮件对话,并指出编辑认为新修订版涉及的评论主题。

Acknowledgements

致谢

Tero Kivinen and Henrik Levkowetz were instrumental in forming this set of requirements and in developing the initial Django models in the appendix.

Tero Kivinen和Henrik Levkowetz在形成这组需求和开发附录中的初始Django模型方面发挥了重要作用。

The following people provided reviews of this document: David Black, Deborah Brungard, Brian Carpenter, Elwyn Davies, Stephen Farrell, Joel Halpern, Jonathan Hardwick, Russ Housley, Barry Leiba, Jean Mahoney, Randy Presuhn, Gunter Van De Velde, and Martin Vigoureux.

以下人员提供了该文件的评论:大卫·布莱克、黛博拉·布伦加德、布赖恩·卡彭特、埃尔温·戴维斯、斯蒂芬·法雷尔、乔尔·哈尔佩恩、乔纳森·哈德威克、罗斯·霍斯利、巴里·莱巴、让·马奥尼、兰迪·普雷森、冈特·范德维尔德和马丁·维古鲁。

Authors' Addresses

作者地址

Robert Sparks Oracle 7460 Warren Parkway Suite 300 Frisco, Texas 75034 United States

Robert Sparks Oracle 7460 Warren Parkway套房300美国德克萨斯州弗里斯科75034

   Email: rjsparks@nostrum.com
        
   Email: rjsparks@nostrum.com
        

Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 Finland

Tero Kivinen INSIDE Kinkatu 28赫尔辛基FI-00180芬兰

   Email: kivinen@iki.fi
        
   Email: kivinen@iki.fi