glibc development and conflicts of interest

[Joseph Myers <joseph at codesourcery dot com>]

I have seen some comments in some recent glibc discussions that could be 
interpreted as people giving preference to their colleagues rather than to 
the public, collaborative discussion in the glibc community as a whole.

I think it's important to avoid that appearance in glibc development.  (I 
am not asserting that in fact such preference has been given, simply that 
the appearance of it should also be avoided.)  Where there could be 
conflicts of interest, I think the following should be considered good 
practice:

Err on the side of being *more* critical of your co-workers because they 
are your co-workers, not less - hold them up to higher standards in public 
patch review than unconnected patch contributors.  Err on the side of 
deferring *more* to the community on patches where such a conflict of 
interest could arise, not less - when you have good arguments, they will 
still reach consensus in the community.  If other contributors to the 
discussion are making irrelevant comments (e.g. suggestions that are not 
application on your architecture), stick to objective facts in response, 
and maybe let other people read the consensus to see that your comments 
are relevant where the other ones are not.

If you have been involved in internal discussion or design of a patch, 
take extra care to ensure that review is based only on what is public and 
that sufficient rationale for the patch is included in the submission, 
including answers to any questions raised internally that might also be of 
relevance to the public discussion; avoid citing internal discussion, or a 
contributor's connection to you, as justification for a patch.  Take extra 
care to ensure that your patch review in such cases is in accord with 
community consensus.

-- 
Joseph S. Myers
joseph@codesourcery.com