[Libreoffice] Handling EasyHacks in general (was: Re: [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167)
bjoern.michaelsen at canonical.com
Sun Aug 7 14:47:17 PDT 2011
Hi Christoph, all,
On Sun, 07 Aug 2011 14:32:08 +0200
Christoph Noack <christoph at dogmatux.com>
> Whenever I've intended to add an Easy Hack (means: before or after
> adding it to the issue tracker), I've asked a developer to have a look
> at it, because: I feel confident with regard to UX matters, I know
> some basics how LibO/OOo works, but I have _no_ clue about the
> internals. Every time, I've got a friendly and helpful reply ...
> But: I've pinged those devs which I know personally, that's something
> which a) might bother them in the long run, and b) isn't suitable for
> the rest of the community.
Doing that for every bug separate is indeed be inefficient and
annoying in the long run. I would propose to just mark such bugs as
"ProposedEasyHacks" and set the importance right on them. Then you
could post this query(*):
in a reminder to the developer list from time to time (once a month
maybe?), asking for a developer to check the most important proposals.
Wait for a "[Checked]" reply by a dev, just as one gets a "[Pushed]"
reply to a "[Patch]" email.
As stated elsewhere, I think the aims of the EasyHacks and the
improvement of released product are rather disjunct. If a coder
comes to the project with clear intention to work on a specific
issue, nobody will stop him to improve the released product because
the work he likes to do is not marked as an EasyHack. But this is not
what the EasyHacks are there for -- they are for the people coming to
the project with _no_ clear idea what to work on.
> Very good questions ... it would be cool if some of us (QA, dev, UX)
> could chat about that (Hackfest in Munich, anyone?). At the end, Easy
> Hacks is only one way how an issue / wish is turned in something a new
> developer may work on. I'm sometimes also unsure how to handle Serious
> Hacks, even strategical stuff.
I just decided: I will be there.
Bjoern (from vacation)
There is a "bug" still in the querys used on the wiki pages: they
currently not only include "EasyHacks", but also "ProposedEasyHacks".
ProposedEasyHacks might still be listed on the wiki-pages, but should
be in a separate section IMHO. Another good reason for:
(*) ProposedEasyHacks sorted by importance
More information about the LibreOffice