7 Cleaning Up Changes

Don’t feel obligated to include every change that someone asks you to include. You must judge which changes are improvements—partly based on what you think the users will like, and partly based on your own judgment of what is better. If you think a change is not good, you should reject it.

If someone sends you changes which are useful, but written in an ugly way or hard to understand and maintain in the future, don’t hesitate to ask per to clean up their changes before you merge them. Since the amount of work we can do is limited, the more we convince others to help us work efficiently, the faster GNU will advance.

If the contributor will not or can not make the changes clean enough, then it is legitimate to say “I can’t install this in its present form; I can only do so if you clean it up.” Invite per to distribute per changes another way, or to find other people to make them clean enough for you to install and maintain.

The only reason to do these cleanups yourself is if (1) it is easy, less work than telling the author what to clean up, or (2) the change is an important one, important enough to be worth the work of cleaning it up.

The GNU Coding Standards are a good thing to send people when you ask them to clean up changes (see Contents in GNU Coding Standards). The Emacs Lisp manual contains an appendix that gives coding standards for Emacs Lisp programs; it is good to urge Lisp authors to read it (see Tips and Conventions in The GNU Emacs Lisp Reference Manual).