[Bug 46279] Show restart message after extension installation or update menu automatically

[Jan Iversen]

> - 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.