[Libreoffice-ux-advise] [Libreoffice] Fwd: [PATCH] Bug 39167
gleppert at gmx.de
Fri Aug 5 13:51:55 PDT 2011
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:
1. 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"
2. 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
3. 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
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).
Am 05.08.2011 21:22, schrieb Kohei Yoshida:
> 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:
>> 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.
> 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.
>> 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
>> 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
>> (www.papyrus.de) 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.
> 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
> 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
> So, my question is, are you familiar enough with the code base to help
> Jenei work on this?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libreoffice-ux-advise