12

When managing an open source project (using a service like GitHub) how would one respond to the following:

Somebody has kindly submitted a patch to add a new feature or address a problem. Any one of the following situations occur:

  • The source code doesn't meet one or more naming conventions, etc.
  • I feel that the source code could be improved in a certain way. Perhaps the same effect can be achieved with far simpler source, or perhaps another useful feature would be needed.

Q1. Is it acceptable for me to alter the submitted source? (is this possible on GitHub?)

Q2. Should all such submissions be rejected in accordance with submission guidelines?

Q3. If yes to Q2, what about a really neat idea that was poorly implemented? Is it acceptable for me to just go ahead and create my own?

I want to encourage contribution but at the same time it is important to maintain a certain standard.

| improve this question | |
7

Set up, if you haven't already, a document that describes the project's standards. Be sure to outline everything you feel is important when contributing code to your project.

Then, respond to the person who supplied the code detailing that you very much appreciate the contribution, and that you would like to include the patch, but there are some issues. Provide a link to the document and cite the particular issues you see. Then, ask that person to fix the issues and resubmit the code.

| improve this answer | |
  • I think linux kernel has some sort of "changes that needs improvements" area for this scenario. – seppo0010 Aug 21 '11 at 20:06
  • 1
    In the long run, it will benefit the project and the community as a whole if you get people to improve their own submissions. But it is absolutely okay to re-implement the feature yourself, provided you are polite about it. – David Schwartz Aug 21 '11 at 21:20
  • 1
    I've seen quite a few projects that automate some of this stuff whenever you request for a pull. – Andrew T Finnell Aug 22 '11 at 3:17
  • Just a note for those using GitHub, if you name the document referenced above CONTRIBUTING, then a link to this document will show when submitting a pull request. It can help save some time upfront if people can resolve common issues on their own first. – Michael Mior Mar 3 '14 at 18:57
2

If there aren't too many contributors, and this contribution is fairly valuable, you could accept the patch as is, and then, in the next commit, rewrite parts of it yourself, or reformat it to confirm to the coding standards. — Then, afterwards, you'd send an email to the contributor, with a link to a diff of the changes you made. Hopefully the contributor will then study the diff, and submit a better patch the next time, which you don't need to amend.

This might be a good idea, if you have not yet written any Contributors Guide or Coding Style documents. In fact, you could continue in this manner (accept and amend patches, email back links to diffs) for a while, until you've noticed what mistakes most contributors do. And then you include only those mistakes in a Contributors Guide and a Styling Guide.

If you do things in this manner, answers to Q1-Q3 would be:

  • Q1: Yes, edit the submission, in a subsequent commit
  • Q2: Not applicable (I've assumed you have not yet written any guidelines)
  • Q3: Say thanks and rewrite it :-) (Perhaps it's pointless to apply a patch at all, if, in the next commit, you rewrite it completely anyway)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.