[Libreoffice] Handling EasyHacks in general (was: Re: [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167)

Hi Gerald, hi all!

Am Samstag, den 06.08.2011, 19:04 +0200 schrieb Gerald Leppert:
> Hi Friedrich, hi all,
>
> does anyone here have a less rigid opinion on that matter than the one 
> expressed by Friedrich? I really don't care whether you want LibreOffice 
> to be a developers AND users community or whether you want to separate 
> these two from each other; whether the LibreOffice community is 
> welcoming or not.

Well, I don't feel comfortable to comment Friedrich's statements - its
rather the opposite of what I feel makes this project progress. So I'd
like to state what happened "to me" so far.

In the past, we (the Design Team) have been asked by some developers to
collect usability issues and add those to the Easy Hacks. That's great,
since (I hope) that new developers are (also) attracted to solve those
issues that really "hurt" users.

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.

Sometimes, some more opinions are needed when addressing EasyHacks ...
e.g. documentation, QA or UX. I think that's something every developer
will agree to. Consequently, the underlying tool (issue tracking) is
used to enrich the hack with additional information (assuming that its
helpful). That might lead to some confusion what he Easy Hacks approach
is used for:
      * collecting / filtering Easy Hack proposals
      * assigning / tracking Easy Hack
      * QAing / documenting changes due to Easy Hacks


> I only would like to know how users are allowed / should / can 
> contribute to the EasyHacks-system. I am confused, because the original 
> EasyHacks wiki page did not carry any restriction on who may contribute 
> to it and my interactions with others on that matter had been always 
> positive. Also, the definition of the tag [ProposedEasyHack] is defined 
> as "As task that is thought to be easy to hack, but has not been checked 
> by a developer to not contain nasty surprises". Please advise.

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.

Cheers,
Christoph