[要約] RFC 7735は、ドキュメントのレビューを追跡するためのプロトコルを提案しています。その目的は、効果的なドキュメントレビュープロセスを確立し、レビューの進捗状況を追跡することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
インターネットドラフトが処理されると、いくつかのレビューチームからレビューが要求されます。たとえば、General Area Review Team（Gen-ART）とSecurity Directorate（SecDir）は、IETF Last Callにあるドキュメントのレビューを実行します。 Gen-ARTは、ドキュメントがIESG Telechatにスケジュールされるときに、常にフォローアップレビューを実行します。 SecDirは通常、フォローアップレビューを実行しますが、SecDir秘書は、Last Callで特定された問題に対処し、それ以外にドキュメントに大きな変更がない場合、そのフォローアップを要求しないことを選択できます。これらのチームは、オンデマンドでドキュメントの以前のレビューも実行します。同様のサービスを実行する他のいくつかのチームがあり、多くの場合、専門分野に焦点を当てています。
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テレチャットの日付が原因です。レビュー担当者は、完了した各レビューをチームのメーリングリストと、レビュー対象のドキュメントに関連する他のリストに送信します。多くの場合、レビューで見つかった問題を解決するために、これらのリストの1つ以上にスレッドが続きます。
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 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].
いくつかのチームの秘書とレビュー担当者は、Tero Kivinenが開発および保守しているツールを使用しています。その設計の多くは、最新のDatatrackerよりも古いものです。現在、アプリケーションは独自のデータストアを保持しており、Datatrackerとtools.ietf.orgのページを調べることにより、レビューが必要なドキュメントについて学習します。これらのページのほとんどは解析が簡単ですが、特にLast Callページは多少の労力を必要とします。 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] |
+-------------------------------+---------------------+
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 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.
多くのチームでは、チームの秘書が定期的（通常は週に1回）に、レビューの準備ができていると識別したドキュメントについてツールをチェックします。このツールは、ラストコールのお知らせとIESG Telechatの議題からリストを作成します。秘書はこのリストから割り当てのセットを作成し、それらをレビューアプールに入力して、大まかにラウンドロビンの順序でレビューアを選択します。その順序は、いくつかの要因によって混乱する可能性があります。レビュー担当者には、さまざまなレベルの可用性があります。月に複数の文書をレビューすることをいとわない人もいます。他の人は隔月でしかドキュメントをレビューする気がないかもしれません。割り当てプロセスでは、校閲者の休暇などの例外的な条件が考慮されます。さらに、秘書は、作成者、羊飼い、責任あるWGの議長であるレビュー担当者にドキュメントを割り当てたり、ドキュメントと他の既存の関連付けを持たないように注意します。フレッシュな視点を持つレビュアーを得ることが優先されます。秘書は、ドキュメントのリストを参照しながら、割り当てを変更する理由を見つける場合があります。レビュー担当者が誤ってレビューを開始しないようにするために、秘書は誰にでも通知を送信する前に割り当ての完全なリストを完成させます。この割り当てプロセスには数分かかる場合があり、秘書が割り当てを行っている間に新しいラストコールが発行される可能性があります。秘書は通常、割り当てを発行する直前に新しいドキュメントがレビューできる状態かどうかを確認し、必要に応じて割り当てを更新します。
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.
一部のチームは、より多くのレビューオンデマンドモデルで活動しています。たとえば、Routing Area Directorate（RTG-dir）は、主にルーティングADの要求でレビューを開始します。また、WG議長の要請により、早期レビューを開始することもできます。どちらの場合でも、レビュアーは、ラウンドロビン順序付けを使用するのではなく、コンテキストによって駆動される利用可能なレビュアーのプールから手動で選択されます。
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.
発行された割り当ては、レビューチームの電子メールリストに送信されるか、割り当てられたレビュー担当者に直接電子メールで送信されます。割り当てはツールに反映されます。異なるタイプのレビュー（ラストコールとテレチャットなど）を扱うチームの場合、秘書は通常、各タイプのレビューのドキュメントを個別に、場合によっては異なる割り当て基準で処理します。たとえば、Gen-ARTでは、ドキュメントのラストコールレビューアは、ほとんどの場合、フォローアップのテレチャットレビュー割り当てを取得します。同様に、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.
場合によっては、レビューの割り当てが行われてから、レビュー担当者がレビューを開始するまでの間にドキュメントが改訂されます。レビュー担当者が割り当てられたバージョンと現在のバージョンのどちらをレビューするかについて、チームごとに異なるポリシーを設定できます。
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 事務局は、レビューチームの秘書に代わって任意の秘書アクションを実行できなければなりません（したがって、レビュアーに代わってレビュアーアクションを実行できなければなりません）。
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 秘書は、頻度、not-available-until-date、およびskip-next-n-assignmentsの両方に関して、レビュー担当者の空席状況を編集できる必要があります。 （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が認識しているすべての役割も考慮する必要があります。
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など）など、割り当て可能なドキュメントの主要な機能を秘書が簡単に確認できるようになります状態）、およびドラフトに関与したその他の担当者（シェパードや他のチームから既に割り当てられているレビュー担当者など）。
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 このツールは、同じバージョンのドキュメントに対する再レビュー要求を秘書が簡単に検出して処理できるようにする必要があります（ドキュメントに新しいIPR情報のみを処理するための追加のLast Callがある場合など）。
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 ドキュメントのグループに対する一般的な操作は、秘書がツールとして最小限の操作でグループとして処理できるようにする必要があります。たとえば、直前の箇条書きで説明したすべてのドキュメントを1つのアクションで処理できるようにする必要があります。同様に、同じレビュー担当者に再レビューを割り当てるチームの場合、すべての再レビューリクエストを発行するのは簡単なアクションです。
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では、要求がわずかな違いしかないリビジョンに対するものであり、以前のレビュー結果が「準備完了」だった場合、新しい割り当ては行われません。特定のドキュメントが1つ以上の他の以前のドキュメントを置き換える場合、ツールは、秘書が置き換えられたドキュメントの以前のレビューの結果を簡単に確認できるようにする必要があります。
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 秘書は、ツールで秘書機能を委任できる必要があります（ワーキンググループの議長が委任を割り当てる方法と同様）。これにより、レビューチームは秘書休暇を自己管理できます。
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
- 毎週最大1つの新しいレビューを割り当てます
- Assign at maximum one new review per fortnight
- 2週間ごとに最大1つの新しいレビューを割り当てます
- Assign at maximum one new review per month
- 1か月あたり最大1つの新しいレビューを割り当てます
- Assign at maximum one new review per two months
- 2か月に最大1つの新しいレビューを割り当てます
- Assign at maximum one new review per quarter
- 四半期ごとに最大1つの新しいレビューを割り当てます
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 レビュー担当者は、ツールのウェブインターフェースを使用するか、レビューの割り当てメールに返信することで、レビューを拒否または受け入れることができます。
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.
- このツールでは、レビュー担当者が電子メールで（おそらく割り当てに返信することにより）レビューをツールに送信することもできます。ツールは、レビューが適切なリストに投稿されていることを確認します。
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 ADまたはグループの議長が、レビューチームに任意のタイプのレビュー、特に初期のレビューをリクエストするのは簡単なはずです。
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 データトラッカーでドキュメントのメインページを見ると、ドキュメントのすべてのレビューを簡単に見つけることができる必要があります。レビューへの参照により、送信されたメーリングリストでレビューへの返信を簡単に確認できる必要があります。ドキュメントが1つ以上の他のドキュメントを「置き換える」場合、置き換えられたドキュメントのレビューを結果に含める必要があります。
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の議題にあるドキュメントなど、検索結果ページやその他のドキュメントリストを見ると、ドキュメントのすべてのレビューを簡単に見つけることができます。
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.
- 事務局とADは任意の統計を見ることができます。
- 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 実装では、ADが自分の立場が所定のレビューによって通知されたことを示すことができる将来の機能拡張を予測する必要があります。このような機能強化により、レビューと1つ以上の「ディスカッション」を受け取るドキュメントとの間の相関関係を報告できます。ただし、これらの拡張機能の実装は現在のプロジェクトの一部ではありません。
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).
このドキュメントでは、レビューチームを支援するツールの要件について説明します。これらの要件は、インターネットのセキュリティには大きな影響を与えません。ツール自体には認証と承認に関する考慮事項があります（チームの秘書はレビュアーとは異なることができます）。
[AppsDir] IETF, "Applications Area Directorate Review Process", <http://trac.tools.ietf.org/area/app/trac/wiki/ AppsDirReview>.
[AppsDir] IETF、「Applications Area Directorate Review Process」、<http://trac.tools.ietf.org/area/app/trac/wiki/ AppsDirReview>。
[art-trac] IETF, "Area Review Team Tool: {1} Active Tickets", <https://wiki.tools.ietf.org/tools/art/trac/report/1>.
[art-trac] IETF、「Area Review Team Tool：{1} Active Tickets」、<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、「General Area：General Area Review Team（GEN-ART）Guidelines」、<http://trac.tools.ietf.org/area/gen/trac/wiki>。
[MIBdoctors] IETF, "MIB Doctors", <http://www.ietf.org/iesg/directorate/mib-doctors.html>.
[MIBdoctors] IETF、「MIB Doctors」、<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 Directorate（OPS-DIR）」、<https://svn.tools.ietf.org/area/ops/trac/wiki/ Directorates>。
[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、「General Area Review Team（Gen-ART）Experiences」、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、「Routing Area Directorate Wiki Page」、<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、「Security Directorate」、<http://trac.tools.ietf.org/area/sec/trac/wiki/SecurityDirectorate>。
[YANGdoctors] IETF, "YANG Doctors", <http://www.ietf.org/iesg/directorate/yang-doctors.html>.
[YANGdoctors] IETF、「YANG Doctors」、<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からインポートimport 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）： "" "早期レビュー、最終通話、電話" ""
class ReviewResultName(NameModel): """Almost ready, Has issues, Has nits, Not Ready, On the right track, Ready, Ready with issues, Ready with nits, Serious Issues"""
class 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 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)
class 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)
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.
ブライアン・カーペンターは、著者/編集者に焦点を合わせた一連の要件を提案し、改善の別の反復のために延期されました。これには、編集者がレビューの受信を確認する方法を提供すること、レビュー担当者とドキュメントエディター間の電子メールの会話を追跡すること、および編集者が新しいリビジョンで対応すると考えるレビュートピックを示すことが含まれます。
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.
次の人々がこのドキュメントのレビューを提供しました：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、Martin Vigoureux 。
Authors' Addresses
著者のアドレス
Robert Sparks Oracle 7460 Warren Parkway Suite 300 Frisco, Texas 75034 United States
Robert Sparks Oracle 7460 Warren Parkway Suite 300フリスコ、テキサス75034アメリカ合衆国
Email: rjsparks@nostrum.com
Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 Finland
Tero Kivinen INSIDE Secure Eerikinkatu 28ヘルシンキFI-00180フィンランド
Email: kivinen@iki.fi