Directing submitter to use upstream channels instead

[James Henstridge]

On 07/03/06, Ian Jackson <ian at davenant.greenend.org.uk> wrote:
> James Henstridge writes ("Re: Directing submitter to use upstream channels instead"):
> > On 28/02/06, Ian Jackson <ian at davenant.greenend.org.uk> wrote:
> > > If all upstream bugs should be open in Ubuntu then something should
> > > open them (probably, Launchpad automatically).  If, on the other hand,
> > > most bugs shouldn't be open - in particular, if only a small subset of
> > > upstream bugs should be recorded against Ubuntu - then there should be
> > > a way to close a bug that was opened in Ubuntu's bugtracker but which
> > > it has now been decided should not have been reported there.
> >
> > If a bug is not appropriate or applicable to Ubuntu, then the Ubuntu
> > bug task would be rejected.  The other bug tasks would remain linked
> > to the remote bugs.
> >
> > Does that help clear up the multiple bug tasks model for you?
>
> Thanks, that's a nice clarification of the confusion about the model.
> I'm glad that you agree with me that this bug task should not remain
> open, and that you therefore (apparently) disagree with what Christian
> and Bjorn said earlier.
>
> However, that leaves unanswered my main point, which is that using
> `status rejected' for this meaning is unfortunate.  As I wrote
> in my initial message:
>
>  IMO `rejected' is wrong because it implies that the original report is
>  somehow defective.  It is a (relatively mild) implied criticism of the
>  submitter's decision to file the bug in the first place.  Sometimes
>  this is appropriate, and that's when `rejected' is right.  `Rejected'
>  to me means `this should not have been filed in the first place and
>  the submitter should have known that', and rejecting a bug in this way
>  (with a polite explanation) is part of the process of educating the
>  community.

Remember that statuses like unconfirmed, confirmed, fixed, rejected,
etc apply to bug tasks in Malone rather than bugs.  If the bug only
has a single task (as most do), then this distinction is not
particularly important

In the case of a bug with multiple tasks, if you mark the Ubuntu
specific task as rejected you are only rejecting the bug in context of
Ubuntu.  The status of the other tasks on the bug would reflect those
other contexts.


>  However in this case the situation is quite different.  The bug report
>  is quite true and appropriate, and no criticism of the submitter is
>  implied by my decision to spend our limited effort elsewhere.  It
>  would be nice to be able to close a report (strictly, in LP-speak, a
>  task) with something along the lines of `we agree that this would be
>  nice but we are not going to spend any effort on it in the context of
>  Ubuntu'.
>
> So it would seem to me that what I'm asking for is a new status other
> than `rejected' and `fixreleased'; say `status notforus'.

I think the rejected status fits your use case quite well.  If the bug
is "not for us", then it has been rejected in the context of Ubuntu,
but may still be open or fixed in the context of upstream or Debian.

If people take offence to this, then the two options I'd prefer to explore are:
 1. education about what the statuses mean.
 2. alter the UI to reduce the chance of misinterpretation.

A number of sites using bugzilla take option (2) and rename some of
the resolutions that end up offending users (e.g. WORKSFORME and
WONTFIX), so this might be worth investigating.

James.