§Pull requests, and Play!

Here are some guidelines for submitting pull requests to the Play project (and why your request might not be accepted).

The reason we’ve written it is that we’ve had to reject a bunch of requests recently - not because they’re not good - just because they don’t match our current project priorities. Each request needs to be assessed and managed appropriately, and if you look at the commit logs you’ll see we’re stupidly busy at the moment and need to make some tough decisions on where our time goes.

§A moving target

The Play2.0 framework is under heavy active development by the core team, and the codebase is changing rapidly. Small fixes and changes for bugs without tickets are a very low priority at the moment (though this will obviously change once the framework become more mature). Pull requests for minor issues - especially for things like cleaning whitespace, indenting, or fixing minor typographical issues will most likely be rejected.

§Features are forever

Unfortunately, pull requests that add new features to Play are also likely to be rejected. A framework needs to fit the majority of cases, and can never cater for every situation: features that are absolutely essential to one team, will be redundant bloat to another. Additionally, any code that is merged into Play needs to be supported for a long long time. Adding support for something means maintaining, testing, and updating the related code throughout the framework’s life - which requires resources from other parts of the project.

Any decision to add or remove even a minor feature has serious consequences and has to be considered carefully and thoroughly.

§If you’re keen to contribute

But good code is good code, and good ideas are good ideas. If you’re serious about getting involved, you spot problems with code, or have a feature that you really think is missing (or shouldn’t be present) then jump on the mailing lists and discuss it. We just don’t want anyone to waste time creating some cool stuff that we can’t use.