<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Kohei, thanks for your reply. I am looking forward to the fruitful discussion regarding bugs 39167 / 39168 / 39169 on the UX mailing list. Thanks for making me understand the matured objectives of the EasyHacks-system. Although I do not share your rough statements about "mis-using", "injecting" and "pet peeves", I propose that I add easy bugs or enhancement requests as "[ProposedEasyHack]" in the future. Then, I do not conflict with the objectives of the EasyHacks-system as you pointed them out. However, I would like to point to some problems and inconsistencies in the EasyHacks-system that might be worth to consider: <ol> <ol> <li>The whiteboard tag "ProposedEasyHack" does not seem to have any effect. So far, I have not seen any bug tagged as "ProposedEasyHack" which was touched by a developer and changed to "EasyHack"</li> <li>Furthermore, if an easy bug or enhancement request does not contain any information on being a easy hack, I have not seen anyone adding this flag to it afterwards, even if it is really easy. </li> <li>You mentioned that it is very very rare that someone "magically picks up" enhancement requests. My experience is different. Please see: bug 33751, bug 36734, bug 36735, bug 36946, bug 36977, bug 39167, bug 39168. This is an argument to be more laissez-faire with the end users adding enhancement requests and EasyHacks to bugzilla. I just propose this. In my opinion, it can help to drive innovation, to collect ideas, to identify easy hacks and to attract new developers. Please keep in mind that end users might not be that stupid not to be able to identify easy enhancements.</li> </ol> </ol> Summing up: I propose that "ProposedEasyHacks" are taken more seriously and are really be converted by someone to "EasyHacks" if identified to be really easy. Also, in my opinion, the mentorship-argument does not hold for really-easy-hacks (please see my examples above). Thanks, Gerald Am 05.08.2011 21:22, schrieb Kohei Yoshida: <blockquote cite="mid:1312572161.11171.16.camel@dell-t3500" type="cite"> <pre wrap="">Hi Gerald, First of all, thanks for introducing yourself on this list. I've been personally wondering who you were since you've filed several EasyHack bugs and I never saw your name or your email address here before. I'll leave the specific enhancement request discussion to the UX folks, but let me address several of your expectations below. On Fri, 2011-08-05 at 16:59 +0200, Gerald Leppert wrote: </pre> <blockquote type="cite"> <pre wrap="">Generally, my experience with enhancement requests in the LO bugzilla (mine or requests from others) has been that there is currently very little to no feed back, review, discussion or comments made to enhancement requests. IMHO this situation is a bit sad and I hope that this will be changing in the future. </pre> </blockquote> <pre wrap=""> Normally we don't respond to RFE's filed in bugzilla with enthusiasm unless there is a sign that the proposer is willing to invest development resources to help bring the RFE into fruition. We already receive an abundance of feature requests, and we simply don't have resources to respond to each and every one of them. So, I don't want you to have the expectation that, if you file an RFE, someone else will magically pick it up and make it happen. That's very very rare. </pre> <blockquote type="cite"> <pre wrap="">Improvements to hybrid PDF: As mentioned in the bug 39168, the hybrid PDF feature is one of the killer features in LibreOffice. However, its implementation has some practical and usability problems out of those most had been already raised in the OpenOffice.org bugzilla. However, most of them can be easily improved in terms of usability and handling. This was my intention of the three enhancement requests made to hybrid PDFs (bug 39167, bug 39168, bug 39169) and I was glad that Gabor liked the idea and took the initiative to start working on two of these easy hacks. Defending bug 39168: As described in the bug entry, the current file ending "pdf" is suboptimal and hybrid PDFs need to be made more visible to the user. In the current situation, the hybrid PDF feature is much less useful than it could be and in many cases it is even counterproductive (i.e. users who try to open 'real' PDF files in LibreOffice assuming that they are hybrid PDFs.) There is indeed no hint to the user what file actually is hybrid pdf. By the way, the file ending ".pap.pdf" is exactly how it is handled in Papyrus (<a class="moz-txt-link-abbreviated" href="http://www.papyrus.de">www.papyrus.de</a>) where the idea of hybrid PDFs was first implemented. Marking bug 39168 as 'invalid' without adding any criticism or comment to the bug entry itself is - in my opinion - inappropriate. </pre> </blockquote> <pre wrap=""> I personally don't object to your argument for the double extension, but I'd like to leave it to the UX folks to decide what would be the good design. Having said that, I'm not pleased to see someone mis-using our EasyHack system to inject his/her favorite features. EasyHack is designed to help new developers get a feel for our code base, and is supposed to be easy enough and/or have someone willing to provide code pointers & mentorship etc. It is not designed for the end users to submit his or her favorite pet peeves. If you file one, you are basically signing up to mentor for the implementation of that feature, either fully or partially. So, my question is, are you familiar enough with the code base to help Jenei work on this? Kohei </pre> </blockquote> </body> </html>