Subject: Re: [sipcore] Tracker Etiquette

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Sep 2010 03:43:24 -0400

Yes in Martini we've been using it in the same vein as a tech support tracker, which is why I was using it for 4424bis - I figure once it's a WG doc or at least in WGLC, then it's important not to miss stuff (which can easily happen in lots of emails).

As for the subject, unfortunately the "Component" you select shows up in the body of the email notification, but not the subject line.  Right now afaik 4424bis is the only one with tickets in sipcore so it prob doesn't matter, but it may in the future.

-hadriel

On Aug 31, 2010, at 10:21 PM, 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Sep 2010 09:31:51 -0400

James,

Thanks for your thoughts.

The correlation with documents seems very important. Based on later 
messages in this thread, I see that the "component" field doesn't show 
up in the subject line of the mail messages, which is unfortunate.

(I only briefly skimmed the features of this tool. It appears to be very 
configurable. Does somebody know if it can be configured to include the 
component name in the mail subject lines?)

	Thanks,
	Paul

James M. Polk wrote:
> ISTM that the first order of business wrt Tickets is to correlate them 
> to a particular document. Perhaps this is a pull down tab with minimal 
> ids for each WG item we have (e.g., 'hi' for history-info, and 'loc' for 
> Location Conveyance). The note to the list will already say it's 
> [sipcore], so this second level of identification allows doc editors to 
> quickly know whether a ticket (in the subject line of the note to the 
> list) is for 'their' doc or not.
> 
> I think the chairs ought to assign what they think is best for a doc 
> identifier.
> 
> BTW - Geopriv and ECRIT use tickets, but not the doc identifiers, and as 
> an author of more than one ID within each group, it's a real bitch 
> (sorry ladies) to track them in my mail app.
> 
> Also, personally I don't like tickets being generated about one of my 
> docs without any discussion - mostly because I feel kinda blindsided by 
> having to account for another topic without having a chance to explain 
> whether or not I believe that ticket's topic is already covered (or 
> not). In other words, I personally don't have an issue with bonafide 
> open issues - whether technical or editorial - but I'd like the 
> opportunity to address the topic before it becomes a ticket.
> 
> I believe all the rest of Paul's points fall under these above, and can 
> be worked out.
> 
> Maybe that's just how I think...
> 
> comments?
> 
> James
> 
> At 04:47 PM 8/31/2010, Paul Kyzivat wrote:
>> [as chair]
>>
>> I've been ignoring the tracker till now, but it seems impossible to 
>> continue doing so.
>>
>> ISTM we do need some group norms on this.
>> Especially given my lack of experience with the tool, I'm reluctant to 
>> impose them, at least *yet*. Instead, I'd like to see some discussion 
>> on how people think this should be used.
>>
>> Here are a few questions that come to mind:
>>
>> - can anybody create a new topic? Or should the topics be controlled
>>   in some way? (e.g. consensus)
>>
>> - can anybody create a new ticket? Or should ticket issuance be
>>   controlled in some way? (e.g. consensus)
>>
>> - is creating a ticket done after discussion, or in lieu of discussion?
>>
>> - who is responsible for assigning ownership of a ticket?
>>   can the author pick anybody he wants? Or should people only be
>>   allowed to assign ownership to themself?  Or should there be
>>   ownership of topics?
>>
>> - who can close a ticket? The reporter? The owner? Anybody?
>>
>> I'd like to hear what people in this WG think about this. (My own 
>> first reaction is that it would be helpful for wg doc editors to use 
>> tracker for those things that need to be addressed in a document, 
>> based on emails from others. I'm not so sure about use beyond that, 
>> but have an open mind.)
>>
>> Should I have created a tracker topic "Tracker Etiquette" and 
>> submitted tickets for each of these questions, rather than sending 
>> this mail?
>>
>>         Thanks,
>>         Paul
>>
>> James M. Polk wrote:
>>> At 02:57 PM 8/31/2010, Adam Roach wrote:
>>>
>>>> [as chair]
>>>>
>>>> Finally, it would be helpful to document authors if you included 
>>>> something in the ticket name that indicated which document the 
>>>> tracker issue is on. It doesn't have to be a whole document name; 
>>>> something like "4244bis" for the history-info draft would be 
>>>> sufficient.
>>> Amen
>>> tracking which issues pertain to which docs is a fundamental flaw in 
>>> this whole process regardless of the WG or doc involved.
>>> James
>>>
>>>> Thank you.
>>>>
>>>> /a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Sep 2010 09:39:17 -0400

> 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,…

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

---

From: Mary Barnes <[email-masked]>
Date: Wed, 1 Sep 2010 08:51:11 -0500

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 <[email-masked]> 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.
>
> that, by default, I think *anyone* can close a ticket, whether justified or
> not. But *will* anyone close tickets that ought to be closed?
>
> 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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 1 Sep 2010 18:39:16 +0200

I agree with Mary's assessment - we should not overload the tracker with trivial things. In my experience, performance is rather slow - not a criticism, but it does discourage opening unnecessary tickets.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: 01 September 2010 14:51
> To: Paul Kyzivat
> Cc: Worley, Dale R (Dale); SIPCORE
> Subject: Re: [sipcore] Tracker Etiquette
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 15:53:34 -0400

________________________________________
From: Paul Kyzivat [[email-masked]]

OTOH, when WGLC time comes around, I will do the appropriate search on the tracker (category == "4244bis" && submitter == "dworley") to find all the issues that I have raised and will compare each issue with the document to verify that it has been taken care of.  So though there is no security block against closing an issue "arbitrarily", if the submitter is paying attention, there will be no adverse practical consequence.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Sep 2010 16:24:12 -0400

If people find that sufficient, then it is certainly simple.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 17 Sep 2010 13:48:18 -0400

I've gotten around to consolidating some (hopefully all) of the tracker items that seem to me to be "minor" wording issues.  Not all of these are nits, strictly speaking, as most of them require content knowledge to handle correctly, but I think that they do not have "interesting" or "controversial" technical content.

The new tracker item is #43 (http://trac.tools.ietf.org/wg/sipcore/trac/ticket/43).  It incorporates items #30, #33, #31, #36, #39, #17, #26, and #22.  Fortunately Trac does have a "resolve as duplicate" status, so I've closed the old items.

Dale
________________________________________
From: Mary Barnes [[email-masked]]
Sent: Wednesday, September 01, 2010 9:51 AM
To: Paul Kyzivat
Cc: Worley, Dale R (Dale); SIPCORE
Subject: Re: [sipcore] Tracker Etiquette

Mary.
___________________________________