| | 1 | CKAN is open source and contributions are welcome. However, we have some guidelines for check-ins to ensure that all developers can work well together. |
| | 2 | |
| | 3 | 1. Work on the right branch - see VersionsAndBranching |
| | 4 | 1. Write tests for all changes. Unit tests go into ckan/tests/{area}/ and functional tests go into ckan/tests/functional/ . Tests describe intent and stop the code regressing in the future. |
| | 5 | 1. Run all the tests before you commit your code. It only takes 5 minutes |
| | 6 | |
| | 7 | Starting out: |
| | 8 | * Before you can commit changes to the OKF repo, you'll need access rights - ask for these on [[CkanDiscuss|ckan-discuss]]. |
| | 9 | |
| | 10 | Life-cycle of a change: |
| | 11 | Unless it is a terribly minor change: |
| | 12 | * Create a ticket with your suggestion and design detail as necessary |
| | 13 | * Send a link to the ticket to [[CkanDiscuss|ckan-discuss]] and ask for suggestions |
| | 14 | * Do it, whilst leaving the repo in a good state at all times (i.e. builds and works). Use another branch or bitbucket if necessary. |
| | 15 | * Announce it on [[CkanDiscuss|ckan-discuss]] and close the ticket when done. |
| | 16 | |
| | 17 | Don't break the build: |
| | 18 | * Keep an eye on [[http://buildbot.okfn.org/waterfall|buildbot]] to make sure you don't break the build. If you're a regular developer, ask to be added to the buildbot emails. Don't wait to be nagged by other frustrated developers ;-) |
| | 19 | * If you break the build, please fix it quickly. If it may take time then email [[CkanDiscuss|ckan-discuss]] to let others know what the plan is. |
