Would you like to help us make the Groovy programming language even better? There are many ways in which you can get involved, make a difference and help the Groovy development team to make Groovy even, well, groovier? We really appreciate and welcome contributions and you can help us by:
- helping other users or discussing future language directions on the mailing-lists
- contribute to discussions on Slack - this channel is not endorsed by the Apache Software Foundation, it's run by Groovy enthusiasts in the community for casual conversations and Q&A,
- reporting or fixing issues you encounter in our bug tracker
- documenting various aspects of the language or its APIs
- Creating or commenting on the Groovy Enhancement Proposals which describe how we make significant changes to the language
- improving this website
- covering the code base with more tests to avoid future regressions,
- and of course, by contributing bug fixes or new features
Discussing on the mailing-lists and forums
If you encounter a problem, want to discuss a new feature, share interesting findings, and more, then the mailing-lists are the place to go to start a conversation with the Groovy developers and other Groovy users. Discussions on the mailing list are archived. It's the place to go to for all formal discussions or if you want to search the archives.
Alternatively, for more casual conversations and Q&A, consider using the Slack channel. (This channel is not endorsed by the Apache Software Foundation; it's run by Groovy enthusiasts in the community.)
If you are wanting to search existing issues, raise a new one or are keen to fix some existing issues, then you should become familiar with Groovy's Bug tracker.
Before submitting a new issue, we recommend you read our guide to reporting issues
Improving the documentation
The documentation of the Groovy programming language comes in various forms:
- the reference documentation covering the language specification, the user guides, getting started, and more.
- the GroovyDoc APIs documenting the classes of the Groovy code base
- the Groovy GDK documentation, explaining how Groovy enriches the JDK APIs
- this website
To contribute to the Groovy reference documentation, this blog post gives all the details on how you can work on that documentation.
All the above is stored in our code repositories on Github, so having an account on Github would be ideal.
Contributing to this website is fairly easy, if you have a Github account already, as you can click on the Improve this doc buttons that you can see on all the pages of this website. So don't hesitate to help us improve it, fix typos, broken language, clarify complicated sections, add new material, etc.
Please check the following section for more information on how to contribute to our codebase.
If you know the area you want to contribute to, this is great, but if you are looking for some first contributions, the Groovy development team tries to maintain a list of tickets of possible easy contributions that could get you started on your journey to become a Groovy committer. Just raise your hand on the Groovy developer mailing-list to tell us about your desire to work on that ticket.
For more complicated tasks, the best approach is also to bring that to the attention of the Groovy developers, so they can give you some guidance on how best to tackle a particular problem, discuss implementation ideas and the semantics or scope of the proposed change.
Cloning the code base
Make sure you configure Git appropriately with the same email that you registered with on Github:
git config --global user.name "YOUR NAME" git config --global user.email "YOUR EMAIL"
You can verify these are configured appropriately by running:
git config --list
Working on the code base
If you are working with the IntelliJ IDEA development environment, this screencast gives lots of details on how to setup your IDE.
Then, to work on the Groovy code base, to build and test Groovy, you can follow the instructions from the readme file in the Groovy repository.
The most important command you will have to run before sending your changes is the test command:
For a successful contribution, all tests should be green!
Creating a pull request
Once you are satisfied with your changes:
- commit your changes in your local branch
- push your changes to your remote branch on Github
- send us a pull request