Get a peek into the inners of the Scala compiler.
File a bug report or a feature request.
Why contribute a patch to Scala?
Just to name a few common reasons:
- contributing a patch is the best way to make sure your desired changes will be available in the next Scala version
- Scala is written in Scala, so going through the source code and patching it will improve your Scala-fu
- last but not least, you will make it into the Scala Contributor Hall of Fame.
The main Scala project consists of the standard Scala library, the Scala reflection and macros library, the Scala compiler and the Scaladoc tool. This means there’s plenty to choose from when deciding what to work on. Typically the scaladoc tool provides a low entry point for new committers, so it is a good first step into contributing.
On the Scala bug tracker you will find many bugs that are marked as good starting points to contributing (“community” bugs) or that are not currently assigned and that you could pick up. Once you decided on a ticket to look at, see the next step on how to proceed further.
If you are interested in contributing code, we ask you to sign the Scala Contributor License Agreement, which allows us to ensure that all code submitted to the project is unencumbered by copyrights or patents.
Bug-fix Check List
This is the impatient developer’s checklist for the steps to submit a bug-fix pull request to the Scala project. For more information, description and justification for the steps, follow the links in that step. Further specific instructions for the release of Scala you are targeting can be found in the
CONTRIBUTING.md file for that github branch
- Select a bug to fix from JIRA, or if you found the bug yourself and want to fix it, create a JIRA issue (but please make sure it’s not a duplicate).
- Optional (but recommended), announce your intention to work on the bug on scala-internals. After all, don’t you want to work on a team with these friendly people - it’s one of the perks of contributing.
- Fork the Scala repository and clone your fork (if you haven’t already).
- Create a feature branch to work on: use the branch name
issue/NNNNwhere NNNN is the JIRA issue number.
- Fix the bug, or implement the new small feature, include new tests (yes, for bug fixes too).
- Test, rinse and test some more until all the tests pass.
- Commit your changes to your feature branch in your fork. Please choose your commit message based on the Git Hygiene section of the Scala project README.
- If necessary re-write git history so that commits are organized by major steps to the fix/feature. For bug fixes, a single commit is requested, for features several commits may be desirable (but each separate commit must compile and pass all tests)
- Submit a pull request following the Scala project pull-request guidelines.
- Work with a reviewer to get your pull request merged in.
Need more information or a little more hand-holding for the first one? We got you covered: take a read through the entire Hacker Guide for an example of implementing a new feature (some of the steps can be skipped for bug fixes, this will be obvious from reading it, but many of the steps here will help with bug fixes too).
Larger Changes, New Features
For larger, more ambitious changes (e.g. new language features), the first step to making a change is to discuss it with the community at large, to make sure everyone agrees on the idea and on the implementation plan. Announce the change on the scala-internals mailing list and get developer feedback. For really complex changes, a Scala Improvement Process (SIP) document might be required, but the first step is always to discuss it on the mailing list and if a SIP is required, that will be discussed on the mailing list.
Contributions, big or small, simple or complex, controversial or undisputed, need to materialize as patches against the Scala project source tree. The hacker guide will explain how to materialize your idea into a full-fledged pull request against the Scala code base.