So you want to fix something, or gasp improve, a part of the GeoTools library?

Chances are people have encouraged you in your geotools endevour (we all love volunteers!). The following document outlines some guidelines to help make all of our lives easier (including yours).

Give warning - Get Permission

Lets follow a couple of steps - just to start out with. The goal here is to let everyone know what is happening, and see if other are willing/able to help.

Step One: Talk to the module maintainer

They may already have plans, and they might help, they may do step number two for you...

Most likely chris will respond with the request that you make a Jira task (Chris is good that way).

Step Two: Set up a Jira task

Jira tracks features as well as bugs. Create a Jira account (if you have not already), and set up a Jira task
for your proposed work.

Step Three: Email the list and explain what you want to do.

We are not too formal, we just want to keep the lines of communication open.

Even if if you are the module maintainer it is nice to email and give people a couple days notice, or ask for a vote if your changes will break other peoples code.

You never know, people may offer to help

Step Four: Ask for forgiveness

Sometimes what you are asking so so strange that nobody will reply (or vote), and as a guidline I wait about three days before going ahead.

Do send a final email out to the list and maybe ask the exhaulted leader to speak for the module maintainer that did not reply to you?

It is also recomended that you strike up an ext/module and write some code for people to look at: chances are they did not understand you.

Step 0: Don't break the Build

And remember don't break the build.

We do have this nice rule about breaking the build (don't). This means that if you are hacking core interfaces you will be running all over the place cleaning up modules.

One very good reason to talk to the list first is to give other module maintainers a chance to get out of the way, or offer to help you clean up the mess.

Get Going

Depending on what feedback you got you are in one of the following positions:

1. Exile to a Branch
2. Working on Trunk

Exile to a Branch

This is what all those branches in the svn repository are about - and they are not fun Many great geotools capabilities started out life in a branch: from the datastore api, through to grid coverage exchange and feature id mapping.

When asked to work on a branch please don't feel neglected. You are working on important aspects of the geotools library. Infact your work is so important that it would impact current development. By having your own branch you are free to work on any module and do great things.

With Great Powers comes great responsibilities You are responsible for: merging your work back onto trunk releasing a new GeoTools point release If your branch lasts more then a couple of weeks this is going to represent a lot of work - please be warned and try to work within the plugin system if at all possible.

Of course when you eventually merge your work back onto trunk you will need to go through that get permission cycle again - hopefully you can scare up a few volunteers (at least for testing).

Go Ahead - working on trunk

This is actually the worst outcome - why?

• Because you have landed on a critical path. That don't break the build guideline will really start to kick in.
• This means that you really have to run maven (from scratch), and pass all tests, before you even think about committing.
• You will also need to send out those permission emails all the time as you run over module after module with changes.

Working on an unsupported/ module or in a branch is way more fun.

However don't lose hope - others have braved this process - infact some of our GeoAPI updates have happened in just this fashion.

And on the bright side you will get lots of feedback when you break things.