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

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

Hi,

On Sun, Apr 20, 2014 at 4:29 AM, Joao S. O. Bueno <gwidion gmail com> wrote:
> As of lately,
> new, sometimes simple, feature requests added to bugzilla are being
> quickly closed as "invalid", with a short-text inviting the reporter to
> discuss the feature here (developer mailing list) rather than
> entering then at bugzilla.
>
> This here is an  invitation for us to discuss this policy and set it
> as "official" or not.
>
> Personally, I find this to be harmful to the project. I think closing
> a feature request
> outright as "invalid" is more or less equivalent to slamming a door  in the
> face of someone which is otherwise eager to help.
>
> Even if the text always contain "looks a nice idea, let's talk about
> it on the mailing list",
> the "invalid'", if only for the status name means... "invalid". It is
> not a nice word to receive
> as an evaluation for what one thinks is a cool idea to the program
>
> Moreover, it is not like we have been talkign about small aditions to
> GIMP in this list,
> and finding "this is cool, it might go in right now" or "we have to
> draft an UI spec to that" (and
> _actyually_ have such a draft made.
>
> On the other hand most features I see being posted here have
> discussions that fade away
> into oblivion after a few replies, if that much.
>
> i agree that the list could be used for that, but it is has not been
> the case over the last
> few years.
>
>
> And still, a third point I see as counter-productive with the idea
> ofmaking the list
> "mandatory" for anyone with a new idea to GIMP: sometimes one may care
> even to the
> point of detailing an idea, and posting it to bugzilla, but the person
> is not (and IMHO, should not)
> necessarily be comited to helping GIMP to the point of joining the
> development mailing list. So,
> the person could simply think "well, I tried to help this program, but
> let me go back to my stuff). I'd do just so after filing bug reports
> to any other program I just use in a normal basis, and fortunately it
> did not happen there - and I am happy some of the ideas or suggestions
> I just filled in the respective bug tracker ended up as nice features
> instead of having them
> "invalidated" because I was not willing to join the development
> mailing list of each project.
>
> So, I for one, feel like such requests in bugzilla should be left in
> the "New" or "Unconfirmed" state,
> with a text inviting the person to discuss it either her or on IRC,
> stating that it might never
> part from "unconfirmed" otherwise (but also, it could happen -
> requests as simple as
> having an option to display a Layer's size could be done by any of the
> regular contributors
> if he felt like it and had the time).
>
> Whatever your (all) position on this, I'd like to state I am against
> the policy of simply marking
> a bug request as "invalid", when it is not necessarily so,  a couple
> of hours/days after it is filled in.
>
> (Ref: https://bugzilla.gnome.org/show_bug.cgi?id=728493)

I agree with every point of what was said by João. So if there is to
be a vote or something, I vote for changing this rule too. :-)
We should never close a feature request, unless we consider it
*actually* invalid, which means: it goes against the program design
and we know that we won't develop it, nor even accept a submitted
patch implementing the feature, since we disagree with it.

But even a feature which no current developer has time or will to
develop should just stay in a "new" status with a nice stock message
in the line of "oh that looks like a nice feature. If ever you are
willing to develop it, or know someone who is, we may discuss it
further here to get a consensus for the right implementation".

Also to confirm further what João said, half of feature-request type
message get hardly an answer on the mailing list (unless they are
highly desired features). This is an illusion to think and affirm that
a user should discuss there first. Furthermore any thread is washed
out by time, as the basic design of mail is. So asking a user to
discuss first on the mailing list, even though it is truthfully hoped
to sparkle a discussion, is in reality most often trashing a feature
request into /dev/null. And I would completely understand if a user
was to be pushed away from such a "first encounter". On the other
hand, bugzilla keep a thread well visible forever and is very good for
discussion too (I don't see why some would think email would be more
suited!).

For information if my first experience with GIMP had been such a
message, I might have abandonned as soon as I started.

During LGM, we were willing to discuss (but had no much time to) how
to have more contribution. Well I definitely think changing this rule
would be a good start.

Jehan

P.S.: we should not fear a huge number of opened tickets, as long as
we treat them accordingly.

>   js
>  -><-
> _______________________________________________
> 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