Re: [sipcore] Tracker Etiquette

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 01 September 2010 13:50 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB5E3A6A4C for <sipcore@core3.amsl.com>; Wed, 1 Sep 2010 06:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level:
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqyOyjF9DO+P for <sipcore@core3.amsl.com>; Wed, 1 Sep 2010 06:50:41 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B262D3A6893 for <sipcore@ietf.org>; Wed, 1 Sep 2010 06:50:41 -0700 (PDT)
Received: by iwn3 with SMTP id 3so7547081iwn.31 for <sipcore@ietf.org>; Wed, 01 Sep 2010 06:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eRKRgLm93QxcTERK1Siz84ToYvVWEQJC6FUyyjIXn/k=; b=dddCbK1chG2Hwf6PW6QimedcAauv0KmK1nwTwrFD8jOB/oP/4DjjFbXe43Xy1hNw72 7fD9AHWtgJM7HyIKtmJIgt/WMJB7wUzX34Qq3gh6iaowVf5iSHACWryGMsm2Az7bW4B2 5HEmuLlPzkh+ORi4/OcRZkJxndZy3jyrk23QE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dc8wILrqR0Nbaw40+A8uUqtygscTt1lLRUKehmqoDjsKZgmxesYdAiZlbcO9+aGkT9 d694w/9m8Uxg98Vv8h/63WOTkPh91SnTTQ94jP7u3Eq+NPADAe4ydb9LB2CbT08T+jwZ cYVo8nIgIF4ZeajBISmbcL15IEavkEy7xK154=
MIME-Version: 1.0
Received: by 10.231.174.84 with SMTP id s20mr8663434ibz.94.1283349071915; Wed, 01 Sep 2010 06:51:11 -0700 (PDT)
Received: by 10.231.169.14 with HTTP; Wed, 1 Sep 2010 06:51:11 -0700 (PDT)
In-Reply-To: <4C7E5785.6080008@cisco.com>
References: <4C7D5E9C.9090908@nostrum.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79C04@DC-US1MBEX4.global.avaya.com> <4C7E5785.6080008@cisco.com>
Date: Wed, 01 Sep 2010 08:51:11 -0500
Message-ID: <AANLkTim1B_2pUgHYPHAcpWa5u5t6WGG3R+ZoQTPehqbf@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Worley, Dale R (Dale)" <dworley@avaya.com>, SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Tracker Etiquette
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2010 13:50:43 -0000

It's not the closing of the ticket in and of itself that's difficult.
I think the tool is an excellent way to track technical issues, so we
don't have to worry about losing email threads. However, it's
absolutely not necessary to use something like this to track editorial
nits, other than perhaps having a placeholder ticket for capturing
them all there.  And by editorial nits, I'm talking about grammatical
things, missing spaces, misplaced quotes, etc. Those don't even need
to go to the ML and can go directly to the author IMHO.  When a single
ticket is opened for every single gramnar nit, then far more time is
spent by the author in just opening each ticket individually and later
closing than it takes to make the edit.  In the end, some of these
nits might end up getting changed by the RFC editor in the end anyways
(in particular grammar and punctuation related).

Another problem with the current system is that you can't tell from
the email header if it's important  (aside from the fact that you
don't even know what document it relates to). There is a way to list
all the tickets and they are color coded based on impact (i.e., major
versus minor), but when you have one ticket per editorial nit, you
still have to sift through all of them.

>From what I've seen, the tool is not so sophisticated that you can
mark things as duplicate, etc. Thinking that opening a ticket is cheap
as compared to other activities involved with editing the drafts isn't
an accurate assessment. There is some overhead, but certainly not
unreasonable for the value we get in being able to track the technical
issues, but it's expensive IMHO to use for editorial comments.

Mary.

On Wed, Sep 1, 2010 at 8:39 AM, Paul Kyzivat <pkyzivat@cisco.com> wrote:
>
>
> Worley, Dale R (Dale) wrote:
>>
>> I've been assuming that the tracker is to be used much like a technical
>> support tracker -- it's assumed that duplicate and mistaken tickets will be
>> entered, and often variants of existing tickets, and that there are
>> facilities for easily closing tickets that prove to be useless, and for
>> consolidating tickets that are partially or completely duplicates.  Maybe
>> I'm mistaken; I'm assuming that closing a ticket is not difficult.
>
> I also presume closing a ticket is not difficult. It may be too easy, in
> that, by default, I think *anyone* can close a ticket, whether justified or
> not. But *will* anyone close tickets that ought to be closed?
>
> I think there will be no problem if the creator of a ticket closes it.
> But if the editor of the subject document closes the ticket without acting
> on it, and without explaining why, and without permission of the creator,
> then there will probably be complaints.
>
> I don't know if we need a restrictive workflow about this, but I think we at
> least need some community norms about how we intend to manage it.
>
>        Thanks,
>        Paul
>
>> In regard to putting something in the "ticket name" to indicate the
>> document in question:  I see a data field "Component" for which one can
>> select the value "4244bis".  I've been assuming that is how one identifies
>> the tickets that are relevant to 4244bis.  Is this not the correct thing to
>> do?  I do not see a data field named "ticket name".
>>
>> Dale
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>