Great post, completely agreed! This may sound arrogant, but sometimes there are patches that simply seem hopeless. One strategy not to offend anyone while rejecting the patch is to intentionally ignore it.
Oliver On Sun, 12 Dec 2004 23:15:20 +0000, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On 12 Dec 2004, at 17:30, Felipe Leme wrote: > > > > > I would add a note to Danny's comment: treat contributors as your > > primary users. > > > > I have seem many projects (inside and outside ASF) where people submit > > patches and the patches are just ignored, without even an explanation > > why it was not accepted. I know that applying a patch is not that > > simple > > in most cases, but I think the risk of breaking something is lesser > > than > > the risk of losing a good contributor. After all, if the patch breaks > > something, you can fix it later; but if you piss-off a contributor > > he/she will probably put his/her efforts in another project. > > there is some truth buried somewhere in there... > > the time required to review, correctly and apply a patch is often > underestimated. projects with too little available committer energy may > get into a viscous circle whereby new committers cannot be recruited > because there's too little energy to review patches. one way round this > problem is to encourage users and developers to review patches > submitted by others. it's also useful to try to do some sort of > preliminary review and offer some kind words as soon as possible after > a patch is posted even if work on the core project prevents a full > review at this time. > > however, the quality of patches applied is crucial to the long term > health of a project. reviewing and rewriting patches is the only way > that developers are taught the standards required by the project. > applying substandard patches shouldn't break the project in the short > term (providing that it's adequately unit tested) but often produces > headaches in the medium and long term. > > though committing a few risky patches in the hope of recruiting a new > committer might seem like a good plan, there are definite drawbacks. > the energy gained by recruiting a new committer (in this fashion) can > easily be lost to the mentoring and refactoring required to produce > code of the correct quality align with the goals of the project. IMHO > it's almost always better (in the long term) for a developer to prove > that they understand the direction and philosophy of a project by > producing good patches which require no correction before they are > elected a committer. > > - robert > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
