| 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 | | === Check-ins === |
| 4 | | 1. Work on the right branch - see BranchingPolicy. |
| 5 | | 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. |
| 6 | | 1. Run all the tests before you commit your code. It only takes 5 minutes! {{{nosetests --ckan ckan/tests}}} |
| 7 | | |
| 8 | | === Starting out === |
| 9 | | * Before you can commit changes to the OKF repo, you'll need access rights - ask for these on [CkanDev ckan-dev]. |
| 10 | | |
| 11 | | === Life-cycle of a change === |
| 12 | | Unless it is a terribly minor change: |
| 13 | | * Create a ticket with your suggestion and design detail as necessary. |
| 14 | | * Send a link to the ticket to [CkanDiscuss ckan-discuss] and ask for suggestions. |
| 15 | | * 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. |
| 16 | | * When done, close the ticket and announce it on [CkanDiscuss ckan-discuss]. |
| 17 | | |
| 18 | | === Don't break the build === |
| 19 | | * 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 ;-) |
| 20 | | * If you break the build, please fix it quickly. If it may take time then email [CkanDev ckan-dev] to let others know what the plan is. |
| | 1 | This page has moved to: http://wiki.ckan.net/Mercurial |
