[Development] Approver status

[André Somers]

Hi,

Op 25-5-2012 8:27, lars.knoll at nokia.com schreef:
> I agree with Andre. Currently we do not have any guiding criteria in
> place, so it's probably difficult  to judge when someone is ready to be
> nominated as an approver. We've now had one or two cases where people
> where being nominated a bit too fast for my taste.
This André disagrees. I have checked my ML archives, but I could not 
find any case where such doubts were uttered on the ML by you. I think 
that if you think these people were nominated too fast, I think you 
should have voiced that opinion. Isn't that what the two week period is 
for? Do we see problems with the people who have been given Approver 
status, or do they function as hoped? Is code quality decreasing because 
of insufficient experience perhaps? In my view, we should only change 
the rules if we see that there are problems with the Approvers we have, 
and it is reasonable to suspect that these are caused by these Approvers 
not having enough feeling with the project yet.

> But I'd propose that we have a discussion to nail down the details at the
> contributor summit. It's only a couple of weeks away, and these things are
> usually discussed a lot easier in such a setting.
You are right about that, but since I won't be there, I'll voice my 
input here and now, and hope you'll take it to Berlin into the 
discussion. I think that defining fixed number of LOC or hours spend on 
the project is not going to work. Please don't go there. Who's really 
counting the hours he put into the project? And as you say yourself: 
LOCs are a bad measure. You're introducing arbitrary measures without 
any real gain. I do think this is reasonable though:

   Nomination for Approver status requires contribution or maintenance
   of a significant amount of code, or comparable activitities
   directly attributable to the nominee.

  Though the wording could be even clearer. It being written in the 
third person, makes it hard to parse who does the nominating. The word 
"Nomination" in the sentence above can - to my non-native speaking eyes 
- both means the _action_ of nominating somebody else, and the _status_ 
of _being_ nominated by somebody else. I assume you mean the latter, but 
that is not clear in this sentence. At least not if seen in isolation. I 
don't think it is needed to define "significant" here.

Bottom line: let's not introduce rules that are supposed to solve 
problems that have not occured, and that are likely to cause more 
problems than they might ever prevent occuring in the first place. I 
would like to stimulate people to make the most of the current set of 
rules: if you have a doubt about an approver nomination, just voice it.

André

>
> Cheers,
> Lars
>
> On 5/24/12 10:36 PM, "ext André Pönitz"
> <andre.poenitz at mathematik.tu-chemnitz.de>  wrote:
>
>> Hi all.
>>
>> I'd like to propose the following addition to the "How to become an
>> Approver" section on http://qt-project.org/wiki/The_Qt_Governance_Model:
>>
>>   "Nomination for Approver status requires contribution or maintenance
>>    of a significant amount of code, or comparable activitities
>>    directly attributable to the nominee. The attributable activities
>>    should typically exceed N lines of new, or M lines of changed
>>    code, or P hours of activities on behalf of the project."
>>
>> N, M, and P are open for discussion, as well as the wording,
>> here, and perhaps at the Summit.
>>
>> I understand that "Lines of Code" is an extremely bad measure for
>> almost everything, but given that we talk about a project in the
>> seven digits number of LOC, expecting N, M, and P, in the, say,
>> three, four, and two digits range respectively does not appear
>> overly unreasonable to me.
>>
>>
>> On a related note, I also think it would be sensible to move the
>> barrier of entrance to "Handle JIRA" into the opposite direction.
>> Triaging issues or verification of fixes are definitely tedious and
>> reputable activities, but I don't think they necessarily need
>> preceding contributions, nor long term dedication.
>>
>> Andre'
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development