I’ve heard many times that Dist::Zilla makes it harder for people to contribute to the project. This is not true, it is either unfortunately either ignorance or FUD (much like saying Linux is harder to use than Windows). Truly, there are things that some dzil users do that can make it harder, but it doesn’t have to be that way. Michael Schwern recently contributed to one of my dzil projects without ever realizing I was using dzil, until I told him. He more recently stated on twitter, “While your solution works, it seems like it makes more work for you to shield contributors from dzil”. This was true in this case because I wasn’t sure how to effectively move a series of multiple patches, I now know it’s easy to do with git. Here’s how you can allow contributors to contribute to your dzil project without causing you or them undo pain.Don’t use anything that changes the line numbers of your sourceExamples: don’t use DZP::Prepender. Use modules like OurPkgVersion to insert VERSION, and make sure your # ABSTRACT and any pod is below the 1; at the end of your module. This will keep the line numbers of errors in your code from being different from the final build. It’s still ok to use PodWeaver as it will save you way more time than it’ll hurt, so long as you follow the rules about pod being at the bottom Use a plugin that commits builds to your source control software I personally recommend DZP::Git::CommitBuild Make your build branch your default branchI’m not sure how to do this with just git, but on github you can go to the admin section of your repository and change the default branch there. This makes it so that when someone clone’s your repository the initial checkout is of your build branch. Your build branch shouldn’t require dzil, it’s the final build. Now that you have your final build branch as the default branch anyone who wants to contribute can simply clone your repo and start hacking. Their are a couple of mistakes they could make, They could either change or add files that are maintained, or pruned by dzil. This did happen when Schwern sent me patches, one of them was the addition of a .gitignore, which I already had, but is being pruned out of the build branch. I can also see it happening to meta’s and makefiles. These patches can simply be rejected as unnecessary, dzil-ified, or if they are truly a bug, then they can be reported and fixed upstream.So what if someone sends you a pull request from build/master? well if it’s just one or two patches, you add their remote, and do a git remote update and then you can git log remote build/master to find the sha1 of this patch. Now that you have the sha1 all you have to do is git cherry-pick [sha1] and it should apply. If there are any conflicts you may have to resolve them with git mergetool. However, the only conflict with Schwern’s patches for me was the .gitignore, all other patches applied without assistance and applied correcly, surprisingly even the pod patch applied without issue.If you have more patches than is comfortable with git cherry-pick then you need git rebase. The command you want is git rebase -i –onto master [sha1 before first sha1 in series] [tip of remote branch checkout]. So in my case git rebase -i –onto master 3f1e3748 schwern. What this appears to do is ends up rewriting my local schwern/build/master checkout and removes all the build commits, and then applies the patches on top. This means I can now do git merge schwern from the master branch, and all of his patches that I want will be successfully merged. For more on this strategy you may want to read this stackoverflow question.given this is not quite as easy as a git pull that’s a fast forward, but reality is it’s not that hard once you know how to do the rebase and how it works. Of course this isn’t ideal for constant contributors, those should simply learn to use dzil, but for the random contributor it should be ok.– This work by Caleb Cushing is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.