Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index



- It might well be that in the existing easyHacks, there are some that
didn't go through the now set careful procedure.
To check if there are issues overseen, maybe we can ask 'UX' to do a
review of the existing (older) easyHacks with relation to UI?
Please set the needsUIEval keyword on any easyHack the UX team want to review. Doing so, removes 
the easyHack from the list contributors use when searching.

In my mind it is better adding needsUIEval when in doubt and thus avoid problems later.

Remark for new easyHacks where UI or workflow are involved, I (among others) set the needsUIEval 
keyword.

Just to be complete, for gerrit patches (which may or may not be based on BZ) from contributors 
where UI or workflow are involved, part of the UX team are added as reviewers.


- Since we want to be maximal encouraging to new hackers, it is unsure
who follow-up issues will be handled of course.
To prevent that (in some rare cases) favoring more devs will result in
poor UX, maybe we can ask 'dev' to commit themselves to fixing those, if
these are not picked up in reasonable time by an easyHacker?
Why would we handle the follow up easy hacks different, than other bugs, gerrit patches etc (about 
1/5 of contributions from non committers are not based on BZ).

In my experience, it is more likely that a gerrit patch (or direct commit), needs a follow up, than 
a easyhack.

While I understand and share the concern, I see it being rather difficult to make our community 
make such a commitment. Would be nice though, and if successful it should be expanded to cover 
critical bugs as well.

I think it is important not to put demands on our community, we all want to have fun while working 
with LO, because it is (for most people) done in our spare time,  which means most do what they 
like to do and not what they are told to do (that is for $DAYJOB).

- In the end we can not prevent that someone reopens a fixed easyHack.
Might that happen, let 'us' react soon and friendly (maybe via direct
mail) explaining and such.

The ‘us’ in this situation is part of my daily monitoring, and based on the last ESC meeting, I 
close such bugs (with few exceptions), with a note about please make a followup bug.

Another possibility is to limit who can reopen a bug, that would motivate people to make a new bug.

Rgds
jan I.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.