[csw-maintainers] Code and package reviews

[Maciej Bliziński]

2011/6/27 Philip Brown <phil at bolthole.com>:
> 2011/6/26 Maciej Bliziński <maciej at opencsw.org>:
>>
>> The non-inclusion of reviews as a gating factor in the proposal is
>> intentional.  It might of course change - but so far, it has been
>> group's intention not to involve a human controlling package releases.
>>
>> Peer reviews are an excellent mechanism to improve quality.  My
>> intention is to create an environment in which maintainers want their
>> packages reviewed.
>
> providing some kind of positive motivation is nice. Its a great
> management strategy.
> but what could be used as sufficient motivation?

My first thought is: giving helpful reviews!  This does of course mean
pointing out issues, but also giving explanations why the issues in
question are important, and suggestions how to tackle them.

>>Package review status would then appear on the web, in places such as
>>maintainer's page, and package pages in the buildfarm database.  It
>>would be a form a beneficial peer pressure, where maintainers would be
>>proud of having their packages reviewed
>
> btw, we've tried similar incentives before, in the form of the bug scoring page.
> While I think this sort of thing appeals to some, it is not universal.
>
>
> Sadly, no amount of "incentive" helps in the case of a person who has
> the attitude of,
> "nothing appeals more to me than not having someone else review my work"
> Additionally , it often happens, in all kinds of areas (software
> programming, article writing, and others)
> that the people who are most resistant to having others review their
> work, are the ones that need it most
> :(
>
> Is that something you are ok with? Because that's what this sort of
> thing comes down to in the end, really.

Am I OK with people resisting reviews?  Nobody can stop anybody from
reviewing their work if it's published, but there can be someone not
willing to listen, or not willing to follow suggestions.  Am I OK with
people willing to listen or not following suggestions?  It depends.
If this happens, it's either because they don't understand the
problem, or because they don't share goals with the reviewer.  The
second issue is harder, in such case the two people need to talk.  It
helps if agreed goals of the group are available in writing, so that a
common ground can be established.  The reviewer also needs to take it
into account that the review receiver has no obligation to follow all the
suggestions.  If there are suggestions that are not part of group's
common goals, the review receiver may simply decline to follow them,
and that's fine.  The reviewer needs to understand that he or she
needs to be reasonable and that it is a conversation between equals.
The reviewer's role is only to help.

While I'm not OK with someone not understanding what the issue is, I'm
OK with someone declining to follow a suggestion if the package
complies with our standards and policies.  For example, if the issue
is that the package is missing a dependency, it's a clear policy
issue.  If the issue is something like whether to use a regular file
or a symlink to one, and it doesn't pose an operational problem, then
the reviewer should let go and save stamina for another time.

Maciej