Following our good discussion in the last ESC meeting, we have another example 
of how to demotivate a new contributor.

When a easyhack no longer has “needsDevEval” and “needsUIEval” is should be 
considered an accepted easyhack with sufficient implementation details.
When a patch has been submitted to gerrit and has been reviewed (in this case 
it pended quite long in gerrit) and has been merged, we should not start to 
discuss how the implementation should be on the BZ Issue.

Of course we all learn, and sometimes when we see the effect of an 
implementation, we realise how it should have been done, this is natural and 
not a problem. BUT please do not reopen the easyhack and do not suggest to 
revert it, instead take the positive approach and:

make a new easyhack, describing how the current status can be enhanced/changed.

That way we do not tell a new contributor his/hers work is rubbish (another 
less polite word for “revert”). Please remember the contributor did the best to 
follow the demands, so the problem is that the easyhack was accepted (in 2012) 
and nobody cared to give more implementation advice, before the work was done.

Sorry for a frank mail on a friday afternoon, but this is slowly becoming a 
bigger problem. We have enough problems helping new contributors become skilled 
LO developers, there are absolutely no need to create more problems.

jan I.

> On 14 Oct 2016, at 19:10, bugzilla-dae...@bugs.documentfoundation.org wrote:
> Comment # 22 <https://bugs.documentfoundation.org/show_bug.cgi?id=46279#c22> 
> on bug 46279 <https://bugs.documentfoundation.org/show_bug.cgi?id=46279> from 
> Heiko Tietze <mailto:tietze.he...@gmail.com>
> As discussed in the UX meeting Oct/14 the recommendation is to revert the
> patch; and in general to add the restart option to the extension 
> specification.
> You are receiving this mail because:
> You are on the CC list for the bug.

LibreOffice mailing list

Reply via email to