FieldTrip is an Open Source project with contributions from various individual users and research groups.
There are various ways in which you can also contribute to the development of FieldTrip.
The FieldTrip community is centered around the email discussion list. You can contribute your expertise by helping other people, answering questions from other people on the email list, or post your ideas.
This FieldTrip website is a Wiki (just like Wikipedia), which allows anyone visiting the site to add, remove, or otherwise edit all content, very quickly and easily, without the need for registration. The IP addresses of people that make changes are logged, and they can be blocked if needed. Please act responsibly and make changes that improve this site.
We invite you to add your own example scripts or frequently asked questions on the wiki. Also tutorials can be added. Every time you explain somebody something about Fieldtrip, please consider whether you could use the wiki for this so others can learn from it as well.
When you add documentation, please consider the documentation guidelines to keep it consistent with other documentation and to facilitate cross-linking.
You can contribute by sharing your Matlab source code with us and help us integrate it into the FieldTrip toolbox. On the development section of this wiki you can find more details on how the development is organized. You can of course also ask.
When you want to contribute code, please consider the code guidelines to keep it consistent and compatible with the existing implementation. Also try to adhere to the existing representation of the data in the data structures.
To get access to the code, please refer to the SVN documentation.
Good ideas on improving FieldTrip are always welcome. You can request for improvements of the code or new functionality. We cannot guarantee that we have time to implement it, but it is good to know what people would like to do with FieldTrip.
You can provide us with detailed bug reports. The easier it is for one of us to reproduce the bug, the more likely it is that we can fix the problem. Good bug reports include a small testscript and the data (i.e. mat file) required to reproduce the bug.