[Gimp-developer] About closing feature requests as invalid
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) 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
Re: [Gimp-developer] About closing feature requests as invalid
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 ___ 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
Re: [Gimp-developer] About closing feature requests as invalid
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 ___ 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
Re: [Gimp-developer] About closing feature requests as invalid
Hi, On Sun, Apr 20, 2014 at 4:29 AM, Joao S. O. Bueno gwid...@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
Re: [Gimp-developer] About closing feature requests as invalid
Hi again, On Sun, Apr 20, 2014 at 6:03 AM, scl scl.gp...@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 ___ 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
