RFC 7735
Tracking Reviews of Documents
Tracking Reviews of Documents ✨
Internet Engineering Task Force (IETF) · Category: Informational 🎀 · Date: January 2016 📅 · ISSN: 2070-1721 🦋
Okay bestie, this one is all about the review teams 💅. The authors are R. Sparks (Oracle) and T. Kivinen (INSIDE Secure) 🫶. It's an Informational doc, so it's not a Standards Track spec, and it doesn't obsolete or update anything. It just gives requirements for making the review-tracking tools work better 🌸.
Abstract ✨
Okay so, several review teams make sure specific kinds of review happen on Internet-Drafts as they march toward becoming RFCs 🧚. The tools these teams use to assign and track reviews would be so much better with tighter integration to the Datatracker 💖. This doc talks about requirements for upgrading those tools without disrupting the workflows people already rely on 🫶.
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, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🔥.
Info about the current status of this doc, any errata, and how to give feedback is at 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 🦋.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date of publication 📜. Please read these carefully, because they describe your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the 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 . . . . . . . . . . . . . . . . . . . . . . . 161. Introduction 🌸
Okay so, as Internet-Drafts get processed, reviews are requested from a bunch of review teams 🎀. For example, the General Area Review Team (Gen-ART) and the Security Directorate (SecDir) review documents that are in IETF Last Call 💅. Gen-ART always does a follow-up review when the document is scheduled for an IESG Telechat ✨. SecDir usually does a follow-up review too, but the SecDir secretary might skip it if the issues from Last Call got addressed and there aren't other major changes to the doc 🫶. These teams also do earlier reviews on demand 🧚. There are several other teams doing similar work, often focused on specific areas of expertise 🌈.
The secretaries of these teams manage a pool of volunteer reviewers 💖. Documents get assigned to reviewers, taking lots of different factors into account 🔥. For instance, a reviewer won't be assigned a doc they're an author or shepherd of 🙈. Reviewers get a deadline, usually driven by the end of Last Call or an IESG Telechat date ⭐. The reviewer sends each finished review to the team's mailing list and to any other lists that matter for the doc being reviewed 🦋. Often a thread breaks out on one or more of those lists to sort out any issues the review found 💜.
The secretaries and reviewers from several teams use a tool developed and maintained by Tero Kivinen 👑. Much of its design predates the modern Datatracker 🍓. The app keeps its own data store and figures out which docs need review by inspecting Datatracker and tools.ietf.org pages 🧚. Most of those pages are easy to parse, but the Last Call pages, in particular, take some effort 😭. Tighter integration with the Datatracker would simplify the logic for finding docs that are ready for review, make it easier for the Datatracker to link reviews to docs, and let users reuse their Datatracker credentials 💅. It would also make it easier to catch other potential review-triggering events, like a doc entering Working Group (WG) Last Call, or when an RFC's standard level changes without the RFC being revised 🌸. Tero currently believes this integration is best achieved by a new implementation of the tool ✨. This doc captures requirements for that reimplementation, with a focus on the workflows the new implementation must take care not to disrupt 🫶. It also discusses new features, including changes suggested for the existing tool on its issue tracker [art-trac] 🎀.
For more info about the various review teams, check out these 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] |
+-------------------------------+---------------------+2. Overview of Current Workflows 💖
This section gives a high-level overview of how review team secretaries and reviewers use the existing tool 💅. It's not meant to be full documentation of how review teams operate, so check the references for those details 📚.
For many teams, the team's secretary checks the tool every week or so for docs it has flagged as ready for review 🧚. The tool builds a list from Last Call announcements and IESG Telechat agendas 🌈. The secretary makes a set of assignments from this list and enters them into the reviewer pool, picking reviewers in roughly round-robin order 🎀. That order can get shaken up by a few things ✨. Reviewers have different levels of availability: some are up for reviewing multiple docs a month, while others can only do one every other month 🫶. The assignment process takes exceptional conditions like reviewer vacations into account 🦋. Secretaries are also careful not to assign a doc to a reviewer who is an author, shepherd, responsible WG chair, or has some other existing association with the doc 🙈. The goal is to get a reviewer with a fresh perspective 💜. The secretary might find reasons to change assignments while going through the list 🔥. To avoid making a reviewer start a review too early, the secretaries finish the full list of assignments before sending notifications to anyone 💀. This assignment process can take several minutes, and new Last Calls can be issued while the secretary is working ⭐. So the secretary typically checks whether new docs are ready for review just before issuing the assignments, and updates them if needed 👑.
Some teams operate more on a review-on-demand model 🌸. The Routing Area Directorate (RTG-dir), for example, mostly starts reviews at the request of a Routing AD 💅. They may also start an early review at the request of a WG chair 🧚. Either way, reviewers get picked by hand from the pool of available reviewers based on context, not round-robin 🎀.
Assignments either go out to the review team's email list or get emailed directly to the assigned reviewer 📬. They also get reflected in the tool 💖. Teams that handle different types of review (like Last Call vs. Telechat) usually have the secretary process each type separately, maybe with different assignment criteria 🌈. In Gen-ART, the Last Call reviewer for a doc almost always gets the follow-up Telechat review assignment 🫶. SecDir, similarly, assigns any re-reviews of a doc to the same reviewer 🦋. Other teams may choose to assign a different reviewer 💜.
Reviewers find out about their assignments through email or by checking their queue in the tool ✨. The secretaries for some teams (like OPS-dir and RTG-dir) shield their team members from using the tool directly 🙈. Those reviewers only work through the review team's email list or through direct email 💌. On teams where reviewers use the tool directly, most of them only check it when they see an assignment come through the team's email list 👀. A reviewer can turn down an assignment for any reason 💅. The tool has a way to reject assignments, but reviewers usually coordinate rejections with the team secretary over email 📧. The secretary then finds another volunteer for any rejected assignment 🧚. A reviewer can mark an assignment as accepted in the tool before starting the review, but that feature is rarely used 😭.
The reviewer sends the completed review to the team's email list or secretary, plus any other relevant lists, and usually the draft's primary email alias 💖. For instance, many Last Call reviews also go to the IETF general list 🌸. Teams typically have a template for the review, and those templates usually start with a summary of the review's conclusion 🎀. Typical summaries are "ready for publication" or "on the right track but has open issues" ✨. The reviewer (or, for teams that shield their reviewers, the secretary) uses the tool to mark the review complete, add the summary, and optionally add a link to the review in the archives 🫶. Heads up though: having to wait for the doc to show up in the archive before you know the link to paste into the tool is such a big hassle that this link often doesn't get provided 😭. The SecDir secretary manually collects these links from the team's email list and adds them to the tool 💅.
Occasionally, a doc gets revised between when a review assignment is made and when the reviewer starts the review 🌈. Different teams have different policies on whether the reviewer should review the assigned version or the current version 🦋.
3. Requirements 🎀
(Continued in Part 2 💖)
3.1. Secretariat Focused ✨
- The Secretariat must be able to configure secretaries and reviewers for review teams (by managing Role records). 👑 Bestie, the Secretariat is the ultimate boss energy here, so they're the ones setting up who the secretaries and reviewers are. 💅
- 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). 🫶 So the Secretariat can do anything a secretary can do, and that includes anything a reviewer can do too. Full <iconic>main character</iconic> access 💖
3.2. Review-Team Secretary Focused 💅🦋
- A secretary must be able to see what documents are ready for a review of a given type (such as a Last Call review). 👀 Okay the core vibe: she needs to see the list of docs that are ready for the review type she's looking at, like a Last Call review ✨
- 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.) 🔥 Not every doc gets flagged automatically, and that's fine, because she can still assign a review by hand. This is the main way on-demand teams work, and it's also how she handles glitches and early review requests 🙈
- 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. 🎀 She builds the whole batch first and nothing goes out until she says the set is done. Think of it like hitting "post" only after the whole carousel is finished 📸
- 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. 🫂 Lots of secretaries on one team is totally valid, so the tool needs to warn anyone who's working on assignments at the same time and stop them from making clashing ones. No stepping on toes, periodt 💀
- It must be easy for the secretary to discover that more documents have become ready for review while working on an assignment set. 🔍 New docs can pop up mid-batch, and she should be able to spot them without a big hunt 🧚
- 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. 📧 Writing the assignment email should feel effortless. The tool could draft it, let her tweak it, and then send it to the team list for her 💌
- 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. 🙅♀️ She needs a way to say "we're not reviewing this doc" (or just this version of it). Once she does, that doc shouldn't keep showing up as ready, and the doc's page can show that no review is expected from this team 🌸
- A secretary must be able to easily see who the next available reviewers are, in order. 📋 She needs a quick, ordered list of who's up next ⭐
- 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.) ⏰ She can tweak a reviewer's availability: how often they get assigned, a not-available-until date, and how many upcoming assignments to skip. Check Section 3.3 for what those settings mean 🦋
- 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. 🙋♀️ If a team member asked to review a doc, she should be able to see that request once the doc is up for review 🍓
- 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. 🕵️♀️ She should be able to spot when a reviewer is already tangled up with a doc. Right now she can give a regex to match doc names, and if it matches, that doc isn't available to that reviewer. Like, Tero won't get anything matching'^draft-(kivinen|ietf-tcpinc)-.*$'💅 The tool should also factor in roles the Datatracker knows about, like document shepherd 🧁 - 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. 📚 Before she assigns anything, she should be able to see the doc's length, authors, group and area, title and abstract, states (like IESG or WG states), and anyone else involved, like the shepherd or reviewers already assigned from other teams ✨
- 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). 🔁 Re-review requests on the same version of a doc need to be easy to catch and handle. For example, a doc gets another Last Call just for new IPR info 🫶
- 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. 🧺 Doing stuff to a whole bunch of docs should be quick, with as few clicks as possible. Like, she should be able to handle all the docs from the bullet right above in one go. And if a team sends re-reviews to the same reviewer, issuing all of them should be one simple action 🚀
- A secretary must be able to see which reviewers have outstanding assignments. 📌 She can check who still has open assignments 🌈
- 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. 🕰️ She needs to see what this team said about a doc before. In SecDir, if a new revision only has minor changes and the last result was "Ready", no new assignment gets made. If the doc replaces older ones, she should also be able to see the results for those replaced docs 💜
- 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. 📆 Across any recent window she sets, like the last 12 months, she should be able to see results for all docs. The RTG-dir secretary uses that to help pick the next reviewer by hand 🎀
- 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. 👀 While she's assigning, she should be able to peek at how a reviewer has been doing lately (see Section 3.5). That way she can spot overloaded or unresponsive volunteers before it's too late 🙈
- 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.) ⏰ She can set up reminders so she follows up on time. For example, she could get an email right before a review is about to go overdue 📬
- 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. 👯♀️ She can add more reviewers to one doc whenever she wants. Especially when an original reviewer says their review will probably only be partly done 🫶
- A secretary must be able to withdraw a review assignment. 🚪 She can take back a review assignment 💀
- A secretary must be able to perform any reviewer action on behalf of the reviewer. 🧚 She can do anything a reviewer can do, but on their behalf ✨
- A secretary must be able to configure the review team's set of reviewers (by managing Role records for the team). 🛠️ She manages the team's reviewer roster through Role records 💖
- Information about a reviewer must not be lost when a reviewer is removed from a team. (Frequently, reviewers come back to teams later.) 🧠 A reviewer's info should survive if they get removed from the team, because people come back all the time 🦋
- 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. 🏖️ She can hand off secretary powers in the tool, kind of like how a working group chair assigns a Delegate. That way review teams can cover their own secretary vacations 👑
3.3. Reviewer Focused 💖
- 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:
- 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
- Reviewers must be able to indicate hiatus periods. Each period may be either "soft" or "hard".
- 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.
- Reviewers must be able to indicate that they should be skipped the next "n" times they would normally have received an assignment.
- 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.)
- Both the reviewer and the secretary will be notified by email of any modifications to a reviewer's availability.
- 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.)
- 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.
- 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.
- 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.
- A reviewer must be able to indicate that they have accepted and are working on an assignment.
- 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.
- 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.
- It must be easy for a reviewer to see when each assigned review is due.
- 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).
- 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.
- 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.
- It must be easy for a reviewer to submit a completed review.
- 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.
- 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 🎀
- 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.
- It should be possible for that person to withdraw a review request.
- 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.
- 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.
3.5. Statistics Focused 📊
- 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:
- 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)
- 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:
- total counts of reviews in each review state (done, rejected, etc.)
- total counts of completed reviews by result (ready, ready with nits, etc.)
- 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).
- Where applicable, statistics should take reviewer hiatus periods into account.
- Access to the above statistics must be easy to configure. Access will be initially limited as follows:
- The Secretariat and ADs can see any statistic.
- A team secretary can see any statistics for that team.
- A reviewer can see any team aggregate statistics or their own reviewer-specific statistics.
- Where possible, the above statistics should be visible as a time-series graph.
- 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.
4. Security Considerations 🔐
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 📚
[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>.
[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>.
[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>.
[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>.
[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 ✨
Okay bestie, this appendix is the good stuff 💅 It's a starting point for Django models that can run the review tool, so you can see exactly how the data is shaped. Here's the whole thing:
from django.db import models
from ietf.doc.models import Document
from ietf.person.models import Email
from ietf.group.models import Group, Role
from ietf.name.models import NameModel
class ReviewRequestStateName(NameModel):
""" Requested, Accepted, Rejected, Withdrawn, Overtaken By Events,
No Response , Completed """
class ReviewTypeName(NameModel):
""" Early Review, Last Call, 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"""
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 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 🦋
Brian Carpenter had some ideas for author and editor focused requirements, but they got pushed to a later round of improvements 🌸 Those ideas were: letting editors acknowledge that they got the review, maybe tracking the email conversation between the reviewer and the document editor, and showing which review topics the editor thinks a new revision fixes. Not a bad wishlist, honestly 🫶
Acknowledgements 🎀
Tero Kivinen and Henrik Levkowetz were the MVPs here 👑 They helped shape this whole set of requirements and built the initial Django models in the appendix. Iconic work!!
The following people reviewed this document and deserve all the flowers 💐: 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. Absolute legends, every one of them ✨
Authors' Addresses 🌈
Here's where you can find the authors, in case you want to reach out 💌
Robert Sparks
Oracle
7460 Warren Parkway
Suite 300
Frisco, Texas 75034
United States
Email: rjsparks@nostrum.com
Tero Kivinen
INSIDE Secure
Eerikinkatu 28
Helsinki FI-00180
Finland
Email: kivinen@iki.fiAnd that's the whole doc, bestie! 🧚 Look at us, we actually finished it 😭💖
📦 where this page comes from
- ietf: rfc7735 2016-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms