We've used the GitHub pull-request model for several years, and it works well. But I do agree with most of what Colby and JesseK have mentioned. As a professional open source developer, I insist on good unit tests in all the projects I run, and where possible continuous integration (via Jenkins, Travis, or something similar).
Our team has made extensive use of unit tests, but the WPILib makes this very challenging; see
our presentation on this topic at the
2015 FIRST World Championship Conference. Because it is so difficult to write tests for WPILib robot projects, in 2015 we ended up creating our own API of hardware interfaces just so that we can unit test without the WPILib classes. This past summer we extracted all of that code and started the
Strongback open source Java library. Hopefully you can benefit from at least its ideas, if not by directly using the library. Get started by reading our Using Strongback online book, which documents the library, how to use it, and how you can write normal unit tests with it.
But having unit tests is of very little benefit if they are not used. Robot projects that use Strongback can use and run JUnit tests via the excellent JUnit Eclipse plugins, but they also have Ant tasks to run all of the unit tests inside the project. We recommend developers do this very frequently -- run them from within Eclipse after you change code, and then run them before committing and certainly before creating a PR.
We'd like to enhance Strongback's Ant tasks to dynamically download the WPILib libraries, making it possible to set up Travis to automatically build and run all tests as soon as a PR is created. We hope to have this soon, and will document how to set everything up.