Welcome Martin! The simplest way to start would be to look for areas the documentation can be shored up. This can be a good place to start for folks a bit new to Groovy, since you'll be digging into the code to make sure provide an adequate and accurate description. The difficulty here of course is identifying where the docs need help. One place I know of offhand is the Using DataSets <https://github.com/apache/incubator-groovy/blob/master/subprojects/groovy-sql/src/spec/doc/sql-userguide.adoc#using-datasets> section of the SQL userguide. One trick I use to identity documentation needs is to keep an eye on what people ask on StackOverflow and on the user mailing list. If something was unclear to someone, obviously the docs need work. You might ask on the dev list or using the PR process <http://blog.cacoethes.co.uk/groovyandgrails/contributing-to-the-groovy-documentation> Peter suggested before starting any big changes, just to be sure you're not duplicating effort with someone else.
If you really want to start with code, in my opinion, Groovy-JDK issues are often easier. You might have a look here <https://issues.apache.org/jira/issues/?jql=component%20%3D%20groovy-jdk%20AND%20project%20%3D%20GROOVY%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC> and see if anything catches your interest. A lot of my PRs started as a comment or Jira from someone else that made me say "yea, I want that too!". If it's been around a while though, you might first check if there's a reason it isn't already done so you don't waste your time. And of course, you don't need formal permission to start experimenting with ideas. PRs are most welcome! Even if your idea is totally crazy -- make a branch in your fork and ask for comments. I'm confident you'll find Groovy development to be a very friendly and welcoming community. -Keegan On Wed, Jul 22, 2015 at 1:32 AM, Martin Lukas <[email protected]> wrote: > Hi Cedric and Jochen, > thanks for you answers! I absolutely understand your concerns. My proposal > would be to entirely decouple the comparator operators and the compareTo() > method as this might be considered as elegant solution but not the most > flexible one when it comes to the definition of DSLs. Such a strict > decoupling would clear up the mess but also possibly break some > compatibilities and, thus, justify that this should be part of a major > release. > > Do you have some suggestion which other parts I might contribute to first > instead? I am a Java expert and very experienced when it comes to > algorithms. Still, the comparator overloading is very close to my heart and > I will revisit it later on after I gained some more Groovy experience as I > very much like to see it in 3.0. > > Thanks, > Martin > > > > -- > View this message in context: > http://groovy.329449.n5.nabble.com/GROOVY-2756-Would-like-to-become-a-contributor-tp5726223p5726514.html > Sent from the Groovy Dev mailing list archive at Nabble.com. >
