Re: [dir-coord] Review tracking requirements draft

"A. Jean Mahoney" <mahoney@nostrum.com> Fri, 20 March 2015 21:58 UTC

Return-Path: <mahoney@nostrum.com>
X-Original-To: dir-coord@ietfa.amsl.com
Delivered-To: dir-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3804F1A906D for <dir-coord@ietfa.amsl.com>; Fri, 20 Mar 2015 14:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNWL0PZz2Kp6 for <dir-coord@ietfa.amsl.com>; Fri, 20 Mar 2015 14:58:04 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E021A8891 for <dir-coord@ietf.org>; Fri, 20 Mar 2015 14:58:04 -0700 (PDT)
Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2KLw3Oc016984 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 16:58:03 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be A-Jean-Mahoneys-MacBook-Pro.local
Message-ID: <550C97DC.1060702@nostrum.com>
Date: Fri, 20 Mar 2015 16:57:48 -0500
From: "A. Jean Mahoney" <mahoney@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>, "dir-coord@ietf.org" <dir-coord@ietf.org>, Tero Kivinen <kivinen@iki.fi>
References: <54DA39DD.8010702@nostrum.com>
In-Reply-To: <54DA39DD.8010702@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dir-coord/Dgvuq7Nb_fHeeL2l-5Q0eTSfp-Q>
Subject: Re: [dir-coord] Review tracking requirements draft
X-BeenThere: dir-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is an e-mail alias for the organisers of IETF directorates." <dir-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dir-coord/>
List-Post: <mailto:dir-coord@ietf.org>
List-Help: <mailto:dir-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2015 21:58:06 -0000

Thanks, Robert and Tero.

For the Gen-ART team, the Spring IETF is a time of transitions, and it 
got me thinking about user management.

Some user management requirements to capture:

Access rights:

o  The administrator must be able to add/modify/delete secretary and 
reviewer users.
o  Secretary users must be able to add/modify/delete reviewer users and 
secretary users.
o  Deleting a user means revoking the user's access to the tool. The 
user's data will
    still remain within the tool.

Currently the tool allows a secretary user to grant secretary privileges 
to another user. This is convenient for when the secretary goes on 
vacation. I would like to keep it this way, but I can see someone 
arguing for only allowing an admin user to create a secretary user.


Modifying reviewer availability:

General requirements:

o  Both the reviewer and the secretary can modify the reviewer's 
availability
    for new and existing work.
o  A reviewer's availability or lack thereof does not impact the 
reviewer's access
    to the tool.
o  Modifications to a reviewer's availability generates notifications to 
both
    the reviewer and the secretary.
o  Hiatuses have start and stop dates. A stop date could also be indefinite.
o  At the end of the hiatus, the reviewer is put back into their 
previous review
    rotation.


Use case: Soft hiatus

For a specific time period, the reviewer does not want new work but is 
willing to complete existing assignments and do followup reviews. This 
is a common request from Gen-ART members during the summer and winter 
holidays. (Gen-ART reviewers do at least two reviews of each draft - one 
at LC and one before the telechat. Other directorates may have different 
review cycles).

o  During a soft hiatus, the secretary must not be able to assign new work
    but may be able to assign followup reviews to the reviewer on hiatus.


Use case: Hard hiatus

For either a specific or indefinite time, the reviewer cannot accept any 
new work and cannot complete existing work.

o  During a hard hiatus, the secretary must not be able to assign new work
    to the reviewer on hiatus. For outstanding reviews and followup 
reviews,
    the tool must notify the secretary that another reviewer should* be 
selected.

    * I use "should" here because a followup review is not necessarily 
required
      if a previous review declared the draft in good shape.


Use case: Transition to inactive

A reviewer gracefully departs the team by finishing current assignments 
while not taking on new work. This is different than the soft hiatus use 
case in that the reviewer becomes inactive after the stop date rather 
than active.

o  During a reviewer's transition to inactive, the secretary must not be 
able
    to assign new work, but may be able to assign followup reviews to the
    reviewer.
o  After the reviewer transitions to inactive, the secretary must not be 
able
    to assign new work to the inactive reviewer. For outstanding reviews 
and
    followup reviews, the tool must notify the secretary that another 
reviewer
    should be selected.


Thanks,

Jean


On 2/10/15 11:03 AM, Robert Sparks wrote:
> All -
>
> Tero and I have a start on a draft of requirements for the evolution 
> of the review tracking tool.
> Please see
> <http://datatracker.ietf.org/doc/draft-sparks-genarea-review-tracker/>
>
> If you have a team that should be added to the block in the 
> introduction, please let us know (and if you have them, send us links 
> similar what the draft currently reference for gen-art and secdir).
>
> Please let us know if we've missed something that's important to you.
> If it's appropriate for your review teams, ask them to comment as well.
>
> Thanks in advance for any time you can spend helping identify how we 
> can make things better.
>
> RjS
>
> _______________________________________________
> dir-coord mailing list
> dir-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/dir-coord