Re: [I18nrp] Additional input needed for i18nRP BOF

Nico Williams <nico@cryptonector.com> Thu, 07 June 2018 02:45 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: i18nrp@ietfa.amsl.com
Delivered-To: i18nrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884B6131090 for <i18nrp@ietfa.amsl.com>; Wed, 6 Jun 2018 19:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 X3NrdeVhxL19 for <i18nrp@ietfa.amsl.com>; Wed, 6 Jun 2018 19:45:32 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078BE130E1A for <i18nrp@ietf.org>; Wed, 6 Jun 2018 19:45:31 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 2EE21A004F14; Wed, 6 Jun 2018 19:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KIdeW1YZ0kEYZ9 INkVdCNBEyyv8=; b=NHSFod8InQ6d9No/TObaBN5VuyNK274iQcC6gYMaymkLEl ZNhA30jIterGvQbA7zIgEQzqS3zc5d9VKpwcu6bXrVng/gxr+Fx3FDYNJO6NRD8F BycECNF0fwAQnNURam+6+B1el5E9uOg4ujCJ7KTN9a4BiQ6kX4eOu6rnmn2Mg=
Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 601DFA004F13; Wed, 6 Jun 2018 19:45:30 -0700 (PDT)
Date: Wed, 6 Jun 2018 21:45:28 -0500
From: Nico Williams <nico@cryptonector.com>
To: Adam Roach <adam@nostrum.com>
Cc: Peter Saint-Andre <stpeter@mozilla.com>, John C Klensin <john-ietf@jck.com>, i18nrp@ietf.org
Message-ID: <20180607024527.GR14446@localhost>
References: <f997170c-3062-0241-e58d-7a3415fba983@nostrum.com> <CE6F76BB323F1555D6B217A5@PSB> <9ecf8b7a-d086-1c56-03fb-6773aed332c6@nostrum.com> <4DA478C4C99396556E1B3EF1@PSB> <a31e91ff-c78c-6a7c-fe8c-70b9563312f7@nostrum.com> <8774afa2-4d3f-bc08-69af-f88e229f547a@mozilla.com> <07356789-b93f-b1a2-21d6-bef704b7c0b0@nostrum.com> <a6b7bf5c-3f37-e97b-7e44-c9e648bdbcef@mozilla.com> <ba6339f3-eb5f-4d14-51fb-256d6682f37e@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ba6339f3-eb5f-4d14-51fb-256d6682f37e@nostrum.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/LqHNHWJPXaEG470r2xz5scc43Rk>
Subject: Re: [I18nrp] Additional input needed for i18nRP BOF
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Internationalization Review Procedures <i18nrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18nrp/>
List-Post: <mailto:i18nrp@ietf.org>
List-Help: <mailto:i18nrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 02:45:35 -0000

On Wed, Jun 06, 2018 at 05:56:47PM -0500, Adam Roach wrote:
> On 6/6/18 5:31 PM, Peter Saint-Andre wrote:
> >SECDIR, GENART, and ARTART reviewers seem to check the whole document.
> >By contrast, I18N reviews would have a smaller scope (along the lines of
> >what the SDPDIR does).

FWIW, I concur with Peter that your message about directorate
organization and functions was quite useful.

> I'm not sure how good a comparison this is. Any document that doesn't
> mention SDP is clearly not a candidate for SDPDIR review. Any document that
> doesn't mention i18n, probably *does* need a check that such omission makes
> sense. In that way, I think the required task is more like SECDIR than
> SDPDIR.

Might it be reasonable to expect shepherds and/or responsible ADs to
detect I18NDIR review opportunities and refer documents to it?

> Thanks for mentioning ARTART. Its process is useful as a third point on the
> continuum of rigor exhibited by directorates. ARTART only reviews those
> documents that are flagged as potentially having ART interactions, rather
> than the intended full coverage of SECDIR, OPSDIR, and GENART. It is
> probably more in line with what is appropriate for an internationalization
> directorate, both in function and size. It currently has 12 members,
> although we would ideally like a slightly larger pool.

This sounds right.

> >As a point of comparison, the W3C I18N WG [1] is
> >quite busy but is very small: John Klensin and I and a few others help
> >out, but most of the work is done by two people.
> 
> Taken together with the assumption that any IETF directorate would
> probably involve substantial overlap with that group of people, I'm
> now concerned about scaling. I couldn't quickly find statistics on how
> many documents the W3C finalizes in any given year, but my impression
> is that it's somewhat smaller than the IETF's output. Given that your
> description uses the words "quite busy," do you think that same group
> of individuals could double or triple their i18n review load without
> losing efficacy or burning out?

Regardless of what the answer to that is, it might be possible to start
small and scale up.  Starting small means triaging more demurely.  At
any rate, starting small is probably the only realistic way to get
started.  But there's no point starting small if we can't scale up, so
we do need to have some idea of how big to scale, and how.

Nico
--