Before making a contribution, it is important to make sure that the change you wish to make, and the approach you wish to take will likely be accepted, otherwise you may end up doing a lot of work for nothing. If the change is only small, for example, if it's a documentation change or a simple bugfix, then it's likely to be accepted with no prior discussion.
Additionally, there are issues labels you can use to navigate issues that a good start to contribute:
- Make sure you have signed the CLA; if not, sign it online.
- Ensure that your contribution meets the following guidelines:
- Live up to the current code standard:
- Not violate DRY.
- Boy Scout Rule needs to have been applied.
- Regardless of whether the code introduces new features or fixes bugs or regressions, it must have comprehensive tests. This includes when modifying existing code that isn't tested.
- Implementation-wise, the following things should be avoided as much as possible:
- Global state
- Public mutable state
- Implicit conversions
- ThreadLocal
- Locks
- Casting
- Introducing new, heavy external dependencies
- The Playframework-Core API design rules are the following:
- Play is a Java framework.
- Java APIs should go to
src/main/java, package structure iscore.myapipackage.xxxx - Features are forever, always think about whether a new feature really belongs to the core framework or if it should be implemented as a module.
- Code must conform to standard style guidelines and pass all tests.
- Basic local validation:
- Not use
@authortags since it does not encourage Collective Code Ownership.
- Not use
- Live up to the current code standard:
- Submit a pull request.
If the pull request does not meet the above requirements then the code should not be merged into main, or even reviewed - regardless of how good or important it is. No exceptions.
The pull request will be reviewed according to contributors availability.