Reviewing the process for giving people commit rights

[Kevin Kofler]

Nate Graham wrote:
> This caused a problem recently in KWin. A new contributor was given
> commit rights very soon after he appeared, and then immediately after
> that, he inappropriately merged a not-fully-reviewed an un-accepted
> merge request
> (https://invent.kde.org/plasma/kwin/-/merge_requests/1980). It seems
> that he did not have a sense of the cultural norms around committing to
> KDE repos, and giving him commit access was probably premature.

Well, the question this calls for is why the merge request was still not 
fully reviewed almost six weeks after submission. I would guess that that is 
what the misunderstanding came from: the submitter most likely assumed that 
the changes were fine given that there were no outstanding comments. (The 
submitter did try to address those comments that you had in those six 
weeks.)

I should also point out that the complaints in Xaver Hugl's post-merge 
review were all only formatting/whitespace, choice of comment sign, and 
brace issues (with no effect on the end user at all), except for one 
debugging message to stdout that the submitter forgot to remove. So I do not 
see the big catastrophe there.

But yes, teaching the implied rules of the KDE community in general, and the 
subproject they will be working on (KWin in this case) in particular, to new 
contributors is needed, considering that the ACLs technically allow doing 
things that are not acceptable according to community procedures 
(necessarily so, because a bot cannot distinguish an obvious compile fix 
from a new feature that needs review).

        Kevin Kofler