The best ways to contribute are by finding and reporting bugs, writing tests for bugs, and improving the documentation. We’re always grateful for patches to Play’s code. Indeed, bug reports with attached patches will get fixed far quickly than those without.
If you want to change the code, be careful follow our design-decisions. Be especially careful not to break compatibility with modules and older versions, or to increase complexity if you don't have a really good reason. See also: coding-style guide.
Process to submit a patch
- Create a lighthouse account on http://lighthouseapp.com
- Create a ticket in the play project on lighthouse. Remember the ticket number on http://play.lighthouseapp.com/dashboard
- Create a github account on https://github.com
- Open the play project home page on github on https://github.com/playframework/play1
- Click "Fork"
- Clone your forked repository on your local machine (don't clone the original repository)
git clone email@example.com:your-username/play1.git my-play-repo
- Create a branch and switch to it
cd my-play-repo git branch lighthouse-XXX-patch git checkout lighthouse-XXX-patch
- Make your changes, then commit them. Include the lighthouse ticket number at the start of the commit message, eg [#XXX]
git commit -m "[#XXX] Fix something really important"
- Push the changes from your local branch to your forked repository on github
git push origin lighthouse-XXX-patch
- Open your forked repository on github at https://github.com/your-username/play1
- Click "Switch Branches" and select your branch (lighthouse-XXX-patch)
- Click "Pull Request"
- Submit your pull request to play developers
Fixing the documentation
The documentation is provided as textile files in the framework distribution. You can contribute to the documentation the same way as for code, or create a ticket with the documentation tag to report issues and contribute corrections and small additions.
You're free to fork the main version, apply whatever changes you want and ask us to merge your changes. But we don't give any guarantee that we'll merge your changes. In general, any patch that modifies the core framework interface/life-cycle will probably never be merged. Typically, any patch that change the expected result or behavior of the test suite will be rejected. Tests should only be expanded.
Always include Lighthouse ticket numbers in your commits
Github-Lighthouse integration makes it possible to link github commits and Lighthouse tickets. Contributors should do this, so we can trace changes better:
- From a git blame to the commit to the ticket, we can understand why a specific line has been changed and see why the code is the way it is
- From a resolved ticket that came back, we can see how it was fixed in the past and investigate why a regression appeared
This is pretty important for code quality to have this traceability, and it will help us release stable versions more often with confidence. To write a commit message that links to a Lighthouse ticket, include the ticket number like this:
[#42] Fix stuff
You can also fix the ticket directly from the commit if you want. This is not especially useful, since the real value is in linking ticket and commit but feel free to do so if you want. See github commit parsing for details.
Moving forward, with the exception of commits just fixing whitespaces or code style, we should get to the point where every commit has a ticket number. So before you commit, create a Lighthouse ticket if there isn’t one.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Play makes it easier to build Web applications with Java. It is a clean alternative to bloated Enterprise Java stacks. It focuses on developer productivity and targets RESTful architectures. Learn more on the <a href="http://www.playframework.org">http://www.playframework.org</a> website.<br><br>
<h2>Source code is hosted on github</h2>Check out our repository at <a href="http://github.com/playframework/play">http://github.com/playframework/play</a><br><br>
<h2>Contributing, creating a patch</h2> Please read the <a href="http://play.lighthouseapp.com/projects/57987/contributor-guide">contributor guide</a><br><br>
<h2>Reporting Security Vulnerabilities</h2> Since all bug reports are public, please report any security vulnerability directly to <em>guillaume dot bort at gmail dot com</em>.<br><br>
<h2>Creating a bug report</h2> Bug reports are incredibly helpful, so take time to report bugs and request features in our ticket tracker. We’re always grateful for patches to Play’s code. Indeed, bug reports with attached patches will get fixed far quickly than those without any.<br><br>
Please include as much relevant information as possible including the exact framework version you're using and a code snippet that reproduces the problem.<br><br>
Don't have too much expectations. Unless the bug is really a serious "everything is broken" thing, you're creating a ticket to start a discussion. Having a patch (or a branch on Github we can pull from) is better, but then again we'll only pull high quality branches that make sense to be in the core of Play.
Completed 20 of 23 tickets