Re: [sipcore] Tracker Etiquette

["Elwell, John" <[e-mail]>]

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: [e-mail] 
> [mailto:[e-mail]] 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
> 
> 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 
> <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >>
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>