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. The other thing is to sound friendly even if we say 'No, not this way'. That's why I did some investigation 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,
- 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.

Kind regards,

Sven

[uservoice.com] http://demo.uservoice.com/

[voting] http://www.bugzilla.org/docs/4.2/en/html/voting.html

On Sat, 2014-04-19 at 13:29 -0300, Joao S. O. Bueno wrote: [...]

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

Yes - we use bugzilla at w3.org for some of the XML specs, and this has been a concern for us too.

Our response for (say) XQuery was that the bugzilla postings go to a mailing list and we have discussion in the comments of the bug report - that way everyone sees them.

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).

I think this is better - even though Sven was very polite, the commenter will get mail that says "CLOSED - INVALID" and may well have to scroll down to see the comments, which people unfamiliar with bugzilla are unlikely to do.

I think also other GNOME projects do entertain at least a little discussion of new features on bugzilla, and GIMP should be part of that community too.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Introducing a new status "feature requelst" or "potential future story" should be simple.

But I'd even suggest going one step forther: integrating with bountysource or such. If people like a feature they might be sponsoring it even ..

There is a big difference in suggesting a feature and having time to implement it. By having a way to fund it there might be a chance that somebody picks it up and gets it done.

Those are just some thoughts ..

Marc Weber

Hi,

On Sun, Apr 20, 2014 at 4:29 AM, Joao S. O. Bueno 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

Hi again,

On Sun, Apr 20, 2014 at 6:03 AM, scl 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

Hi,

1)
I think there is some vagueness about the meaning of the fields in Bugzilla (yes, sometimes it also affects me). They are defined here:
https://bugzilla.gnome.org/page.cgi?id=fields.html

We already have a severity 'Enhancement' for feature requests and also use the milestone 'Future' for things that are currently not meant to be included in one of the next releases.

Indeed, the definition of 'Invalid' lacks of clarity: 'This bug is in some way not valid...'. But if we close bugs we will neither fix nor accept patches we clearly use the state='CLOSED-WONTFIX'. Why would we use 'CLOSED-INVALID' for this?

2) Let's also not forget, that the mailing lists have around 1000 subscribers and are mirrored directly to various sites (GMane, Markmail, etc.).
After committing a comment to a bug in Bugzilla we all can see the recipients: a handful of interested people. If I do a Google search on 'tito' and constrain the search to bugzilla.gnome.org, gmane.org or markmail.org I get 1 (in words: one) result for bugzilla.gnome.org and lots for the other sites.
This confirms that the mailing lists are suited better for broad discussions than Bugzilla.

2) When I closed the bug 'INVALID' I obeyed the projects policy, see for instance http://www.gimp.org/bugs/ in the 2nd paragraph. However, as we see there are doubts and disagreements about its practical use.
I think it is a good idea if the people who usually care most about policies joined in:
Mitch, Peter, Schumaml - what are your opinions?

Greetings and Happy Easter!

Sven