source: Dev/branches/play-2.0.1/documentation/manual/hacking/PullRequests.md @ 322

Last change on this file since 322 was 322, checked in by hendrikvanantwerpen, 13 years ago

Added Play! framework and application with Jena dependency. Working on
the basic things now (login/register), after that start implementing
our data model.

File size: 2.0 KB
Line 
1# Pull requests, and Play!
2
3Here are some guidelines for submitting pull requests to the Play project (and why your request might not be accepted).
4
5The 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.
6
7## A moving target
8
9The 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.
10
11## Features are forever
12
13Unfortunately, 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.
14
15Any decision to add or remove even a minor feature has serious consequences and has to be considered carefully and thoroughly.
16
17## If you're keen to contribute
18
19But 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.
Note: See TracBrowser for help on using the repository browser.