openerp-community team mailing list archive

["Pieter J. Kersten" <p.j.kersten@xxxxxxxxxxx>]

You still miss my point. It is not in the behavior of the reviewers I 
foresee impoliteness, but in the fact that someone contributing a new 
module and making enhancements to his own module, is forced to convince 
a tribune of reviewers of the quality of this new contribution.

The flow can become: refuse it, refuse it, refuse it and then, when the 
quality is "high" enough - who says what's quality and what's high 
enough? - take it. Phew, it's in. You risk bashing people away by 
enforcing the mechanics alone.

A "politer" flow would be: take it, grant the author access to it, 
review it and then, if that "proves" to be necessary (for you?), enhance 
it in co-creation with the author. No sweat, everybody happy. That's the 
way OS has proved to work over the last few decades.

Op 22-11-12 12:12 schreef Alexandre Fayolle:
> On jeu. 22 nov. 2012 11:54:49 CET, Pieter J. Kersten wrote:
> > Hi Alexandre,
> >
> > You have taken my response out of its context. I was not speaking of
> > merges into other peoples code bases. They should be assessed.
> > Nonetheless a brute "no" is considered impolite there too. Even more
> > when it is the original author whose code you refuse. That can be
> > considered as hijacking.
> I agree with this.
>
> > You argue that code quality overrules politeness. But they are
> > different perspectives of the same issue. One cannot overrule the
> > other. Arguments from one perspective against the other are against
> > reality and therefore fruitless. You have to deal with both. I simply
> > state that following the proposed rule as some law of nature, will
> > inevitably lead to impoliteness. That should be avoided.
> Well, in an ideal world, of course, everyone will be kind and
> forgiving. I'm not
> the kind of person who bashes and swears for the sake of it.
>
> When I do a code review, I tend to state facts (on this line you do
> such and
> such, you should do such instead). It is generally quite dry. If the
> matter is
> important I will tag the MP as "needs rework" (which anyone with the
> correct
> privileges is free to ignore, although I would consider it rude to do
> so without
> discussing the issue first). But of course discussing is important and
> part of
> the process. Discussing means exchanging messages, and of course
> enhancing the patch being merged.
>
> In the end, there are then 2 possibilities:
>
> * the issue is technical, and one side will be able to convince the
> other that
> their approach is the correct one. Issue solved
> * the issue is non technical (it can be cultural, a matter of style or
> whatever else),
> and there is no "correct" answer in the end. People are expected to
> behave as
> adults and find a gentlemen's agreement and deal with it.
>
> The second case can take time, and maturity on the participant's side.
> Free software promotes meritocracy, and accepting others' arguments
> in a discussion is part of earning merit in a community.
>
> --
> Alexandre Fayolle
> Chef de Projet
> Tel : + 33 (0)4 79 26 57 94
>
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac Cedex
> http://www.camptocamp.com
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp