Hi again, On Sun, Apr 20, 2014 at 6:03 AM, scl <scl.gplus@xxxxxxxxx> 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@xxxxxxxxx > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list