Re: [Gimp-developer] About closing feature requests as invalid

[Jehan Pagès <jehan marmottard gmail com>]

Hi again,

On Sun, Apr 20, 2014 at 6:03 AM, scl <scl gplus gmail com> wrote:
> Hi,
>
> yes, it's a bit tricky.
> One goal is to take care for bugs in a timely manner to
> let the reporter know that we care as well as to
> save developers from drowning in open bugs.

Thousands of bugs can stay open, that's not a problem at all if they
are well managed. Only companies with useless "performance reports",
who wishes to bend numbers to look nice (however how good or bad they
actually are) care for this.

> The other thing is to sound friendly even if we say
> 'No, not this way'. That's why I did some investigation

We don't have to say "no". If that's something none in the current
developers cares sufficiently about, but still are not against, we
just say it and leave it open. That means we still leave the door
opened for any new contributor to join us. Actually one of the point
(not discussed again!) planned during the GIMP meeting was "more
GNOME-love bugs". Well the given example for instance would make for a
perfect GNOME-love: easy to implement, not to intrusive. All it takes
is someone new willing to try and develop this. With such tickets
closed, we may lose opportunities to new developers.

So "no" means "no", thus it should only be used in actual "no" case
(like someone opening a bug for the save/export troll, that's a clear
"no", we know this by now :p). We should not be afraid to answer
different from "yes" and "no", but also "why not?" or "I am not
against if you do it". And we can answer this in a timely manner too.
:-)

> about the reported issue and posted the request myself
> here instead of simply saying 'Go to the mailing list'.
> Thirdly I think Bugzilla is even less visible to the
> broad audience than the mailing lists, so lengthy
> discussions in Bugzilla have less chances to solve anything.
> If we failed to take accepted feature requests on the mailing
> list to Bugzilla in the past, this should be no reason
> to do it wrong in another way.
>
> However, you have a point in saying ''Invalid' sounds
> too harsh'. If we found a better solution I would be
> the last to hamper it.
>
> Currently I see the following solutions:
> - a friendly stock answer we agreed about to guide the
> reporter the right way,

But if one posts on bugzilla, one is already on the right way! I don't
get why mail should be a better way. Bugzilla is specifically done for
this purpose. It is done for bugs and feature requests. This is the
right way, and none else, in my opinion.

> - the policy change you proposed,
> - feature voting like [uservoice.com]. I saw newer Bugzilla
> versions should be able to support [voting], but I neither
> know whether nor when it will become part of GNOME's Bugzilla.

Feature voting is especially nice when there are enough dedicated
developers with time to kill, or when some are paid (thus can develop
on vote-basis). In our case, every developer rather develops what we
think is more important for oneself.
This said, I am not against adding vote features to Bugzilla. That's
always a nice feature to get in a bug tracker. But I definitely don't
think we should use this to priorize the bug fixes or features. This
should only stay a complementary available information, which is
always nice to have. And that's all.

Jehan

> Kind regards,
>
> Sven
>
> [uservoice.com]
> http://demo.uservoice.com/
>
> [voting]
> http://www.bugzilla.org/docs/4.2/en/html/voting.html
>
>
>
>
> _______________________________________________
> gimp-developer-list mailing list
> List address:    gimp-developer-list gnome org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list