jules wrote:Yeah, but the thing is that I already have a system for merging code locally, and nobody has *ever* sent me any changes that I've used without needing to edit them in some way first. If I was to use github's merge tools, I'd need to merge the 3rd-party changes using the website, pull everything back to my local machine, review and edit the changes, re-commit my edits, and then push it out again to sourceforge. That'd be annoying, and would create twice as many commits as necessary.
Totally understandable but Git has super flexible workflows. The workflow you described is the straightforward way but suffers from the problem that you pointed out. Instead, you could pull a merge request into its own branch, sniff it out with testing and inspection, and if it was "perfect" (unlikely, as you pointed out) then pull it into master.
However if you don't like it then just delete the branch and leave a note to the submitter telling them what to change, and they can update the pull request. You wouldn't accept anything that wasn't right so there won't be double the commits. You would also not have to edit anything...just leave a comment in the opened issue.
If there was sufficient interest (and I strongly suspect there is), with a small investment of time you could outline some of your style requirements and one or more volunteers could handle pull requests instead of you, acting as a buffer. You wouldn't see a submission until it passed through one or two other people. Each submission would be isolated into its own branch for you to inspect at your leisure.
The github repo could have a "community test" branch which includes merged changes from submitters. Anyone could pull the branch and test the changes, this way there would be many people looking at it instead of just one or two.
It would certainly require some additional efforts to make this happen but the benefit is that work moves along in parallel. Truth be told you the first submissions will probably not be very appealing to you but as the style / coding requirements become documented and more transparent I think there will be higher quality pull requests and in fairly reasonable time you would get commits that you were comfortable accepting as-is - especially if there is a helper or two screening/editing them to suit your taste.
This means that all those little things that you had to say "I don't have the time to work on that right now" to, may suddenly get some attention.
Is there anyone else in the forum who thinks this is a good idea? Can anyone else weigh in on their likelihood to participate in such a scheme? Is there anyone who would volunteer to review pull requests and work with the submitter to make them Jules-approved? Would anyone be interested in helping put together and maintain a style guide?